[libvirt] [RFC] On present using dummy hostdev usb device

[Roman Kagan]

On Fri, Aug 30, 2019 at 04:19:23PM +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 30, 2019 at 05:08:52PM +0200, Michal Privoznik wrote:
> > On 8/30/19 2:30 PM, Roman Kagan wrote:
> > > On Fri, Aug 30, 2019 at 10:09:06AM +0100, Daniel P. Berrangé wrote:
> > > > On Fri, Aug 30, 2019 at 08:44:03AM +0000, Nikolay Shirokovskiy wrote:
> > > > > Hi, all!
> > > > > 
> > > > >    We use an interesting approach when starting/migrating/etc domain with usb
> > > > > hostdev with startupPolicy=optional. We add qemu usb-host device with
> > > > > missing hostaddr/hostbus parameters (dummy device). I guess there are
> > > > > 2 reasons why we do it. First without dummy device migration will fail as
> > > > > described in [1]. Second is an interesting property of dummy device that
> > > > > qemu starts to monitor for attaching of usb devices and binds the first
> > > > > attached to node to the dummy device. So one can start a domain with
> > > > > missing hostdev and attach it later or migrate a domain then detach
> > > > > hostdev on source and attach it on destination. But as qemu binds the
> > > > > first attached device this is not reliable, to say the least. And after
> > > > > all this does not work if domain uses distinct mount namespace which
> > > > > is default.
> > > > 
> > > > Even without mount namespaces, it should fail as QEMU is running  non-root
> > > > and libvirt won't have granted access to any host USB devices in /dev, and
> > > > also SELinux policy will forbid this.
> > > 
> > > Right, but the case with mount namespaces is particularly problematic:
> > > if the device open fails due to missing device node, libusb removes the
> > > device from its internal device list.  This results in the following
> > > scenario:
> > > 
> > > - libvirt adds a dummy usb-host device to QEMU in place of a missing
> > >    device
> > > 
> > > - QEMU (via libusb) installs a watch for udev add events
> > > 
> > > - the physical device is plugged into the host
> > > 
> > > - QEMU detects the addition of the device and, since the dummy device
> > >    matches everything, tries to open it
> > > 
> > > - by this time libvirt may have not created a device node in QEMU's
> > >    mount namespace, so the open fails due to missing device node, and
> > >    libusb removes the device from its internal list
> > > 
> > > - libvirt removes the dummy usb-host device and adds the actual usb-host
> > >    device
> > > 
> > > - QEMU fails to open it because it's no longer seen by libusb
> > 
> > There is a bug filed against libusb exactly for this:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1595525
> > 
> > BTW: you don't have to migrate, it's sufficient to start a domain with a
> > missing USB and startupPolicy='optional' and then physically plug it into
> > the host and then try to hotplug it into the domain.
> 
> AFAIR, the startupPolicy=optional was never really intended to allow
> for the device to be dynamically added after startup. It was only
> trying drop the device if it didn't exist at startup.
> 
> If we do want a way to dynamically add after startup, then libvirt itself
> would have to monitor the USB devices on the host, and then perform QMP
> commands to hot-add to QEMU.

This is actually what Nikolay was trying to achieve with his patchset
(https://www.redhat.com/archives/libvir-list/2019-August/msg01413.html).
Is this a NAK to it, with a suggestion that it's the upper layer's
responsibility?

Thanks,
Roman.