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

[peng.hao2]

>On Tue, 4 Dec 2018 at 00:41, <address@hidden> wrote:
>>
>> >I would still prefer to see a more detailed examination of whether
>> >we can do this with a PCI device before we commit to taking the
>> >MMIO version into the virt board.
>>
>> I'm sorry I thought I had sent an email. yesterday when I wrote an email to
>> explain the reason, I was interrupted and forgot to send it out.
>>
>> Now the pvpanic device is implemented as a mmio device or an ACPI device in 
>> the kernel,
>> and only one device can be seen at the same time. If the kernel parses FDT 
>> first, then pvpanic
>> is a mmio device. The kernel parses ACPI table first(and virtual machine is 
>> configured with ACPI),
>> and pvpanic  is an ACPI device.
>> If pvpanic is implemented as a PCI device, then the PCI device must still be 
>> seen when the ACPI table
>> is first parsed by the kernel, because ACPI device relies on the mmio space 
>> of the PCI device.
>> Mmio devices can be thought of as just an address space rather than a device 
>> in the strict sense.
>
>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. 
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

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

thanks.
>
>thanks
>-- PMM