Il 22/08/2013 19:15, Laszlo Ersek ha scritto:
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*.
No, we cannot because of backwards compatibility. VMs could have no on_crash element (which means <on_crash>destroy</on_crash>) and yet the guest admin could expect them to reboot on panic.
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.
Is it too much work? s/"pvpanic"/"isa-pvpanic"? Paolo