acrn-hypervisor/hypervisor
Shiqing Gao 651d44432c 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 <shiqing.gao@intel.com>
Reviewed-by: Li Fei1 <fei1.li@intel.com>
2021-08-20 09:46:09 +08:00
..
acpi_parser hv: dm: Use new power management data structures 2021-07-15 11:53:54 +08:00
arch/x86 hv: initialize the XSAVE related processor state for guest 2021-08-20 09:46:09 +08:00
boot HV: Add implements of 32bit and 64bit elf loader 2021-08-19 20:00:45 +08:00
bsp/ld HV: add a specific stack space used in CPU booting 2020-04-29 13:56:40 +08:00
common hv: Change sched_event structure to resolve data race in event handling 2021-08-20 08:11:40 +08:00
debug HV: debug: support 64bit BAR pci uart with 32bit space 2021-08-04 10:10:35 +08:00
dm hv: mmiodev: a minor bug fix about refine acrn_mmiodev data structure 2021-08-19 12:01:35 +08:00
hw hv: ensure PTM root is always enabled in hw 2021-05-27 09:00:50 +08:00
include hv: Change sched_event structure to resolve data race in event handling 2021-08-20 08:11:40 +08:00
lib HV: replace merge_cmdline api with strncat_s 2020-06-08 13:30:04 +08:00
quirks hv: tpm2: do tpm2 fixup for security vm 2021-08-11 14:45:55 +08:00
release hv: debug: Add hv console callback to VM-exit event 2021-07-22 10:08:23 +08:00
scripts config_tools: remove obsolete kconfig files 2021-08-09 09:25:02 +08:00
MAINTAINERS
Makefile HV: Add elf loader sketch 2021-08-19 20:00:45 +08:00
README.rst

README.rst

ACRN Hypervisor
###############

The open source `Project ACRN`_ defines a device hypervisor reference stack and
an architecture for running multiple software subsystems, managed securely, on
a consolidated system by means of a virtual machine manager. It also defines a
reference framework implementation for virtual device emulation, called the
"ACRN Device Model".

The ACRN Hypervisor is a Type 1 reference hypervisor stack, running directly on
the bare-metal hardware, and is suitable for a variety of IoT and embedded
device solutions. The ACRN hypervisor addresses the gap that currently exists
between datacenter hypervisors, and hard partitioning hypervisors. The ACRN
hypervisor architecture partitions the system into different functional
domains, with carefully selected guest OS sharing optimizations for IoT and
embedded devices.

You can find out more about Project ACRN on the `Project ACRN documentation`_
website.

.. _`Project ACRN`: https://projectacrn.org
.. _`ACRN Hypervisor`: https://github.com/projectacrn/acrn-hypervisor
.. _`Project ACRN documentation`: https://projectacrn.github.io/