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

[<peng.hao2@zte.com.cn>]

>On Wed, 5 Dec 2018 at 00:28, <peng.hao2@zte.com.cn> 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.
>

Sorry, the expression is not clear enough. I want to say that x86 needs backward 
compatibility if we intend to reuse the code of x86/pvpanic.

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

ok, I will try it.
thanks.
>
>thanks
>-- PMM