[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen stable-4.15] x86/CPUID: surface suitable value in EBX of XSTATE subleaf 1
commit 7923ea47e578bca30a6e45951a9da09e827ff028 Author: Jan Beulich <jbeulich@xxxxxxxx> AuthorDate: Tue Oct 11 15:14:05 2022 +0200 Commit: Jan Beulich <jbeulich@xxxxxxxx> CommitDate: Tue Oct 11 15:14:05 2022 +0200 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@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: c3bd0b83ea5b7c0da6542687436042eeea1e7909 master date: 2022-08-24 14:23:59 +0200 --- xen/arch/x86/cpuid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index ee2c4ea03a..11c95178f1 100644 --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c @@ -1052,7 +1052,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf, 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 -- generated by git-patchbot for /home/xen/git/xen.git#stable-4.15
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |