From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Christiane_Gro=c3=9f?= Subject: Re: [PATCH V7 6/7] xl: add usb-assignable-list command Date: Wed, 7 Oct 2015 12:35:33 +0200 Message-ID: <5614F575.5050305@pfupf.net> References: <1443147102-6471-1-git-send-email-cyliu@suse.com> <1443147102-6471-7-git-send-email-cyliu@suse.com> <5613FCE7.5080002@citrix.com> <1444207207.5302.269.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , Ian Campbell Cc: Wei Liu , Ian Jackson , Chunyan Liu , George Dunlap , Jim Fehlig , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 10/07/2015 12:10 PM, George Dunlap wrote: > On Wed, Oct 7, 2015 at 9: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 >>>> >>>> --- >>>> 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