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

[Christiane Groà <jg@xxxxxxxxx>]

On 10/07/2015 12:10 PM, George Dunlap wrote:
> 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?
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

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