Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-21 Thread Juergen Gross 

On 05/21/2015 01:11 PM, George Dunlap wrote:

On 05/21/2015 11:52 AM, Juergen Gross wrote:

  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.


That's not really an accurate characterization.  I introduced the
concept of assignable because under xm, you had to manually much about
in sysfs yourself to assign the device to pciback before attaching it to
a guest.  So pci-assignable-add takes a device and assigns it to
pciback; pci-attach attaches an assignable device to the guest.
pci-assignable-list lists the devices which have been made
assignable under this new definition.




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.


You seem to have missed in my tone that I think xm usb-assignable-list
behavior is more useful.  I said that xm usb-assignable-list gave you
practical information, and I said that xl pci-assignable-list gives
you about a technical quirk.  I also said that pci-assignable a state
half-way in between being assigned and not assigned, which I personally
think portrays it as rather clunky.


I didn't want to offend you, sorry if you felt that way.


I never claimed that we should make the new usb-*-list command mimic
pci-assignable-list.  What I'm responding to is your claim that they do
similar things, and so implying that it should be OK for them to have
similar names.  They do not do the similar things, and therefore they
must not have similar names.

So, as I said in the previous e-mail:
* I think that it would definitely be useful to have the xm
usb-assignable-list functionality.
* But we cannot give it the same name as the current xl
pci-assignable-list functionality, since they behave differently
* I think assignable is the best name for what xm
usb-assignable-list does; however,
* We have existing users to consider; I think choosing a different name
(like xl usb-available-list) will have the lowest negative impact on
existing users.


There might be existing users who know about xm usb-assignable-list.

OTOH I don't care giving it another name, as long as the functionality
is available.


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-21 Thread George Dunlap 
On 05/21/2015 12:58 PM, Juergen Gross wrote:
 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.

 You seem to have missed in my tone that I think xm usb-assignable-list
 behavior is more useful.  I said that xm usb-assignable-list gave you
 practical information, and I said that xl pci-assignable-list gives
 you about a technical quirk.  I also said that pci-assignable a state
 half-way in between being assigned and not assigned, which I personally
 think portrays it as rather clunky.
 
 I didn't want to offend you, sorry if you felt that way.

Misunderstandings happen -- I certainly misread what people write
sometimes.  It's mildly annoying but no harm done. :-)

 I never claimed that we should make the new usb-*-list command mimic
 pci-assignable-list.  What I'm responding to is your claim that they do
 similar things, and so implying that it should be OK for them to have
 similar names.  They do not do the similar things, and therefore they
 must not have similar names.

 So, as I said in the previous e-mail:
 * I think that it would definitely be useful to have the xm
 usb-assignable-list functionality.
 * But we cannot give it the same name as the current xl
 pci-assignable-list functionality, since they behave differently
 * I think assignable is the best name for what xm
 usb-assignable-list does; however,
 * We have existing users to consider; I think choosing a different name
 (like xl usb-available-list) will have the lowest negative impact on
 existing users.
 
 There might be existing users who know about xm usb-assignable-list.

Yes -- unfortunately something has to give: either we confuse new users
with two names that sound similar but do something different, or we
confuse former xm users by renaming their function, or we confuse
current xl users by renaming their function.  There's badness to be had
whichever one we choose.  I think renaming the xm function is the least
bad of all the options.

 OTOH I don't care giving it another name, as long as the functionality
 is available.

OK -- what about usb-available-list?  Any objections / alternate
suggestions from anyone?

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-21 Thread Juergen Gross 

On 05/21/2015 03:01 PM, George Dunlap wrote:

On 05/21/2015 12:58 PM, Juergen Gross wrote:

There might be existing users who know about xm usb-assignable-list.


Yes -- unfortunately something has to give: either we confuse new users
with two names that sound similar but do something different, or we
confuse former xm users by renaming their function, or we confuse
current xl users by renaming their function.  There's badness to be had
whichever one we choose.  I think renaming the xm function is the least
bad of all the options.


OTOH I don't care giving it another name, as long as the functionality
is available.


OK -- what about usb-available-list?  Any objections / alternate
suggestions from anyone?


Hmm, just another idea:

xl usb-list -a

