qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-1.6 V2 0/2] pvpanic: Separate pvpanic from m


From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH for-1.6 V2 0/2] pvpanic: Separate pvpanic from machine type
Date: Wed, 21 Aug 2013 11:03:17 +0300

On Wed, 2013-08-14 at 10:02 +0300, Ronen Hod wrote:
> How about adding a flag that tells QEMU whether to pause or reboot the guest
> after the panic?
> We cannot assume that we always have a management layer that takes care
> of this.
> One example is Microsoft's WHQL that deliberately generates a BSOD, and then
> examines the dump files.
After this patch the pvpanic is not part of the global devices anymore so just
don't enable it if you want to reboot on BSOD.
In my opinion "reboot after panic" equals "run without pvpanic device"
Marcel

> 
> Ronen.
> 
> On 08/11/2013 06:10 PM, Marcel Apfelbaum wrote:
> > Creating the pvpanic device as part of the machine type has the
> > potential to trigger guest OS, guest firmware and driver bugs.
> > The potential of such was originally viewed as minimal.
> > However, since releasing 1.5 with pvpanic as part
> > of the builtin machine type, several issues were observed
> > in the field:
> >   - Some Windows versions triggered 'New Hardware Wizard' and
> >     an unidentified device appeared in Device Manager.
> >   - Issue reported off list: on Linux >= 3.10
> >     the pvpanic driver breaks the reset on crash option:
> >     VM stops instead of being reset.
> >
> > pvpanic device also changes monitor command behaviour in some cases,
> > such silent incompatible changes aren't expected by management tools:
> >   - Monitor command requires 'cont' before 'system_reset'
> >     in order to restart the VM after kernel panic/BSOD
> >
> > Note that libvirt is the main user and libvirt people indicated their
> > preference to creating device with -device pvpanic rather than a
> > built-in one that can't be removed.
> >
> > These issues were raised at last KVM call. The agreement reached
> > there was that we were a bit too rash to make the device
> > a builtin, and that for 1.6 we should drop the pvpanic device from the
> > default machine type, instead teach management tools to add it by
> > default using -device pvpanic.
> > It's not clear whether changing 1.5 behaviour at this point
> > is a sane thing, so this patchset doesn't touch 1.5 machine type.
> >
> > This patch series reworks the patchset from Hu Tao
> > (don't create pvpanic device by default)
> > addressing comments and modifying behaviour according
> > to what was discussed on the call.
> > Please review and consider for 1.6.
> >
> > A related discussion can be followed at
> > http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00036.html.
> >
> > This is a continuation of patches sent by Hu Tao:
> > http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00124.html
> > http://lists.nongnu.org/archive/html/qemu-devel/2013-08/msg00125.html
> >
> > Changes from v1 (by Hu Tao):
> >   - Keep pvpanic device enabled by default for 1.5
> >     for backport compatibility
> >   - Addressed Andreas Färber review (removed bus type)
> >   - Small changes to be posible to enable pvpanic
> >     both from command line and from machine_init
> >   - Added pvpanic to MISC category
> >
> > Marcel Apfelbaum (2):
> >    hw/misc: don't create pvpanic device by default
> >    hw/misc: make pvpanic known to user
> >
> >   hw/i386/pc_piix.c |  9 ++++-----
> >   hw/i386/pc_q35.c  |  7 ++++---
> >   hw/misc/pvpanic.c | 25 ++++++++++---------------
> >   3 files changed, 18 insertions(+), 23 deletions(-)
> >
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]