Re: [Qemu-arm] [Qemu-devel] [PATCH V11 0/8] add pvpanic mmio support

[Peter Maydell]

On Tue, 4 Dec 2018 at 12:47, Daniel P. Berrangé <address@hidden> 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.

> Perhaps more relevant is the question of how easily it can be initialized,
> as that affects whether it can be used for panics during very early boot,
> or from firmware:
>
>   https://lists.gnu.org/archive/html/qemu-devel/2013-08/msg03296.html

Mmm, firmware and early boot panic is potentially an interesting
use case. Does UEFI actually make use of it, though? A quick look
at the kernel source for the x86 pvpanic driver suggests it doesn't
take any particular steps to ensure that it is initialized early,
though I guess acpi drivers probably init before PCI.

I notice also that there's a mention in that thread that the pvpanic
ACPI table entry on x86 resulted in unhelpful Windows notifications
about new devices it didn't understand. Is that going to be an issue
for Arm with this mmio pvpanic ?

> Finally, there is also the point that PCI slots are precious, and this
> is something to be enabled out of the box on all VMs, so you'd be removing
> one extra PCI slot from general usage. Thus mgmt apps would need to start
> adding PCI bridges sooner. Not a blocker but something to bear in mind
> when weighing up options.

Space in the 'virt' memory map for random MMIO devices is also a limited
resource, especially if you want something in the <4GB space.

thanks
-- PMM