• Sean Christopherson's avatar
    KVM: x86: Reinstate kvm_vcpu_arch.guest_supported_xcr0 · ee519b3a
    Sean Christopherson authored
    Reinstate the per-vCPU guest_supported_xcr0 by partially reverting
    commit 988896bb; the implicit assessment that guest_supported_xcr0 is
    always the same as guest_fpu.fpstate->user_xfeatures was incorrect.
    
    kvm_vcpu_after_set_cpuid() isn't the only place that sets user_xfeatures,
    as user_xfeatures is set to fpu_user_cfg.default_features when guest_fpu
    is allocated via fpu_alloc_guest_fpstate() => __fpstate_reset().
    guest_supported_xcr0 on the other hand is zero-allocated.  If userspace
    never invokes KVM_SET_CPUID2, supported XCR0 will be '0', whereas the
    allowed user XFEATURES will be non-zero.
    
    Practically speaking, the edge case likely doesn't matter as no sane
    userspace will live migrate a VM without ever doing KVM_SET_CPUID2. The
    primary motivation is to prepare for KVM intentionally and explicitly
    setting bits in user_xfeatures that are not set in guest_supported_xcr0.
    
    Because KVM_{G,S}ET_XSAVE can be used to svae/restore FP+SSE state even
    if the host doesn't support XSAVE, KVM needs to set the FP+SSE bits in
    user_xfeatures even if they're not allowed in XCR0, e.g. because XCR0
    isn't exposed to the guest.  At that point, the simplest fix is to track
    the two things separately (allowed save/restore vs. allowed XCR0).
    
    Fixes: 988896bb ("x86/kvm/fpu: Remove kvm_vcpu_arch.guest_supported_xcr0")
    Cc: stable@vger.kernel.org
    Cc: Leonardo Bras <leobras@redhat.com>
    Signed-off-by: default avatarSean Christopherson <seanjc@google.com>
    Message-Id: <20220824033057.3576315-2-seanjc@google.com>
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    ee519b3a
x86.c 354 KB