On 22/08/13 20:33, Anthony Liguori wrote:
Laszlo Ersek <lersek(a)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(a)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