Re: [PATCH 0/2] KVM: x86: nSVM: fixes for SYSENTER emulation
On Thu, 2021-04-01 at 14:16 +0300, Maxim Levitsky wrote:
> This is a result of a deep rabbit hole dive in regard to why
> currently the nested migration of 32 bit guests
> is totally broken on AMD.
Please ignore this patch series, I didn't update the patch version.
Best regards,
Maxim Levitsky
>
> It turns out that due to slight differences between the original AMD64
> implementation and the Intel's remake, SYSENTER instruction behaves a
> bit differently on Intel, and to support migration from Intel to AMD we
> try to emulate those differences away.
>
> Sadly that collides with virtual vmload/vmsave feature that is used in
> nesting.
> The problem was that when it is enabled,
> on migration (and otherwise when userspace reads MSR_IA32_SYSENTER_{EIP|ESP},
> wrong value were returned, which leads to #DF in the
> nested guest when the wrong value is loaded back.
>
> The patch I prepared carefully fixes this, by mostly disabling that
> SYSCALL emulation when we don't spoof the Intel's vendor ID, and if we do,
> and yet somehow SVM is enabled (this is a very rare edge case), then
> virtual vmload/save is force disabled.
>
> V2: incorporated review feedback from Paulo.
>
> Best regards,
> Maxim Levitsky
>
> Maxim Levitsky (2):
> KVM: x86: add guest_cpuid_is_intel
> KVM: nSVM: improve SYSENTER emulation on AMD
>
> arch/x86/kvm/cpuid.h | 8
> arch/x86/kvm/svm/svm.c | 99 +++---
> arch/x86/kvm/svm/svm.h | 6 +--
> 3 files changed, 76 insertions(+), 37 deletions(-)
>
> --
> 2.26.2
>
[PATCH 0/2] KVM: x86: nSVM: fixes for SYSENTER emulation
This is a result of a deep rabbit hole dive in regard to why
currently the nested migration of 32 bit guests
is totally broken on AMD.
It turns out that due to slight differences between the original AMD64
implementation and the Intel's remake, SYSENTER instruction behaves a
bit differently on Intel, and to support migration from Intel to AMD we
try to emulate those differences away.
Sadly that collides with virtual vmload/vmsave feature that is used in nesting.
The problem was that when it is enabled,
on migration (and otherwise when userspace reads MSR_IA32_SYSENTER_{EIP|ESP},
wrong value were returned, which leads to #DF in the
nested guest when the wrong value is loaded back.
The patch I prepared carefully fixes this, by mostly disabling that
SYSCALL emulation when we don't spoof the Intel's vendor ID, and if we do,
and yet somehow SVM is enabled (this is a very rare edge case), then
virtual vmload/save is force disabled.
V2: incorporated review feedback from Paulo.
Best regards,
Maxim Levitsky
Maxim Levitsky (2):
KVM: x86: add guest_cpuid_is_intel
KVM: nSVM: improve SYSENTER emulation on AMD
arch/x86/kvm/cpuid.h | 8
arch/x86/kvm/svm/svm.c | 99 +++---
arch/x86/kvm/svm/svm.h | 6 +--
3 files changed, 76 insertions(+), 37 deletions(-)
--
2.26.2
[PATCH 0/2] KVM: x86: nSVM: fixes for SYSENTER emulation
This is a result of deep rabbit hole dive in regard to why currently the nested migration of 32 bit guests is totally broken on AMD. It turns out that due to slight differences between the original AMD64 implementation and the Intel's remake, SYSENTER instruction behaves a bit differently on Intel, and to support migration from Intel to AMD we try to emulate those differences away. Sadly that collides with virtual vmload/vmsave feature that is used in nesting such as on migration (and otherwise when userspace reads MSR_IA32_SYSENTER_EIP/MSR_IA32_SYSENTER_ESP), wrong value is returned, which leads to #DF in the nested guest when the wrong value is loaded back. The patch I prepared carefully fixes this, by mostly disabling that SYSCALL emulation when we don't spoof Intel's vendor ID, and if we do, and yet somehow SVM is enabled (this is very rare corner case), then virtual vmload/save is force disabled. Best regards, Maxim Levitsky Maxim Levitsky (2): KVM: x86: add guest_cpuid_is_intel KVM: nSVM: improve SYSENTER emulation on AMD arch/x86/kvm/cpuid.h | 8 arch/x86/kvm/svm/svm.c | 97 -- arch/x86/kvm/svm/svm.h | 7 +-- 3 files changed, 77 insertions(+), 35 deletions(-) -- 2.26.2
