From 651d44432cb86d4f9b4b9337eb8fd634d41068ca Mon Sep 17 00:00:00 2001 From: Shiqing Gao Date: Wed, 18 Aug 2021 15:34:40 +0800 Subject: [PATCH] hv: initialize the XSAVE related processor state for guest If SOS is using kernel 5.4, hypervisor got panic with #GP. Here is an example on KBL showing how the panic occurs when kernel 5.4 is used: Notes: * Physical MSR_IA32_XSS[bit 8] is 1 when physical CPU boots up. * vcpu_get_guest_msr(vcpu, MSR_IA32_XSS)[bit 8] is initialized to 0. Following thread switches would happen at run time: 1. idle thread -> vcpu thread context_switch_in happens and rstore_xsave_area is called. At this moment, vcpu->arch.xsave_enabled is false as vcpu is not launched yet and init_vmcs is not called yet (where xsave_enabled is set to true). Thus, physical MSR_IA32_XSS is not updated with the value of guest MSR_IA32_XSS. States at this point: * Physical MSR_IA32_XSS[bit 8] is 1. * vcpu_get_guest_msr(vcpu, MSR_IA32_XSS)[bit 8] is 0. 2. vcpu thread -> idle thread context_switch_out happens and save_xsave_area is called. At this moment, vcpu->arch.xsave_enabled is true. Processor state is saved to memory with XSAVES instruction. As physical MSR_IA32_XSS[bit 8] is 1, ectx->xs_area.xsave_hdr.hdr.xcomp_bv[bit 8] is set to 1 after the execution of XSAVES instruction. States at this point: * Physical MSR_IA32_XSS[bit 8] is 1. * vcpu_get_guest_msr(vcpu, MSR_IA32_XSS)[bit 8] is 0. * ectx->xs_area.xsave_hdr.hdr.xcomp_bv[bit 8] is 1. 3. idle thread -> vcpu thread context_switch_in happens and rstore_xsave_area is called. At this moment, vcpu->arch.xsave_enabled is true. Physical MSR_IA32_XSS is updated with the value of guest MSR_IA32_XSS, which is 0. States at this point: * Physical MSR_IA32_XSS[bit 8] is 0. * vcpu_get_guest_msr(vcpu, MSR_IA32_XSS)[bit 8] is 0. * ectx->xs_area.xsave_hdr.hdr.xcomp_bv[bit 8] is 1. Processor state is restored from memory with XRSTORS instruction afterwards. According to SDM Vol1 13.12 OPERATION OF XRSTORS, a #GP occurs if XCOMP_BV sets a bit in the range 62:0 that is not set in XCR0 | IA32_XSS. So, #GP occurs once XRSTORS instruction is executed. Such issue does not happen with kernel 5.10. Because kernel 5.10 writes to MSR_IA32_XSS during initialization, while kernel 5.4 does not do such write. Once guest writes to MSR_IA32_XSS, it would be trapped to hypervisor, then, physical MSR_IA32_XSS and the value of MSR_IA32_XSS in vcpu->arch.guest_msrs are updated with the value specified by guest. So, in the point 2 above, correct processor state is saved. And #GP would not happen in the point 3. This patch initializes the XSAVE related processor state for guest. If vcpu is not launched yet, the processor state is initialized according to the initial value of vcpu_get_guest_msr(vcpu, MSR_IA32_XSS), ectx->xcr0, and ectx->xs_area. With this approach, the physical processor state is consistent with the one presented to guest. Tracked-On: #6434 Signed-off-by: Shiqing Gao Reviewed-by: Li Fei1 --- hypervisor/arch/x86/guest/vcpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hypervisor/arch/x86/guest/vcpu.c b/hypervisor/arch/x86/guest/vcpu.c index 9abf5e53a..d349e202d 100644 --- a/hypervisor/arch/x86/guest/vcpu.c +++ b/hypervisor/arch/x86/guest/vcpu.c @@ -843,7 +843,7 @@ void save_xsave_area(struct acrn_vcpu *vcpu, struct ext_context *ectx) void rstore_xsave_area(const struct acrn_vcpu *vcpu, const struct ext_context *ectx) { - if (vcpu->arch.xsave_enabled) { + if ((!vcpu->launched) || (vcpu->arch.xsave_enabled)) { write_xcr(0, ectx->xcr0 | XSAVE_SSE); msr_write(MSR_IA32_XSS, vcpu_get_guest_msr(vcpu, MSR_IA32_XSS)); xrstors(&ectx->xs_area, UINT64_MAX);