Re: [PATCH V7 6/7] xl: add usb-assignable-list command

["Christiane Groß" <jg@pfupf.net>]

On 10/07/2015 12:10 PM, George Dunlap wrote:
> On Wed, Oct 7, 2015 at 9:40 AM, Ian Campbell <ian.campbell@citrix.com> wrote:
>> On Tue, 2015-10-06 at 17:55 +0100, George Dunlap wrote:
>>> On 25/09/15 03:11, Chunyan Liu wrote:
>>>> Add xl usb-assignable-list command to list assignable USB devices.
>>>> Assignable USB device means the USB device type is assignable and
>>>> it's not assigned to any guest yet.
>>>>
>>>> Signed-off-by: Chunyan Liu <cyliu@suse.com>
>>>>
>>>> ---
>>>>    Same as "libxl: add libxl_device_usb_assignable_list API" patch,
>>>>    this patch could be sqaushed to previous one. Split because of
>>>>    some dispute. Could be squashed if acceptable, otherwise could
>>>>    be removed.
>>>
>>> I think it's worth pointing out to other reviewers that the
>>> "usb-assignable-list" command introduced here:
>>> 1. Has identical behavior to "xm usb-assignable-list", but
>>> 2. Has different behavior than "xl pci-assignable-list".
>>
>> OOI how does xl pci-assignable-list compare to xm pci-assignable-list.
>
> xm doesn't have such a command -- more on that below.
>
>>
>>> Namely:
>>>
>>> xl pci-assignable-list will list PCI devices which have been detached
>>> from their normal driver and have been assigned to pciback (in
>>> preparation for being attached to a domain).
>>>
>>> This command will list all USB devices in dom0 that are not assigned to
>>> VMs.
>>>
>>> Juergen and I had a long back-and-forth about it around v3.  I thought
>>> having slightly different semantics might be confusing, and Juergen
>>> thought the functionality was important to include.  We didn't really
>>> come to a conclusion and none of the tools maintainers expressed an
>>> opinion.
>>
>> TBH I couldn't follow precisely what that discussion was about, so thanks
>> for your summary. IMHO you both make good points.
>>
>> However given that xend was now removed 2 releases ago I think the time for
>> strictly mimicking xm behaviour purely for the sake of that
>> compatibility/transition has passed.
>>
>> Obviously if the xm interface was fine we shouldn't deviate from it just to
>> be contrary, but similarly if the xm interface was bad in some way or
>> doesn't fit in with the direction xl has taken since the two coexisted then
>> we shouldn't feel bound to follow xm.
>>
>> In this case and at this point in time I think I find the argument that xl
>> subcommands should, where possible, behave similarly to each other more
>> compelling than they should match their xm counterparts. (maybe if we'd
>> been aware of it we would have implemented pci-assignable-list differently,
>> but that ship has sailed).
>>
>> So IMHO xl usb-assignable-list should behave like pci-assignable-list by
>> default.
>
> I don't think that's really suitable.
>
> Let me try to add in a little more detail (trying to keep it as
> concise as possible).
>
> In both pci and usb, devices in dom0 will begin assigned to the normal
> device driver for the device.  In order to assign a device to a guest
> via the PV protocol, the device needs to be detached from its normal
> driver and assigned to {pci,usb}back.
>
> In USB, this has always been done in one step as part of the
> assignment:  when you did "xm usb-attach", xm expected the device to
> be assigned to the normal driver; it would then detach it from the
> current driver, attach it to usbback, and then assign it to the guest.
> The "xl usb-attach" Chunyan has submitted behaves the same way.
>
> In PCI, this has always been done in two steps.  In xm, there was no
> way *with xm* to detach the device from the current driver and attach
> it to pciback: you had to either set kernel parameters so that the
> device was assigned to pciback at boot, or manually frob around with
> sysfs nodes.  "xm pci-attach" expected the device to already be
> assigned to pciback; it would then assign it to the guest.  "xl
> pci-attach" behaves the same way.
>
> To avoid the user having to manually frob around with sysfs nodes, I
> made it possible for xl to do it instaed.  But rather than make "xl
> pci-attach" do everything, I left it in two steps; and the state of
> being attached to pciback but not yet assigned to a VM I called
> "assignable".  So for pci devices, you can use "lspci" to find the
> device you want, then use "pci-assignable-add" to detach it from the
> current driver and attach it to pciback, and then "pci-attach" to
> assign it to a VM.  "pci-assignable-list" will give you the pci
> devices currently in this "assignable" state.  (I wasn't aware of "xm
> usb-assignable-list" when I came up with that command.)
>
> There is also an option, "seize", which will do the whole thing at
> once in "pci-attach"; this is off by default.
>
> The reason I left the two-stage thing for pci devices was that I was
> afraid that setting "seize=1" by default would be too dangerous: it
> would be to easy for a missed keystroke or a typo to bring down the
> system.
>
> For USB, there is no "assignable" stage -- "usb-attach" will take it
> all the way from being assigned to a driver to being assigned to the
> guest.  (You can think of this as pci-attach with "seize=1" always.)
> So making "usb-assignable-list" act like "pci-assignable-list" doesn't
> actually make any sense.
>
>> Now, maybe it should also support some sort of --all or --full or --host
>> option which lists everything, ideally with some indication as to whether
>> they are attached to usbback or not and using syntax which can just be cut
>> -and-pasted into a cfg file (without at least one of those it's just a
>> pointless reimplementation of lsusb).
>>
>> However I think --all/full/host is an optional extra.
>
> Juergen suggested having "usb-list" have an --all option in the v3
> discussion.  If like me you're concerned about confusing people, then
> having --all and --host is probably the best option.
>
> Thoughts?

The main information I'd like to have at my hands is a way to see which
USB devices are available for being attached to a domain. The command
should list the devices in a way that all information related to the
planned use is contained in the output:

- the parameter needed for attaching the device to a domain
- a way to identify the device (e.g. something like the lsusb output)

If this done via an own command or an option of xl usb-list I don't
care.


Juergen