could list all domains with assigned USB-devices and the currently not
assigned devices as well. This would avoid the need for another command
name. It would even be possible to omit the -a.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-21 Thread George Dunlap 
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 jgr...@suse.com wrote:
 On 05/20/2015 04:20 PM, George Dunlap wrote:

 On Mon, Apr 20, 2015 at 9:12 AM, Juergen Gross jgr...@suse.com
 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 cy...@suse.com
 Signed-off-by: Simon Cao caobosi...@gmail.com
 ---
 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.

Yes, from a pedantic perspective, both will tell you on

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-21 Thread Juergen Gross 

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 jgr...@suse.com wrote:

On 05/20/2015 04:20 PM, George Dunlap wrote:


On Mon, Apr 20, 2015 at 9:12 AM, Juergen Gross jgr...@suse.com
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 cy...@suse.com
Signed-off-by: Simon Cao caobosi...@gmail.com
---
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

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-21 Thread George Dunlap 
On 05/21/2015 11:52 AM, Juergen Gross wrote:
  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.

That's not really an accurate characterization.  I introduced the
concept of assignable because under xm, you had to manually much about
in sysfs yourself to assign the device to pciback before attaching it to
a guest.  So pci-assignable-add takes a device and assigns it to
pciback; pci-attach attaches an assignable device to the guest.
pci-assignable-list lists the devices which have been made
assignable under this new definition.

 
 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.

You seem to have missed in my tone that I think xm usb-assignable-list
behavior is more useful.  I said that xm usb-assignable-list gave you
practical information, and I said that xl pci-assignable-list gives
you about a technical quirk.  I also said that pci-assignable a state
half-way in between being assigned and not assigned, which I personally
think portrays it as rather clunky.

I never claimed that we should make the new usb-*-list command mimic
pci-assignable-list.  What I'm responding to is your claim that they do
similar things, and so implying that it should be OK for them to have
similar names.  They do not do the similar things, and therefore they
must not have similar names.

So, as I said in the previous e-mail:
* I think that it would definitely be useful to have the xm
usb-assignable-list functionality.
* But we cannot give it the same name as the current xl
pci-assignable-list functionality, since they behave differently
* I think assignable is the best name for what xm
usb-assignable-list does; however,
* We have existing users to consider; I think choosing a different name
(like xl usb-available-list) will have the lowest negative impact on
existing users.

 (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. :-)

I think we have that already, actually.  (If not at least we discussed
it.)  But unfortunately that doesn't help us in the current situation,
as the pci-assignable state still exists, and we still need commands
to deal with it.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-21 Thread Juergen Gross 

On 05/21/2015 03:43 PM, George Dunlap wrote:

On 05/21/2015 02:08 PM, Juergen Gross wrote:

On 05/21/2015 03:01 PM, George Dunlap wrote:

On 05/21/2015 12:58 PM, Juergen Gross wrote:

There might be existing users who know about xm usb-assignable-list.


Yes -- unfortunately something has to give: either we confuse new users
with two names that sound similar but do something different, or we
confuse former xm users by renaming their function, or we confuse
current xl users by renaming their function.  There's badness to be had
whichever one we choose.  I think renaming the xm function is the least
bad of all the options.


OTOH I don't care giving it another name, as long as the functionality
is available.


OK -- what about usb-available-list?  Any objections / alternate
suggestions from anyone?


Hmm, just another idea:

xl usb-list -a

could list all domains with assigned USB-devices and the currently not
assigned devices as well. This would avoid the need for another command
name. It would even be possible to omit the -a.


That works for me too, I guess.

Can I suggest, though, that work on that functionality be detached from
getting the core pvusb functionality in?  I can't really effectively do
the qemu side until it is in due to the cost of rebasing, and I would
really like to have both in for 4.6 if possible.


Sure.

