The ABI is broken and we cannot support it properly. Turn it off.
If this causes a meaningful performance regression for someone, KVM can introduce an improved ABI that is supportable.
Cc: stable@vger.kernel.org Signed-off-by: Andy Lutomirski luto@kernel.org --- arch/x86/kernel/kvm.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index 93ab0cbd304e..71f9f39f93da 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -318,11 +318,16 @@ static void kvm_guest_cpu_init(void)
pa = slow_virt_to_phys(this_cpu_ptr(&apf_reason));
-#ifdef CONFIG_PREEMPTION - pa |= KVM_ASYNC_PF_SEND_ALWAYS; -#endif pa |= KVM_ASYNC_PF_ENABLED;
+ /* + * We do not set KVM_ASYNC_PF_SEND_ALWAYS. With the current + * KVM paravirt ABI, if an async page fault occurs on an early + * memory access in the normal (sync) #PF path or in an NMI + * that happens early in the #PF code, the combination of CR2 + * and the APF reason field will be corrupted. + */ + if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF_VMEXIT)) pa |= KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT;
On Fri, Mar 6, 2020 at 6:16 PM Andy Lutomirski luto@kernel.org wrote:
The ABI is broken and we cannot support it properly. Turn it off.
If this causes a meaningful performance regression for someone, KVM can introduce an improved ABI that is supportable.
Ugh, disregard this patch. I flubbed the comment, and I'll send v2 shortly.
Andy Lutomirski luto@kernel.org writes:
The ABI is broken and we cannot support it properly. Turn it off.
If this causes a meaningful performance regression for someone, KVM can introduce an improved ABI that is supportable.
Cc: stable@vger.kernel.org Signed-off-by: Andy Lutomirski luto@kernel.org
arch/x86/kernel/kvm.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index 93ab0cbd304e..71f9f39f93da 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -318,11 +318,16 @@ static void kvm_guest_cpu_init(void) pa = slow_virt_to_phys(this_cpu_ptr(&apf_reason)); -#ifdef CONFIG_PREEMPTION
pa |= KVM_ASYNC_PF_SEND_ALWAYS;-#endif pa |= KVM_ASYNC_PF_ENABLED;
/** We do not set KVM_ASYNC_PF_SEND_ALWAYS. With the current* KVM paravirt ABI, if an async page fault occurs on an early* memory access in the normal (sync) #PF path or in an NMI* that happens early in the #PF code, the combination of CR2* and the APF reason field will be corrupted.
I don't think this can happen. In both cases IF == 0 and that async (think host side) page fault will be completely handled on the host. There is no injection happening in such a case ever. If it does, then yes the host side implementation is buggered, but AFAICT this is not the case.
See also my reply in the other thread:
https://lore.kernel.org/r/87r1y4a3gw.fsf@nanos.tec.linutronix.de
Thanks,
tglx
On Mar 7, 2020, at 2:09 AM, Thomas Gleixner tglx@linutronix.de wrote:
Andy Lutomirski luto@kernel.org writes:
The ABI is broken and we cannot support it properly. Turn it off.
If this causes a meaningful performance regression for someone, KVM can introduce an improved ABI that is supportable.
Cc: stable@vger.kernel.org Signed-off-by: Andy Lutomirski luto@kernel.org
arch/x86/kernel/kvm.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index 93ab0cbd304e..71f9f39f93da 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -318,11 +318,16 @@ static void kvm_guest_cpu_init(void)
pa = slow_virt_to_phys(this_cpu_ptr(&apf_reason));-#ifdef CONFIG_PREEMPTION
pa |= KVM_ASYNC_PF_SEND_ALWAYS;-#endif pa |= KVM_ASYNC_PF_ENABLED;
/** We do not set KVM_ASYNC_PF_SEND_ALWAYS. With the current* KVM paravirt ABI, if an async page fault occurs on an early* memory access in the normal (sync) #PF path or in an NMI* that happens early in the #PF code, the combination of CR2* and the APF reason field will be corrupted.I don't think this can happen. In both cases IF == 0 and that async (think host side) page fault will be completely handled on the host. There is no injection happening in such a case ever. If it does, then yes the host side implementation is buggered, but AFAICT this is not the case.
Indeed. But read v2 please.
See also my reply in the other thread:
https://lore.kernel.org/r/87r1y4a3gw.fsf@nanos.tec.linutronix.de
Thanks,
tglx
linux-stable-mirror@lists.linaro.org
-
Andy Lutomirski -
Andy Lutomirski -
Thomas Gleixner