[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On 8/30/19 5:19 PM, 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.

Sure, I'm not saying that. That's why I'm saying explicitly you need to
hotplug the device that was misssing. I'm only supporting our case of
not adding dummy device to libvirt since there's a bug filed against
libusb that exhibits same symptoms. Perhaps I should have said that more
clearly.

Michal


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]