From: "Dr. David Alan Gilbert" <dgilbert@xxxxxxxxxx>
A live migration under qemu is currently failing when the source
host is ~Nehalem era (pre-xsave) and the destination is much newer,
(configured with a guest CPU type of Nehalem).
QEMU always calls kvm_put_xsave, even on this combination because
KVM_CAP_CHECK_EXTENSION_VM always returns true for KVM_CAP_XSAVE.
When QEMU calls kvm_put_xsave it's rejected by
fpu_copy_uabi_to_guest_fpstate->
copy_uabi_to_xstate->
validate_user_xstate_header
when the validate checks the loaded xfeatures against
user_xfeatures, which it finds to be 0.
I think our initialisation of user_xfeatures is being
too strict here, and we should always allow the base FP/SSE.
Fixes: ad856280ddea ("x86/kvm/fpu: Limit guest user_xfeatures to supported bits of XCR0")
bz: https://bugzilla.redhat.com/show_bug.cgi?id=2079311
Signed-off-by: Dr. David Alan Gilbert <dgilbert@xxxxxxxxxx>
---
arch/x86/kvm/cpuid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index de6d44e07e34..3b2319cecfd1 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -298,7 +298,8 @@ static void kvm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
guest_supported_xcr0 =
cpuid_get_supported_xcr0(vcpu->arch.cpuid_entries, vcpu->arch.cpuid_nent);
- vcpu->arch.guest_fpu.fpstate->user_xfeatures = guest_supported_xcr0;
+ vcpu->arch.guest_fpu.fpstate->user_xfeatures = guest_supported_xcr0 |
+ XFEATURE_MASK_FPSSE;
kvm_update_pv_runtime(vcpu);
--
2.37.2