I hope to have my pvusb backend in qemu ready until then, too. :-)
In case the performance isn't too bad I'll have to make some changes to
the libxl part as well, but this will result in some deletions only
(qemu will do driver unbinding, this will no longer be required to be
done by libxl).


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-21 Thread George Dunlap 
On 05/21/2015 02:55 PM, Juergen Gross wrote:
 On 05/21/2015 03:43 PM, George Dunlap wrote:
 On 05/21/2015 02:08 PM, Juergen Gross wrote:
 On 05/21/2015 03:01 PM, George Dunlap wrote:
 On 05/21/2015 12:58 PM, Juergen Gross wrote:
 There might be existing users who know about xm usb-assignable-list.

 Yes -- unfortunately something has to give: either we confuse new users
 with two names that sound similar but do something different, or we
 confuse former xm users by renaming their function, or we confuse
 current xl users by renaming their function.  There's badness to be had
 whichever one we choose.  I think renaming the xm function is the least
 bad of all the options.

 OTOH I don't care giving it another name, as long as the functionality
 is available.

 OK -- what about usb-available-list?  Any objections / alternate
 suggestions from anyone?

 Hmm, just another idea:

 xl usb-list -a

 could list all domains with assigned USB-devices and the currently not
 assigned devices as well. This would avoid the need for another command
 name. It would even be possible to omit the -a.

 That works for me too, I guess.

 Can I suggest, though, that work on that functionality be detached from
 getting the core pvusb functionality in?  I can't really effectively do
 the qemu side until it is in due to the cost of rebasing, and I would
 really like to have both in for 4.6 if possible.
 
 Sure.
 
 I hope to have my pvusb backend in qemu ready until then, too. :-)
 In case the performance isn't too bad I'll have to make some changes to
 the libxl part as well, but this will result in some deletions only
 (qemu will do driver unbinding, this will no longer be required to be
 done by libxl).

Right -- just like it's not necessary when qemu does emulated device
passthrough. :-)

Out of curiosity, what's the motivation for doing pvusb in qemu?  Will
there be an option, for instance, to switch usb devices from emulated
over to pv when the magic port is written to (as is done with disks 
network currently)?

 -George



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-21 Thread Juergen Gross 

On 05/21/2015 04:00 PM, George Dunlap wrote:

On 05/21/2015 02:55 PM, Juergen Gross wrote:

On 05/21/2015 03:43 PM, George Dunlap wrote:

On 05/21/2015 02:08 PM, Juergen Gross wrote:

On 05/21/2015 03:01 PM, George Dunlap wrote:

On 05/21/2015 12:58 PM, Juergen Gross wrote:

There might be existing users who know about xm usb-assignable-list.


Yes -- unfortunately something has to give: either we confuse new users
with two names that sound similar but do something different, or we
confuse former xm users by renaming their function, or we confuse
current xl users by renaming their function.  There's badness to be had
whichever one we choose.  I think renaming the xm function is the least
bad of all the options.


OTOH I don't care giving it another name, as long as the functionality
is available.


OK -- what about usb-available-list?  Any objections / alternate
suggestions from anyone?


Hmm, just another idea:

xl usb-list -a

could list all domains with assigned USB-devices and the currently not
assigned devices as well. This would avoid the need for another command
name. It would even be possible to omit the -a.


That works for me too, I guess.

Can I suggest, though, that work on that functionality be detached from
getting the core pvusb functionality in?  I can't really effectively do
the qemu side until it is in due to the cost of rebasing, and I would
really like to have both in for 4.6 if possible.


Sure.

I hope to have my pvusb backend in qemu ready until then, too. :-)
In case the performance isn't too bad I'll have to make some changes to
the libxl part as well, but this will result in some deletions only
(qemu will do driver unbinding, this will no longer be required to be
done by libxl).


Right -- just like it's not necessary when qemu does emulated device
passthrough. :-)

Out of curiosity, what's the motivation for doing pvusb in qemu?  Will
there be an option, for instance, to switch usb devices from emulated
over to pv when the magic port is written to (as is done with disks 
network currently)?


Doing it in qemu was a request when I sent my patches to do it in the
kernel. :-)

Doing pvusb in qemu really has advantages. Just by using a newer Xen
you'll have pvusb backend support in Dom0. No need for a kernel update.

Up to now I have no plan doing a switch of emulated USB devices to pv.
TBH I don't think this is an important scenario. In case someone wants
to add support for it I won't object. :-)


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-21 Thread George Dunlap 
On 05/21/2015 02:08 PM, Juergen Gross wrote:
 On 05/21/2015 03:01 PM, George Dunlap wrote:
 On 05/21/2015 12:58 PM, Juergen Gross wrote:
 There might be existing users who know about xm usb-assignable-list.

 Yes -- unfortunately something has to give: either we confuse new users
 with two names that sound similar but do something different, or we
 confuse former xm users by renaming their function, or we confuse
 current xl users by renaming their function.  There's badness to be had
 whichever one we choose.  I think renaming the xm function is the least
 bad of all the options.

 OTOH I don't care giving it another name, as long as the functionality
 is available.

 OK -- what about usb-available-list?  Any objections / alternate
 suggestions from anyone?
 
 Hmm, just another idea:
 
 xl usb-list -a
 
 could list all domains with assigned USB-devices and the currently not
 assigned devices as well. This would avoid the need for another command
 name. It would even be possible to omit the -a.

