Re: [Qemu-devel] pvpanic plans?

[Christian Borntraeger <borntraeger@de.ibm.com>]

On 22/08/13 20:33, Anthony Liguori wrote:
> Laszlo Ersek <lersek@redhat.com> writes:
> 
>> 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)
> 
> Just to further complicate things...
> 
> pvpanic is not going to be present on S390, PPC, ARM, or MIPS because of
> the fact that it's x86 specific.

What about crashed state? I have implemented this state after the guest entered
disabled wait (by convention used by all s390 OSes for crashes)

See commit 08eb8c85e3967b97865d46acadf26dc908fbb094
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date:   Fri Apr 26 11:24:47 2013 +0800

    Wire up disabled wait a panicked event on s390



Should we remove that as well? From s390 point of view, after allowing
the crashed->running transition the feature would probably work as expected.


Christian