[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] pvpanic plans?
From: |
Christian Borntraeger |
Subject: |
Re: [Qemu-devel] pvpanic plans? |
Date: |
Mon, 04 Nov 2013 10:25:06 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 |
On 31/10/13 15:30, Michael S. Tsirkin wrote:
> On Thu, Oct 24, 2013 at 10:39:03AM +0800, Hu Tao wrote:
>> Hi All,
>>
>> I know it's been a long time since this thread. But qemu 1.7 is
>> releasing, do you have any consensus on this?
>>
>> Thanks.
>
>
> I think the biggest issue is the new PANICKED state.
I thought the problem was that the new device broke windows and all
the following hazzle.
> Guests already have simple ways to halt the CPU,
> and actually do. I think a new state was a mistake.
> So how about the following? Does it break anything?
> (Untested).
Please note that on s390 we also do the panic state (on a disabled wait)
"target-s390x/kvm.c"
...
monitor_protocol_event(QEVENT_GUEST_PANICKED, data);
qobject_decref(data);
vm_stop(RUN_STATE_GUEST_PANICKED);
...
Currently it is possible to restart libvirt, e.g. after an update and then it
will
be able to fetch the full state of a guest via QMP. It will then also be able to
detect that this guest panicked some time ago.
I think one issue when removing the PANICKED state is that libvirt can then no
longer detect that state, correct?
Christian
>
> Signed-off-by: Michael S. Tsirkin <address@hidden>
>
> diff --git a/hw/misc/pvpanic.c b/hw/misc/pvpanic.c
> index 226e298..2055afc 100644
> --- a/hw/misc/pvpanic.c
> +++ b/hw/misc/pvpanic.c
> @@ -51,7 +51,6 @@ static void handle_event(int event)
>
> if (event & PVPANIC_PANICKED) {
> panicked_mon_event("pause");
> - vm_stop(RUN_STATE_GUEST_PANICKED);
> return;
> }
> }
>
>
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-devel] pvpanic plans?,
Christian Borntraeger <=