That works for me too, I guess.

Can I suggest, though, that work on that functionality be detached from
getting the core pvusb functionality in?  I can't really effectively do
the qemu side until it is in due to the cost of rebasing, and I would
really like to have both in for 4.6 if possible.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-20 Thread George Dunlap 
On Mon, Apr 20, 2015 at 9:12 AM, Juergen Gross jgr...@suse.com 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 cy...@suse.com
 Signed-off-by: Simon Cao caobosi...@gmail.com
 ---
 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?

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-20 Thread George Dunlap 
On Sun, Apr 19, 2015 at 4:50 AM, Chunyan Liu cy...@suse.com 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 cy...@suse.com
 Signed-off-by: Simon Cao caobosi...@gmail.com

Thanks, Chunyan.  The interface looks good to me, and a skim through
the code doesn't turn up any obvious problems.  Someone more familiar
with the libxl coding conventions will have to give it a stricter
review.

I'll wait on the ack until we've discussed Juergen's point.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-20 Thread George Dunlap 
On Wed, May 20, 2015 at 3:23 PM, George Dunlap
george.dun...@eu.citrix.com wrote:
 On Sun, Apr 19, 2015 at 4:50 AM, Chunyan Liu cy...@suse.com 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 cy...@suse.com
 Signed-off-by: Simon Cao caobosi...@gmail.com

 Thanks, Chunyan.  The interface looks good to me, and a skim through
 the code doesn't turn up any obvious problems.  Someone more familiar
 with the libxl coding conventions will have to give it a stricter
 review.

Actually, sorry to take this back.  I looked at what I wrote in v2 of
the series, and I think what I suggested there was better. :-)

I pointed out that most devices -- disk, vif, pci, c -- take the same
thing in their command-line arguments as you put in the config file.
They have parse_disk_config(), parse_vif_config(), and
xlu_parse_bdf(), each of which are called from both
parse_config_data() and the respective add commands.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-20 Thread George Dunlap 
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 jgr...@suse.com wrote:
 On 05/20/2015 04:20 PM, George Dunlap wrote:

 On Mon, Apr 20, 2015 at 9:12 AM, Juergen Gross jgr...@suse.com 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 cy...@suse.com
 Signed-off-by: Simon Cao caobosi...@gmail.com
 ---
 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.

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.

#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@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-20 Thread George Dunlap 
On Sun, Apr 19, 2015 at 4:50 AM, Chunyan Liu cy...@suse.com 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

One more nit: this shuold be ports=8, not num_ports=8.

(It looks like it's only wrong here in the description; it's
consistently ports throughout the rest of this patch and the next
one.)

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-20 Thread Juergen Gross 

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 jgr...@suse.com wrote:

On 05/20/2015 04:20 PM, George Dunlap wrote:


On Mon, Apr 20, 2015 at 9:12 AM, Juergen Gross jgr...@suse.com 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 cy...@suse.com
Signed-off-by: Simon Cao caobosi...@gmail.com
---
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@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-20 Thread Juergen Gross 

On 05/20/2015 04:20 PM, George Dunlap wrote:

On Mon, Apr 20, 2015 at 9:12 AM, Juergen Gross jgr...@suse.com 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 cy...@suse.com
Signed-off-by: Simon Cao caobosi...@gmail.com
---
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.

Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-20 Thread George Dunlap 
On Wed, May 20, 2015 at 3:33 PM, Juergen Gross jgr...@suse.com wrote:
 On 05/20/2015 04:20 PM, George Dunlap wrote:

 On Mon, Apr 20, 2015 at 9:12 AM, Juergen Gross jgr...@suse.com 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 cy...@suse.com
 Signed-off-by: Simon Cao caobosi...@gmail.com
 ---
 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.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-05-20 Thread Juergen Gross 

On 05/20/2015 04:41 PM, George Dunlap wrote:

On Wed, May 20, 2015 at 3:33 PM, Juergen Gross jgr...@suse.com wrote:

On 05/20/2015 04:20 PM, George Dunlap wrote:


