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

[Peter Maydell]

On Wed, 5 Dec 2018 at 00:28, <address@hidden> wrote:
>
> >I'm afraid I don't understand. If it's a PCI device then
> >it does not need to be listed in the device tree or the
> >ACPI tables at all, because it is probeable by the guest.
> >This also significantly simplifies the changes needed in QEMU.
> >
>
> It is precisely because PCI devices can not be controlled by FDT or ACPI 
> tables,
> I do not want to implement it as a pci device.
> X86/pvpanic is implemented as ISA device in QEMU and ACPI device in kernel.
> My implementation extends the implementation of x86/pvpanic, and a large of 
> x86/pvpanic
> codes are reused.If PCI devices are implemented in qemu, then ACPI devices 
> and PCI
> devices may appear simultaneously in the kernel. This would add both devices 
> to the
> crash notifier list, which is odd. I want to see only one device at any time.

Yes, certainly we only need one pvpanic device. If it's implemented
as a PCI device, then that's what appears. We don't need and
would not implement the MMIO version. On x86 a user could
in theory use the command line to request both ISA and PCI
pvpanic devices. That would not be very sensible, but there
are lots of QEMU command lines the user can request that
don't make sense.

> Of course, many
> architectures can use PCI devices, but we are currently reusing x86/pvpanic 
> code as much
> as possible in qemu and kernel , rather than reimplementing it. At the same 
> time,
> backward compatibility also needs to be considered.
>
>                                      pvpanic in guest kernel
> ARM:   ACPI table         acpi device
>             FDT                  mmio device  (start guest bypassing uefi)
> x86      ACPI table         acpi device

For Arm, there is no backward compatibility issue, as we have
not yet implemented or shipped anything.

> >> Secondly, I don't want it to be a pluggable device. If the user
> >> deletes the device by mistake, it may lead to unpredictable results.
> >
> >If the user deletes the PCI device they're using for their
> >disk or networking this will also lead to unpredictable
> >results. We expect users not to randomly unplug things from
> >their system if they want it to continue to work. In any
> >case your guest driver can easily handle the unplug: the
> >guest would then just lose the ability to notify on panic,
> >falling back to as if the pvpanic device had never been
> >present.
>
> If two devices can exist simultaneously by modifying the code,
>  then because ACPI devices rely on a PCI device, if PCI devices are 
> dynamically
>  unplugged, ACPI device will not work when panic is triggered.

If somebody modifies the code to QEMU or the guest kernel
such that something breaks, that's their issue to deal with.
My proposal is that we would ship:
 * a QEMU with a PCI pvpanic device (which you could plug in
   if you wanted it)
 * no changes to the Arm virt board, so nothing in the ACPI
   or device tree
 * no "mmio pvpanic" device

thanks
-- PMM