At 03/08/2012 07:56 PM, Daniel P. Berrange Wrote: > On Thu, Mar 08, 2012 at 01:52:45PM +0200, Avi Kivity wrote: >> On 03/08/2012 01:36 PM, Daniel P. Berrange wrote: >>> On Thu, Mar 08, 2012 at 01:28:56PM +0200, Avi Kivity wrote: >>>> On 03/08/2012 12:15 PM, Wen Congyang wrote: >>>>> When the host knows the guest is panicked, it will set >>>>> exit_reason to KVM_EXIT_GUEST_PANICKED. So if qemu receive >>>>> this exit_reason, we can send a event to tell management >>>>> application that the guest is panicked and set the guest >>>>> status to RUN_STATE_PANICKED. >>>>> >>>>> Signed-off-by: Wen Congyang <wency@xxxxxxxxxxxxxx> >>>>> --- >>>>> kvm-all.c | 5 +++++ >>>>> monitor.c | 3 +++ >>>>> monitor.h | 1 + >>>>> qapi-schema.json | 2 +- >>>>> qmp.c | 3 ++- >>>>> vl.c | 1 + >>>>> 6 files changed, 13 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/kvm-all.c b/kvm-all.c >>>>> index 77eadf6..b3c9a83 100644 >>>>> --- a/kvm-all.c >>>>> +++ b/kvm-all.c >>>>> @@ -1290,6 +1290,11 @@ int kvm_cpu_exec(CPUState *env) >>>>> (uint64_t)run->hw.hardware_exit_reason); >>>>> ret = -1; >>>>> break; >>>>> + case KVM_EXIT_GUEST_PANICKED: >>>>> + monitor_protocol_event(QEVENT_GUEST_PANICKED, NULL); >>>>> + vm_stop(RUN_STATE_PANICKED); >>>>> + ret = -1; >>>>> + break; >>>>> >>>> >>>> If the management application is not aware of this event, then it will >>>> never resume the guest, so it will appear hung. >>> >>> Even if the mgmt app doesn't know about the QEVENT_GUEST_PANICKED, it should >>> still see a QEVENT_STOP event emitted by vm_stop() surely ? So it will >>> know the guest CPUs have been stopped, even if it isn't aware of the >>> reason why, which seems fine to me. >> >> No. The guest is stopped, and there's no reason to suppose that the >> management app will restart it. Behaviour has changed. >> >> Suppose the guest has reboot_on_panic set; now the behaviour change is >> even more visible - service will stop completely instead of being >> interrupted for a bit while the guest reboots. > > Hmm, so this calls for a new command line argument to control behaviour, > similar to what we do for disk werror, eg something like > > --onpanic "report|pause|stop|..." > > where > > report - emit QEVENT_GUEST_PANICKED only If the guest is panicked when libvirt is stopped, and we only emit a event, we cannot know the guest is panicked when libvirt starts. So I add a new RunState to solve this problem. If the guest is stopped when it is panicked, it will change the behaviour. So I think the new RunState should be a running state. Thanks Wen Congyang > pause - emit QEVENT_GUEST_PANICKED and pause VM > stop - emit QEVENT_GUEST_PANICKED and quit VM > stop - emit QEVENT_GUEST_PANICKED and quit VM > > This would map fairly well into libvirt, where we already have config > parameters for controlling what todo with a guest when it panics. > > Regards, > Daniel -- 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