On Mon, Apr 20, 2015 at 9:12 AM, Juergen Gross jgr...@suse.com 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 cy...@suse.com
Signed-off-by: Simon Cao caobosi...@gmail.com
---
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.


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-04-20 Thread Chun Yan Liu 


 On 4/20/2015 at 04:12 PM, in message 5534b4d8.4010...@suse.com, Juergen 
 Gross
jgr...@suse.com 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 cy...@suse.com 
  Signed-off-by: Simon Cao caobosi...@gmail.com 
  --- 
  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. 

Ian  George, how do you think?

  
 * add documentation 
  
docs/man/xl.pod.1 |  38  
tools/libxl/xl.h  |   5 + 
tools/libxl/xl_cmdimpl.c  | 238  
 ++ 
tools/libxl/xl_cmdtable.c |  25 + 
4 files changed, 306 insertions(+) 
  
 ... 
  --- a/tools/libxl/xl_cmdimpl.c 
  +++ b/tools/libxl/xl_cmdimpl.c 
  @@ -3196,6 +3196,244 @@ int main_cd_insert(int argc, char **argv) 
return 0; 
} 
  
  +static void usbinfo_print(libxl_device_usb *usbs, int num) { 
  +int i; 
  +if ( usbs == NULL ) 
  
 Coding style. 
  
  + return; 
  +for (i = 0; i  num; i++) { 
  +libxl_usbinfo usbinfo; 
  +libxl_usbinfo_init(usbinfo); 
  + 
  +if (usbs[i].port ) 
  
 Coding style. 
  
  +printf(  Port %d:, usbs[i].port); 
  +if (!libxl_device_usb_getinfo(ctx, usbs[i].busid, usbinfo)) { 
  +printf( Bus %03x Device %03x: ID %04x:%04x %s %s\n, 
  +usbinfo.busnum, usbinfo.devnum, usbinfo.idVendor, 
  +usbinfo.idProduct, usbinfo.manuf, usbinfo.prod); 
  +} 
  +libxl_usbinfo_dispose(usbinfo); 
  +} 
  +} 
  + 
  +int main_usbctrl_attach(int argc, char **argv) 
  +{ 
  +uint32_t domid; 
  +int opt; 
  +char *oparg; 
  +libxl_device_usbctrl usbctrl; 
  + 
  +SWITCH_FOREACH_OPT(opt, , NULL, usb-ctrl-attach, 1) { 
  +/* No options */ 
  +} 
  + 
  +domid = find_domain(argv[optind++]); 
  + 
  +libxl_device_usbctrl_init(usbctrl); 
  + 
  +while (argc  optind) { 
  +if (MATCH_OPTION(version, argv[optind], oparg)) { 
  +usbctrl.version = atoi(oparg); 
  +} else if (MATCH_OPTION(ports, argv[optind], oparg)) { 
  +usbctrl.ports = atoi(oparg); 
  +} else { 
  +fprintf(stderr, unrecognized argument `%s'\n, argv[optind]); 
  +exit(-1); 
  
 I don't think this is the preferred way of error handling. 
 Returning with an appropriate error code would be better. 
  
 Same applies to all other uses of exit() below. 
  
  +} 
  +optind++; 
  +} 
  + 
  +if (dryrun_only) { 
  +   char* json = libxl_device_usbctrl_to_json(ctx, usbctrl); 
  +   printf(usb controller: %s\n, json); 
  +   free(json); 
  +   libxl_device_usbctrl_dispose(usbctrl); 
  +   if (ferror(stdout) || fflush(stdout)) { 
  +   perror(stdout); 
  +   exit(-1); 
  +   } 
  +   return 0; 
  +} 
  + 
  +if (libxl_device_usbctrl_add(ctx, domid, usbctrl, 0)) { 
  +fprintf(stderr, libxl_device_usbctrl_add failed.\n); 
  +exit(-1); 
  +} 
  +libxl_device_usbctrl_dispose(usbctrl); 
  +return 0; 
  +} 
  + 
  +int main_usbctrl_detach(int argc, char **argv) 
  +{ 
  +uint32_t domid; 
  +int opt; 
  +libxl_device_usbctrl usbctrl; 
  + 
  +SWITCH_FOREACH_OPT(opt, , NULL, usb-ctrl-detach, 2) { 
  +/* No options */ 
  +} 
  + 
  +domid = find_domain(argv[optind]); 
  + 
  +libxl_device_usbctrl_init(usbctrl); 
  +usbctrl.devid = atoi(argv[optind+1]); 
  + 
  +if(libxl_device_usbctrl_remove(ctx, domid, usbctrl, 0)) { 
  
 Coding style. 
  
  +fprintf(stderr, libxl_device_usbctrl_add failed.\n); 
  +exit(-1); 
  +} 
  +libxl_device_usbctrl_dispose(usbctrl); 
  +return 0; 
  + 
  +} 
  
 Juergen 
  
  
 ___

Re: [Xen-devel] [PATCH V3 4/6] xl: add pvusb commands

2015-04-20 Thread Juergen Gross 

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 cy...@suse.com
Signed-off-by: Simon Cao caobosi...@gmail.com
---
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.


   * add documentation

  docs/man/xl.pod.1 |  38 
  tools/libxl/xl.h  |   5 +
  tools/libxl/xl_cmdimpl.c  | 238 ++
  tools/libxl/xl_cmdtable.c |  25 +
  4 files changed, 306 insertions(+)


...

--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3196,6 +3196,244 @@ int main_cd_insert(int argc, char **argv)
  return 0;
  }

+static void usbinfo_print(libxl_device_usb *usbs, int num) {
+int i;
+if ( usbs == NULL )


Coding style.


+ return;
+for (i = 0; i  num; i++) {
+libxl_usbinfo usbinfo;
+libxl_usbinfo_init(usbinfo);
+
+if (usbs[i].port )


Coding style.


+printf(  Port %d:, usbs[i].port);
+if (!libxl_device_usb_getinfo(ctx, usbs[i].busid, usbinfo)) {
+printf( Bus %03x Device %03x: ID %04x:%04x %s %s\n,
+usbinfo.busnum, usbinfo.devnum, usbinfo.idVendor,
+usbinfo.idProduct, usbinfo.manuf, usbinfo.prod);
+}
+libxl_usbinfo_dispose(usbinfo);
+}
+}
+
+int main_usbctrl_attach(int argc, char **argv)
+{
+uint32_t domid;
+int opt;
+char *oparg;
+libxl_device_usbctrl usbctrl;
+
+SWITCH_FOREACH_OPT(opt, , NULL, usb-ctrl-attach, 1) {
+/* No options */
+}
+
+domid = find_domain(argv[optind++]);
+
+libxl_device_usbctrl_init(usbctrl);
+
+while (argc  optind) {
+if (MATCH_OPTION(version, argv[optind], oparg)) {
+usbctrl.version = atoi(oparg);
+} else if (MATCH_OPTION(ports, argv[optind], oparg)) {
+usbctrl.ports = atoi(oparg);
+} else {
+fprintf(stderr, unrecognized argument `%s'\n, argv[optind]);
+exit(-1);


I don't think this is the preferred way of error handling.
Returning with an appropriate error code would be better.

Same applies to all other uses of exit() below.


+}
+optind++;
+}
+
+if (dryrun_only) {
+   char* json = libxl_device_usbctrl_to_json(ctx, usbctrl);
+   printf(usb controller: %s\n, json);
+   free(json);
+   libxl_device_usbctrl_dispose(usbctrl);
+   if (ferror(stdout) || fflush(stdout)) {
+   perror(stdout);
+   exit(-1);
+   }
+   return 0;
+}
+
+if (libxl_device_usbctrl_add(ctx, domid, usbctrl, 0)) {
+fprintf(stderr, libxl_device_usbctrl_add failed.\n);
+exit(-1);
+}
+libxl_device_usbctrl_dispose(usbctrl);
+return 0;
+}
+
+int main_usbctrl_detach(int argc, char **argv)
+{
+uint32_t domid;
+int opt;
+libxl_device_usbctrl usbctrl;
+
+SWITCH_FOREACH_OPT(opt, , NULL, usb-ctrl-detach, 2) {
+/* No options */
+}
+
+domid = find_domain(argv[optind]);
+
+libxl_device_usbctrl_init(usbctrl);
+usbctrl.devid = atoi(argv[optind+1]);
+
+if(libxl_device_usbctrl_remove(ctx, domid, usbctrl, 0)) {


Coding style.


+fprintf(stderr, libxl_device_usbctrl_add failed.\n);
+exit(-1);
+}
+libxl_device_usbctrl_dispose(usbctrl);
+return 0;
+
+}


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel