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 12:52:14 +0200 Message-ID: <555DB8DE.50903@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> <555D526C.4090603@suse.com> <555DB578.8070902@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: <555DB578.8070902@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/21/2015 12:37 PM, George Dunlap wrote: > On 05/21/2015 04:35 AM, Juergen Gross wrote: >> 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). > > You can do the same thing (now) for pci devices, by setting "seize=1" in > the device spec (which will cause xl to first assign them to pciback, > then to the guest, just as the usb code does now). > >> >>> 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. :-) > > Actually, they don't. :-) > > From your description, "xm usb-assignable-list" would list *all* USB > devices on the system which were available to be assigned to a guest. > > "xl pci-assignable-list" does *not* list all PCI devices on a system > which are available to be assigned. It lists the ones which can be > assigned without the "seize=1" parameter -- the ones you've already done > something with. It won't tell you about the other devices on the system > which have not yet been assigned to pciback. So "xl pci-assignable-list" is suppressing some of the PCI devices which in theory could be assigned. I don't think this "weird" behaviour should be mimicked by "xl usb-assignable-list". > Yes, from a pedantic perspective, both will tell you on which devices > you can run "X-attach" without any extra arguments. But from a > practical perspective, "xm usb-assignable-list" tells you something > practical about the state of devices on the whole system; and "xl > pci-assignable-list" tells you a technical quirk about devices are in a > half-way state between not being assigned and actually being assigned. I can't believe you are suggesting to use "a technical quirk" as a good example for future development. Just because a user interface isn't perfect shouldn't result in other interfaces to behave in the same imperfect way. > (I'm about 45% of the opinion that we should make pci behave like the > proposed USB patches -- i.e., make seize=1 the default, and just > deprecate the whole "pci-assignable" state altogether. My only > hesitation is that it removes one level of safety check against doing > something like unplugging the host's main disk controller or something.) You could add a configuration item in xl.conf for setting the default behaviour, defaulting to "default_seize=1". :-) Juergen