[PATCH] pci: Refuse to hotplug PCI Devices when the Guest OS is not ready
dgibson at redhat.com
Mon Oct 26 06:38:57 UTC 2020
On Fri, 23 Oct 2020 19:27:55 +0200
Igor Mammedov <imammedo at redhat.com> wrote:
> On Fri, 23 Oct 2020 11:54:40 -0400
> "Michael S. Tsirkin" <mst at redhat.com> wrote:
> > Rather than adding_device_allowed, something like "query slot"
> > might be helpful for debugging. That would help user figure out
> > e.g. why isn't device visible without any races.
> Would be new command useful tough? What we end up is broken guest
> (if I read commit message right) and a user who has no idea if
> device_add was successful or not.
> So what user should do in this case
> - wait till it explodes?
> - can user remove it or it would be stuck there forever?
> - poll slot before hotplug, manually?
> (if this is the case then failing device_add cleanly doesn't sound bad,
> it looks similar to another error we have "/* Check if hot-plug is disabled on the slot */"
> in pcie_cap_slot_pre_plug_cb)
> CCing libvirt, as it concerns not only QEMU.
> > I think we want QEMU management interface to be reasonably
> > abstract and agnostic if possible. Pushing knowledge of hardware
> > detail to management will just lead to pain IMHO.
> > We supported device_add which practically never fails for years,
> For CPUs and RAM, device_add can fail so maybe management is also
> prepared to handle errors on PCI hotplug path.
There can be unarguable reasons for PCI hotplug to fail as well
(attempting to plug to a bus that can't support it for one). The
difference here is that it's a failure that we expect to be transitory.
David Gibson <dgibson at redhat.com>
Principal Software Engineer, Virtualization, Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the libvir-list