File 6306185f-x86-XSTATE-CPUID-subleaf-1-EBX.patch of Package xen

Overview Repositories Revisions Requests Users Attributes Meta

File 6306185f-x86-XSTATE-CPUID-subleaf-1-EBX.patch of Package xen (Revision 542e820733de1e99db3e58a2c9fbf830)

Currently displaying revision 542e820733de1e99db3e58a2c9fbf830 , Show latest

# Commit c3bd0b83ea5b7c0da6542687436042eeea1e7909
# Date 2022-08-24 14:23:59 +0200
# Author Jan Beulich <jbeulich@suse.com>
# Committer Jan Beulich <jbeulich@suse.com>
x86/CPUID: surface suitable value in EBX of XSTATE subleaf 1

While the SDM isn't very clear about this, our present behavior make
Linux 5.19 unhappy. As of commit 8ad7e8f69695 ("x86/fpu/xsave: Support
XSAVEC in the kernel") they're using this CPUID output also to size
the compacted area used by XSAVEC. Getting back zero there isn't really
liked, yet for PV that's the default on capable hardware: XSAVES isn't
exposed to PV domains.

Considering that the size reported is that of the compacted save area,
I view Linux'es assumption as appropriate (short of the SDM properly
considering the case). Therefore we need to populate the field also when
only XSAVEC is supported for a guest.

Fixes: 460b9a4b3630 ("x86/xsaves: enable xsaves/xrstors for hvm guest")
Fixes: 8d050ed1097c ("x86: don't expose XSAVES capability to PV guests")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -1060,7 +1060,7 @@ void guest_cpuid(const struct vcpu *v, u
         switch ( subleaf )
         {
         case 1:
-            if ( p->xstate.xsaves )
+            if ( p->xstate.xsavec || p->xstate.xsaves )
             {
                 /*
                  * TODO: Figure out what to do for XSS state.  VT-x manages

Places

File 6306185f-x86-XSTATE-CPUID-subleaf-1-EBX.patch of Package xen (Revision 542e820733de1e99db3e58a2c9fbf830)

Places