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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list