On 17/09/20 04:25, yadong.qi@xxxxxxxxx wrote: > From: Yadong Qi <yadong.qi@xxxxxxxxx> > > Background: We have a lightweight HV, it needs INIT-VMExit and > SIPI-VMExit to wake-up APs for guests since it do not monitoring > the Local APIC. But currently virtual wait-for-SIPI(WFS) state > is not supported in KVM, so when running on top of KVM, the L1 > HV cannot receive the INIT-VMExit and SIPI-VMExit which cause > the L2 guest cannot wake up the APs. > > This patch is incomplete, it emulated wait-for-SIPI state by halt > the vCPU and emulated SIPI-VMExit to L1 when trapped SIPI signal > from L2. I am posting it RFC to gauge whether or not upstream > KVM is interested in emulating wait-for-SIPI state before > investing the time to finish the full support. Yes, the patch makes sense and is a good addition. What exactly is missing? (Apart from test cases in kvm-unit-tests!) Paolo > According to Intel SDM Chapter 25.2 Other Causes of VM Exits, > SIPIs cause VM exits when a logical processor is in > wait-for-SIPI state. > > In this patch: > 1. introduce SIPI exit reason, > 2. introduce wait-for-SIPI state for nVMX, > 3. advertise wait-for-SIPI support to guest. > > When L1 hypervisor is not monitoring Local APIC, L0 need to emulate > INIT-VMExit and SIPI-VMExit to L1 to emulate INIT-SIPI-SIPI for > L2. L2 LAPIC write would be traped by L0 Hypervisor(KVM), L0 should > emulate the INIT/SIPI vmexit to L1 hypervisor to set proper state > for L2's vcpu state.
