Re: [Qemu-devel] pvpanic plans?

[Laszlo Ersek <lersek@redhat.com>]

On 08/22/13 21:19, Paolo Bonzini wrote:
> 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.

Ah. I thought "no on_crash" meant <on_crash>ignore</on_crash>, or
something like that -- if on_crash was absent, the guest wouldn't see a
working pvpanic device in ACPI, and wouldn't trigger the event in qemu.

>>> 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"?

... I probably skipped the rename option because you called it gross
(and maybe because I (erroneously?) recall Michael's opposition). I
think I meant the dummy property under "too much work" (it may not be,
in retrospect, but properties always imply compat stuff for me, and
*that* is scary).

Laszlo