Re: [libvirt] pvpanic plans?

> 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*.

> 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.