Il 21/08/2013 16:58, Michael S. Tsirkin ha scritto: > On Wed, Aug 21, 2013 at 04:37:56PM +0200, Paolo Bonzini wrote: >> Il 21/08/2013 16:30, Michael S. Tsirkin ha scritto: >>>> I think the same reasoning went behind the PANICKED state, and for most >>>> cases it's going to be disastrous to put the guest to run again, >>> >>> Why will it? It will most likely just call halt a bit later. >> >> I agree. >> >>>> but I can understand that this is up user/mngt to decide this, not QEMU. >>> >>> I don't have a problem with this patch as such, so >>> >>> Acked-by: Michael S. Tsirkin <mst@xxxxxxxxxx> >>> >>> though I'm still not really sure why do we >>> want to block guest immediately on panic. >>> Why not let it call halt a bit later? >> >> To make sure the panic is detected, and action taken, in the host even >> if management has crashed at the time. > > I'm not sure I get the reference to management crashing - we just > need to maintain "panicked" state to make sure info is not lost ... Yes, but that would be additional burden (a new "info" command to retrieve the exact time of panicking, or something like that). Since synchronous panic events are useful anyway, and crashed management is rare, it's simpler to go the synchronous way. Paolo >> For example, even if you have >> reboot-on-panic active, management has time to take a core dump of the >> paused guest _before_ the reboot. >> >> Paolo > > but this sounds like a good reason to support synchronous panic events. > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list