[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 10:40 AM, Ian Campbell 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.

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).

Assigning a PCI device to pciback is a necessary step to be able to
attach it to a domain.

This command will list all USB devices in dom0 that are not assigned to
VMs.

Attaching a USB device to a domain works by detaching it from it's
normal driver and attaching it to the pvUSB backend. And this backend
is per domain (qemu), so it's not possible to prepare this step by
attaching the device to "the" pvUSB backend.

And just detaching the device from it's driver is no solution either,
as the driver can grab it again at any time, as all drivers are queried
for all unassigned devices when a new USB device shows up.

And you'd need another command to move a USB-device to the assignable
state.

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.

As stated above: this will have weird consequences or you need some kind
of placeholder backend just for this functionality. Is this really worth
the effort?


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®.