[libvirt] pvpanic plans?

[Laszlo Ersek]

On 08/22/13 18:10, Paolo Bonzini wrote:
> The thread from yesterday has died off (perhaps also because of
> my inappropriate answer to Michael, for which I apologize to him
> and everyone).  I took some time to discuss the libvirt requirements
> further with Daniel Berrange and Eric Blake on IRC.  If anyone is
> interested, I can give logs.  This is a suggestion for how to
> proceed in both QEMU and libvirt.

The analysis is pretty overwhelming :)

I have read Anthony's response and I'm not trying to argue -- I'm just
spending a few thoughts on this and I'm willing to let them go to waste.

In general I think we should minimize the quirks the user (who edits the
libvirt XML) has to know about. Interactions between some XML elements,
without explicit inter-references (formulated as attributes, like
controller/index) are Bad (TM). So,

> == Builtin pvpanic ==
> 
> QEMU will remove pvpanic from pc-1.5 in 1.6.1 and 1.5.4.  This does not
> break migration.
> 
> 
> == Support in libvirt for current functionality ==
> 
> libvirt will add a <panic-notifier/> element, and possibly a capability
> for it accessible via "virsh capabilities".  There are two possibilities:
> 
> 1) On QEMU 1.5.4/1.6.1 and newer (and on QEMU 1.6.0 with a machine type
>    other than pc-1.5), <on_crash> will only work if the element is there.
>    On QEMU 1.5.0->1.5.3, and on QEMU 1.6.0 with the pc-1.5 machine type,
>    <on_crash> will be obeyed always, and may override e.g. reboot-on-panic
>    if a guest driver exist.

I don't like this because there's some interplay between on_crash and
panic_notifier, which even depends on the qemu version.


> 
> 2) On all versions, <on_crash> will only work if the element is there.

I like this, because, if on_crash doesn't work without panic_notifier
*at all*, then we can just drop panic_notifier, and make on_crash mean
(on_crash && panic_notifier) in the original sense.

IOW, drop "panic_notifier", and make "on_crash" work *always*.

> 
> 
> In turn, there are two ways to implement (2):
> 
> 2a) libvirt will always add -global pvpanic.iobase=0 to neutralize
>     the builtin pvpanic device if present.  <panic-notifier/>
>     will create the device with -device pvpanic,iobase=0x505
> 
>     Advantage: no changes to QEMU
> 
>     Disadvantage 1: writes to port 0 with QEMU 1.{5.0,5.1,5.2,5.3,6.0}
>       and pc-1.5 machine type will write to a pvpanic device instead of
>       the DMA controller.  Probably harmless, and limited to some QEMU
>       versions.
> 
>     Disadvantage 2: libvirt has knowledge of the pvpanic port number

Updating this paragraph with my above suggestion:

- (s/pvpanic.iobase/pvpanic.ioport/g)

- if "on_crash" is absent:
  - for 1.{5.0,5.1,5.2,5.3,6.0}, add -global pvpanic.ioport=0
  - for other versions, do nothing

- if "on_crash" is present:
  - for 1.{5.0,5.1,5.2,5.3,6.0}, do nothing,
  - for other versions, pass -device pvpanic
    (knowledge of 0x505 is unneeded)

"advantage" and "disadvantage 1" remain, "disadvantage 2" is gone.


> 2b) QEMU will provide a way for libvirt to detect that no machine type
>     has the builtin pvpanic.  If some machine type may have the builtin
>     pvpanic, and <panic-notifier/> is absent, libvirt will add
>     "-global pvpanic.iobase=0" to neutralize it.  Otherwise, libvirt
>     will create the device normally.
> 
>     A possible way for libvirt to detect "good" machine types is a
>     dummy property.  This is a bit ugly in that the property would not
>     affect the behavior of the device.  The property would remain in
>     the long term.
> 
>     Another possibility is for QEMU to rename the device, e.g. to
>     isa-pvpanic.  This is also somewhat gross, but not visible in the
>     long term when the "pvpanic" name will be lost in history.
> 
>     Advantage 1: libvirt has no knowledge of the pvpanic port number
> 
>     Disadvantage 1: same as above
> 
>     Disadvantage 2: need a somewhat gross change in QEMU
> 
> 
>     This method also provides an (also somewhat gross on the QEMU side)
>     way to detect other changes in the pvpanic semantics.  One example
>     mentioned below, is making the panicked state temporary.

Too much work in qemu, in order to introduce ugliness, to hide older
ugliness.

> == Possible improvements to pvpanic ==

That's too complex / far out for me now, sorry :)

Thanks,
Laszlo