[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/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 <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).
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
