On Fri, 23 Oct 2020 19:27:55 +0200 Igor Mammedov <imammedo@xxxxxxxxxx> wrote: > On Fri, 23 Oct 2020 11:54:40 -0400 > "Michael S. Tsirkin" <mst@xxxxxxxxxx> 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@xxxxxxxxxx> Principal Software Engineer, Virtualization, Red Hat
Attachment:
pgpzBQMsVYWv6.pgp
Description: OpenPGP digital signature
