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