[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands
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 <jgross@xxxxxxxx> wrote:
On 05/20/2015 04:20 PM, George Dunlap wrote:
On Mon, Apr 20, 2015 at 9:12 AM, Juergen Gross <jgross@xxxxxxxx> 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 <controller> and which
<port>.
#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 <cyliu@xxxxxxxx>
Signed-off-by: Simon Cao <caobosimon@xxxxxxxxx>
---
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
