On Tue, Dec 04, 2018 at 12:59:51PM +0000, Peter Maydell wrote: > On Tue, 4 Dec 2018 at 12:47, Daniel P. Berrangé <berra...@redhat.com> wrote: > > After it had merged there were some changes and the question of turning > > it into a PCI device was raised. Paolo was concerned that the guest OS > > is in an unknown state (arbitrary locks held, data structures corrupt, > > etc) when panic is fired, so simplicity of the I/O port was desirable: > > > > https://lists.gnu.org/archive/html/qemu-devel/2013-08/msg03309.html > > > > Anthony countered that even a PCI device could simply do an outb() in > > config space: > > > > https://lists.gnu.org/archive/html/qemu-devel/2013-08/msg03325.html > > > > So it is not clear using a PCI device is in fact a problem in terms of > > reliability at time of firing. > > ...and if we'd done it that way in the first place for x86 then > we wouldn't be having to do anything at all now for Arm. > That suggests to me that we should do it that way now, and then we > can avoid having to do a bunch of extra development work for the > next architecture, or the next interesting Arm board model.
On s390 there's always a panic notifier mechanism as it is a integral part of the architecture. On PowerPC, pSeries guests have access to a panic notifier provided by the firmware. On x86, as well as pvpanic, there is also a paravirtualized option defined by the HyperV extensions "hv_crash" IIUC a PCI based solution would be usable on x86, s390, powerpc (pseries), aarch64 (virt) and eventually riscv (virt). Of those, it is only aarch64 and riscv that lack a panic notifier solution today. I feel like we've already lost from the pov of a standardized solution, but that doesn't mean we shouldn't still consider using PCI if it does look like the best otion for arm/riscv. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|