Hi all, KVM's mp_state on x86 is usually manipulated over the context of the VCPU. Therefore, no locking is required. There are unfortunately two exceptions, and one of them is definitely broken: INIT and SIPI delivery.
The lapic may set mp_state over the context of the sending VCPU. For
SIPI, it first checks if the mp_state is INIT_RECEIVED before updating
it to SIPI_RECEIVED. We can only race here with user space setting the
state in parallel, I suppose. Probably harmless in practice.
What is critical is the update on INIT. That signal is asynchronous to
the target VCPU state. And we can loose it:
vcpu 1 vcpu 2
------ ------
hlt;
vmexit
__apic_accept_irq(APIC_DM_INIT)
mp_state = KVM_MP_STATE_INIT_RECEIVED
mp_state = KVM_MP_STATE_HALTED
And there it goes, our INIT state. I've triggered this under heavy INIT
load and my nVMX patch for processing it while in VMXON.
I'm currently considering options to fix this:
- through a lock at mp_state manipulations, check under the lock that
we don't perform invalid state transitions (e.g. INIT->HLT)
- signal the INIT via some KVM_REQ_INIT to the target VCPU, fully
localizing mp_state updates, the same could be done with SIPI, just
to play safe
I'm leaning toward the latter ATM, Any thoughts or other idea?
Jan
signature.asc
Description: OpenPGP digital signature
