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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Wed, Oct 7, 2015 at 9:40 AM, Ian Campbell <ian.campbell@xxxxxxxxxx> 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@xxxxxxxx>
>> >
>> > ---
>> >   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?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel