When VCPU #0 exits (e.g. due to KVM_EXIT_SYSTEM_EVENT), it sends
SIGKVMEXIT to all other VCPUs, waits for them to exit, then tears down
any remaining context. The signalling of SIGKVMEXIT is critical to
forcing VCPUs to shut down in response to a system event (e.g. PSCI
SYSTEM_OFF).
VCPUs other that VCPU #0 simply exit in kvm_cpu_thread without forcing
other CPUs to shut down. Thus if a system event is taken on a VCPU other
than VCPU #0, the remaining CPUs are left online. This results in KVM
tool not exiting as expected when a system event is taken on a VCPU
other than VCPU #0 (as may happen if the guest panics).
Fix this by tearing down all CPUs upon a system event, regardless of the
CPU on which the event occurred. While this means the VCPU thread will
signal itself, and VCPU #0 will signal all other VCPU threads a second
time, these are harmless.
Signed-off-by: Mark Rutland <mark.rutland@xxxxxxx>
Cc: Marc Zyngier <marc.zyngier@xxxxxxx>
Cc: Suzuki Poulose <suzuki.poulose@xxxxxxx>
Cc: Will Deacon <will.deacon@xxxxxxx>
---
kvm-cpu.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
Since v1:
* Per Suzuki's suggestion, use kvm_cpu__reboot() to tear down all CPUs,
as PPC does for RTAS power off and reboot.
diff --git a/kvm-cpu.c b/kvm-cpu.c
index 5d90664..664795f 100644
--- a/kvm-cpu.c
+++ b/kvm-cpu.c
@@ -166,13 +166,18 @@ int kvm_cpu__start(struct kvm_cpu *cpu)
* treat all system events as shutdown request.
*/
switch (cpu->kvm_run->system_event.type) {
- case KVM_SYSTEM_EVENT_RESET:
- /* Fall through for now */
- case KVM_SYSTEM_EVENT_SHUTDOWN:
- goto exit_kvm;
default:
pr_warning("unknown system event type %d",
cpu->kvm_run->system_event.type);
+ /* fall through for now */
+ case KVM_SYSTEM_EVENT_RESET:
+ /* Fall through for now */
+ case KVM_SYSTEM_EVENT_SHUTDOWN:
+ /*
+ * Ensure that all VCPUs are torn down,
+ * regardless of which CPU generated the event.
+ */
+ kvm_cpu__reboot(cpu->kvm);
goto exit_kvm;
};
break;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
