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

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.