diff options
author | Jan Kiszka <jan.kiszka@siemens.com> | 2013-03-13 12:42:34 +0100 |
---|---|---|
committer | Gleb Natapov <gleb@redhat.com> | 2013-03-13 16:08:10 +0200 |
commit | 66450a21f99636af4fafac2afd33f1a40631bc3a (patch) | |
tree | 81a71a5ad44edcb7317567b2a922e9a861bb2bb8 /arch/h8300 | |
parent | 5d218814328da91a27e982748443e7e375e11396 (diff) | |
download | kernel_goldelico_gta04-66450a21f99636af4fafac2afd33f1a40631bc3a.zip kernel_goldelico_gta04-66450a21f99636af4fafac2afd33f1a40631bc3a.tar.gz kernel_goldelico_gta04-66450a21f99636af4fafac2afd33f1a40631bc3a.tar.bz2 |
KVM: x86: Rework INIT and SIPI handling
A VCPU sending INIT or SIPI to some other VCPU races for setting the
remote VCPU's mp_state. When we were unlucky, KVM_MP_STATE_INIT_RECEIVED
was overwritten by kvm_emulate_halt and, thus, got lost.
This introduces APIC events for those two signals, keeping them in
kvm_apic until kvm_apic_accept_events is run over the target vcpu
context. kvm_apic_has_events reports to kvm_arch_vcpu_runnable if there
are pending events, thus if vcpu blocking should end.
The patch comes with the side effect of effectively obsoleting
KVM_MP_STATE_SIPI_RECEIVED. We still accept it from user space, but
immediately translate it to KVM_MP_STATE_INIT_RECEIVED + KVM_APIC_SIPI.
The vcpu itself will no longer enter the KVM_MP_STATE_SIPI_RECEIVED
state. That also means we no longer exit to user space after receiving a
SIPI event.
Furthermore, we already reset the VCPU on INIT, only fixing up the code
segment later on when SIPI arrives. Moreover, we fix INIT handling for
the BSP: it never enter wait-for-SIPI but directly starts over on INIT.
Tested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Diffstat (limited to 'arch/h8300')
0 files changed, 0 insertions, 0 deletions