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
Attachment:
signature.asc
Description: OpenPGP digital signature
