[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [Qemu-devel] [PATCH V11 0/8] add pvpanic mmio support
From: |
Andrew Jones |
Subject: |
Re: [Qemu-arm] [Qemu-devel] [PATCH V11 0/8] add pvpanic mmio support |
Date: |
Tue, 4 Dec 2018 13:05:47 +0100 |
User-agent: |
NeoMutt/20180716 |
On Tue, Dec 04, 2018 at 09:40:07AM +0000, Peter Maydell wrote:
> 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.
>
> > 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.
>
To muddy the waters a bit more, while I'm not opposed to this device
being a PCI device, there is a chance that someone will still want a
platform-mmio version as well. I'm not sure how everything will
eventually fall into place, but I've seen some super minimal guest
configs proposed for the VMs-used-like-containers use cases, even
configs that choose to use virtio-mmio over virtio-pci, and then not
provide a PCI bus at all to the vm.
Maybe this series and the current kernel series can be allowed to
continue as they are, and if later there's a demand for a pci version,
it could just be yet another variant added later?
Thanks,
drew
- Re: [Qemu-arm] [PATCH V11 6/8] hw/arm/virt: add configure interface for pvpanic-mmio, (continued)
- [Qemu-arm] [PATCH V11 1/8] hw/misc/pvpanic: Build the pvpanic device in $(common-obj), Peng Hao, 2018/12/03
- [Qemu-arm] [PATCH V11 3/8] hw/misc/pvpanic: Add the MMIO interface, Peng Hao, 2018/12/03
- [Qemu-arm] [PATCH V11 4/8] hw/arm/virt: Use the pvpanic device, Peng Hao, 2018/12/03
- [Qemu-arm] [PATCH V11 8/8] pvpanic : update pvpanic document, Peng Hao, 2018/12/03
- [Qemu-arm] [PATCH V11 7/8] hw/arm/virt: use the configure interface, Peng Hao, 2018/12/03
- Re: [Qemu-arm] [PATCH V11 0/8] add pvpanic mmio support, Peter Maydell, 2018/12/03
Re: [Qemu-arm] [Qemu-devel] [PATCH V11 0/8] add pvpanic mmio support, Daniel P . Berrangé, 2018/12/04
- Re: [Qemu-arm] [Qemu-devel] [PATCH V11 0/8] add pvpanic mmio support, Peter Maydell, 2018/12/04
- Re: [Qemu-arm] [Qemu-devel] [PATCH V11 0/8] add pvpanic mmio support, Paolo Bonzini, 2018/12/04
- Re: [Qemu-arm] [Qemu-devel] [PATCH V11 0/8] add pvpanic mmio support, Peter Maydell, 2018/12/04
- Re: [Qemu-arm] [Qemu-devel] [PATCH V11 0/8] add pvpanic mmio support, Paolo Bonzini, 2018/12/04
- Re: [Qemu-arm] [PATCH V11 0/8] add pvpanic mmio support, Michael S. Tsirkin, 2018/12/04