[libvirt] pvpanic plans?

[Laszlo Ersek]

On 08/22/13 18:44, Anthony Liguori wrote:

> pvpanic has been a failure.  It's a poorly designed device with even
> worse semantics.

I disagree somewhat.

Requiring a separate ioport is not ideal, I admit. Configuration over
ACPI is good OTOH (it seems to put standards to good use anyway).

Noone realized pvpanic had poor technical design until the Windows "new
device" wizard popped up -- is that correct? Most of us are probably not
habitual Windows users, which is probably why we haven't thought of it
earlier.

Maybe we shouldn't promise "there won't be guest-visible changes in ACPI
contents". If we do promise, maybe we should then make the SeaBIOS
binary that we're loading dependent on -M too too.

After all, had we managed to completely hide the \_SB.PCI0.ISA.PEVT
device programmatically, as opposed to only disabling it, we might have
never realized pvpanic had poor design. Which (almost) means it wouldn't
have had one.

If we selected a SeaBIOS binary based on -M, then we could hide this
stuff from Windows.


> I applied it and I'll take the fault for merging it in
> the first place.
> 
> We should simply scrap it and start over.

That will kinda Eff some downstreams in the A...


> It has so few users at this
> point that this is still a realistic option.  Using something based on
> ISA that requires specific ACPI entries was a mistake.
> 
> We should just introduce a simple watchdog device based on virtio and
> call it a day.  Then it's cross platform, solves the guest enumeration
> problem, and libvirt can detect the presence of the new device.

If the guest doesn't initialize the proposed virtio-panic device, then
it will lie dormant too, just like the current pvpanic device. That's good.

However a new (standalone) virtio device will take up yet another PCI
function (a full device if you want it to be hotpluggable). PCI
functions are scarcer than ioports.

It will need documentation in the virtio-spec as well.

We'd need an arbitrarily heavily multiplexed paravirt channel between
guest and qemu. Maybe a dedicated virtio-serial port that's not exposed
to other host processes; one that qemu would "consume" itself.

If you want to be able to panic in boot firmware, writing to an ioport
is easier than adding a new virtio driver (virtio-serial, or a
completely new device).

> None of the plans outlined below give us a proper solution.  I think
> removing is our best option at this point.

I'm just trolling ^W playing the devil's advocate here, giving you more
opportunity to argue your point :)

Thanks,
Laszlo