The call to kvm_apic_accept_events(vcpu) from kvm_arch_vcpu_ioctl_get_mpstate() is just, oh, so wrong. First, it can change all kinds of vCPU state, which imposes undocumented dependencies on reliable orderings of the KVM_GET_* family of ioctls for serializing VM state. But, even worse, it can modify guest memory, even while all vCPU threads are stopped! Just follow the call chain down to vmx_complete_nested_posted_interrupt(). That path wasn't there when the call to kvm_apic_accept_events(vcpu) was added to kvm_arch_vcpu_ioctl_get_mpstate() back in 2013, but it's there now. I'm not entirely sure why this call was added in the first place. Was this simply to avoid serializing the two new bits in apic->pending_events? It seems that we now *do* serialize KVM_APIC_INIT in the kvm_vcpu_events struct. Strangely, we call it smi.latched_init, but it looks like we put the pending_events bit in there all the time, regardless of what's happening with SMM. Would anyone object to serializing KVM_APIC_SIPI in the kvm_vcpu_events struct as well? Or would it be better to resurrect KVM_MP_STATE_SIPI_RECEIVED? In any event, the call to kvm_apic_accept_events(vcpu) from kvm_arch_vcpu_ioctl_get_mpstate() has to go.
