From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH V3 4/6] xl: add pvusb commands Date: Thu, 21 May 2015 05:35:08 +0200 Message-ID: <555D526C.4090603@suse.com> References: <1429415452-6161-1-git-send-email-cyliu@suse.com> <1429415452-6161-5-git-send-email-cyliu@suse.com> <5534B4D8.4010109@suse.com> <555C9B3A.6000906@suse.com> <555CA04F.20705@suse.com> <555CA77F.9030509@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <555CA77F.9030509@eu.citrix.com> 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 Cc: Lars Kurth , Wei Liu , Ian Campbell , Chunyan Liu , "xen-devel@lists.xen.org" , Ian Jackson , Simon Cao List-Id: xen-devel@lists.xenproject.org On 05/20/2015 05:25 PM, George Dunlap wrote: > On 05/20/2015 03:55 PM, Juergen Gross wrote: >> On 05/20/2015 04:41 PM, George Dunlap wrote: >>> On Wed, May 20, 2015 at 3:33 PM, Juergen Gross wrote: >>>> On 05/20/2015 04:20 PM, George Dunlap wrote: >>>>> >>>>> On Mon, Apr 20, 2015 at 9:12 AM, Juergen Gross wrote: >>>>>> >>>>>> On 04/19/2015 05:50 AM, Chunyan Liu wrote: >>>>>>> >>>>>>> >>>>>>> Add pvusb commands: usb-ctrl-attach, usb-ctrl-detach, usb-list, >>>>>>> usb-attach and usb-detach. >>>>>>> >>>>>>> To attach a usb device to guest through pvusb, one could follow >>>>>>> following example: >>>>>>> >>>>>>> #xl usb-ctrl-attach test_vm version=1 num_ports=8 >>>>>>> >>>>>>> #xl usb-list test_vm >>>>>>> will show the usb controllers and port usage under the domain. >>>>>>> >>>>>>> #xl usb-attach test_vm 1.6 >>>>>>> will find the first usable controller:port, and attach usb >>>>>>> device whose bus address is 1.6 (busnum is 1, devnum is 6) >>>>>>> to it. One could also specify which and which >>>>>>> . >>>>>>> >>>>>>> #xl usb-detach test_vm 1.6 >>>>>>> >>>>>>> #xl usb-ctrl-detach test_vm dev_id >>>>>>> will destroy the controller with specified dev_id. Dev_id >>>>>>> can be traced in usb-list info. >>>>>>> >>>>>>> Signed-off-by: Chunyan Liu >>>>>>> Signed-off-by: Simon Cao >>>>>>> --- >>>>>>> Changes to v2: >>>>>>> * use bus.addr as user interface instead of busid in >>>>>>> usb-attach|detach >>>>>>> * remove usb-assignable-list interface >>>>>> >>>>>> >>>>>> >>>>>> Why? While lsusb in combination with xl usb-list for each domain will >>>>>> give the same information, having to iterate through all domains >>>>>> can be >>>>>> quite annoying. >>>>>> >>>>>> An alternative would be to accept omitting the domain for xl usb-list >>>>>> and list all domains with assigned usb devices in this case. >>>>> >>>>> >>>>> I don't understand what information it is that you want. Do you want >>>>> a list of devices *not already assigned* to domains? >>>> >>>> >>>> Yes. >>> >>> ...and why do you need that, instead of just remembering what you'd >>> assigned to whom? >>> >>> We don't really have the equivalent for pci either. That is, if a >>> device shows up in "lspci" but not in "pci-assignable-list", that may >>> be either because 1) I hasn't yet been assigned to pciback (and this >>> is available to be assigned to a domain), or 2) because it's already >>> been assigned to a domain. Someone new coming to the system would >>> need to check all VMs to see which devices hadn't yet been assigned. >> >> So this is a problem of pci-assignable-list, which isn't present for >> USB devices. Any USB device not already assigned to a VM would be listed >> as before with "xm usb-assignable-list". >> >> Additionally all systems support hotplug of USB devices - the list of >> available USB-devices can change rather often. If you unplug e.g. a >> memory stick which has been assigned to a VM and stick it in again it >> might show up under a different address and has to be reassigned. >> Remembering having it already assigned won't help in this case as much >> as a simple command to list the devices ready for assignment. > > OK. :-) Yes, I can see that having USB devices disappear and appear as > a different bus:host would make such a command particularly useful. > > But then we have the problem that "assignable" means something different > in each case. In pci-assignable-list, it means "Devices which have been > assigned to pciback but not yet been attached to a domain". In your > suggested command, it means "Devices which have not yet been assigned > either to pvusbback or to a domain." For USB devices there isn't such an action as "assign it to pvusbback". You just assign a USB device to a domain. One command, no steps to prepare that action (besides the possibility to define a USB controller first). > When I introduced pci-assignable-* I didn't realize that "assignable" > was already in one of the xm commands with a different meaning. I > introduced it because until that point, neither xm nor xl had a way of > attaching a device to pciback. > > So we basically have three options: > 1. Keep both names the same > 2. Rename usb-assignable-list to something else (usb-available-list?) > 3. Rename pci-assignable-* to something else > > #1 would be the most backwards-compatible. But I think it's really bad > going forward, since you have two commands that look like they should do > similar things that don't. Actually they do. :-) Juergen > > #2 and #3 would both solve the potential confusion issue. > > #2 would be the easiest on current xl users. It's a bit annoying > interface-wise going forward, since "assignable" is probably the best > word for what Juergen wants; and it's not 100% backwards-compatible with > the previous xm usb commands. > > #3 would give us probably the most consistent naming thing going > forward, but would be a pretty major breakage for current xl users. > > I'm inclined to suggest #2 as the best balance between not disrupting > current users and not confusing future users. > > Wei / Ian, any opinions? > > -George > >