Laszlo Ersek <lersek@xxxxxxxxxx> 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.
That means at some point there's going to have to be another device to
support these platforms and libvirt will need to deal with that too.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list