[PATCH 2/2] qemu: Use .hostdevice attribute for usb-host
mprivozn at redhat.com
Thu Oct 1 09:14:17 UTC 2020
On 9/29/20 5:59 PM, Ján Tomko wrote:
> On a Monday in 2020, Michal Privoznik wrote:
>> This originally started as bug 1595525 in which namespaces and
>> libusb used in QEMU were not playing nicely with each other. The
>> problem was that libusb built a cache of USB devices it saw
>> (which was a very limited set because of the namespace) and then
>> expected to receive udev events to keep the cache in sync. But
>> those udev events didn't come because on hotplug when we mknod()
>> devices in the namespace no udev event is generated. And what is
>> worse - libusb failed to open a device that wasn't in the cache.
>> Without going further into what the problem was, libusb added a
>> new API for opening USB devices that avoids using cache which
>> QEMU incorporated and exposes under "hostdevice" attribute.
>> What is even nicer is that QEMU uses qemu_open() for path
>> provided in the attribute and thus FD passing could be used.
>> Except qemu_open() expects so called FD sets instead of `getfd'
>> and these are not implemented in Libvirt, yet.
> Are you looking for `qemuVirCommandGetFDSet`?
Sort of. That handles cmd line and I need monitor wrapper. But it's not
that simple - an FD group can consist of multiple FDs (although I don't
think we are using that now, but maybe we will - for vhost-net), FDs can
be closed individually within a group and if a device using the group is
detached from the guest and cleaned up the FDs within the group are not
closed automatically. So what we would need for hotplug is tracking the
IDs of FD groups and closing them explicitly in device cleanup. Also,
the hotplug would be done in two steps - in the first we would open and
pass FDs to qemu to obtain the group ID so that later - when
constructing the real device JSON we can refer to the FD set.
There is plenty of work to accommodate FDsets for hotplug.
More information about the libvir-list