Re: [Qemu-devel] pvpanic plans?

[Paolo Bonzini <pbonzini@redhat.com>]

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