On Fri, 23 Oct 2020 19:27:55 +0200
Igor Mammedov <imammedo(a)redhat.com> wrote:
On Fri, 23 Oct 2020 11:54:40 -0400
"Michael S. Tsirkin" <mst(a)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(a)redhat.com>
Principal Software Engineer, Virtualization, Red Hat