Re: [libvirt] pvpanic plans?
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