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)