KVM: x86: Racy mp_state manipulations

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]