[libvirt] pvpanic plans?

[Anthony Liguori]

Laszlo Ersek <lersek at redhat.com> writes:

> 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.

Generating ACPI tables dynamically is painful and worse yet, it's 100%
ACPI specific.  Had we used virtio from the start, we would have had a
cross-architecture mechanism instead of a one-off x86-ism.

Yes, hind sight is 20/20 but that shouldn't stop us from doing things
right when presented the opportunity.

> 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.

Yes, at some point I'm sure we'll hit the need for maintaining multiple
copies of SeaBIOS but that's going to make testing all that much
harder.  The longer we can avoid it the better IMHO.

>> 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...

If it's too late then we're stuck with it, but perhaps some of the
downstreams can skip up about what level of support they need for the
existing device in a bit more detail...

AFAICT, we've got something that's fundamentally broken right now so
downstreams are already in a bind if they're planning on supporting this
device.

>> 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.

Ack.

> 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.

We can always use bridges to expand the number of slots available.  If
we truly run into a situation where slots become too scarce, then we can
look at introducing a PCI-to-N-virtio-devices bridge.

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

Ack.

> 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.

I don't think using virtio-serial would be a good approach.

If we make the panic flag a config space variable, it makes it pretty
easy for firmware to use since it's still just an ioport write.

> 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).

See above.

>> 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 :)

It's really a tremendously simple virtio device to start with.  No
queues, just a configuration space with a single flag.

Down the road, I can imagine lots of useful extensions like the ability
to send a stack trace to the host as part of the panic.  That would be
mighty handy.  That's easy to add with virtio but pretty much impossible
with the current device.

Plus adding watchdog functionality would be a logical extension too.  I
believe that the watchdogs we emulate today are not supported by a
majority of guests.  A virtio-ras device with Windows and Linux drivers
would give us a universally supported watchdog device.

Regards,

Anthony Liguori

>
> Thanks,
> Laszlo