Re: [Xen-devel] [PATCH V7 6/7] xl: add usb-assignable-list command

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 07/10/15 12:09, Ian Campbell wrote:
> On Wed, 2015-10-07 at 11:10 +0100, George Dunlap wrote:
> 
>>> So IMHO xl usb-assignable-list should behave like pci-assignable-list by
>>> default.
>>
>> I don't think that's really suitable.
> 
> Then I'm terribly confused because I thought that is what you were
> initially advocating.

I think in v3 I was trying to come up with a different name
(usb-available-list or something); but my main point was that it
*shouldn't* be named similarly but have different functionality.

As I said, for this am I was ready to just let it slide; I just wanted
to make sure other people knew what was being let slide. :-)

> 
> [...]
> 
>> For USB, there is no "assignable" stage -- "usb-attach" will take it
>> all the way from being assigned to a driver to being assigned to the
>> guest.  (You can think of this as pci-attach with "seize=1" always.)
>> So making "usb-assignable-list" act like "pci-assignable-list" doesn't
>> actually make any sense.
> 
> Thanks. Jeurgen has also explained this.
> 
> Do you agree that adding a dummy usbback driver just for the purposes of
> adding this extra "assignable" state doesn't make sense?

Yes, I agree.

>>> Now, maybe it should also support some sort of --all or --full or --host
>>> option which lists everything, ideally with some indication as to whether
>>> they are attached to usbback or not and using syntax which can just be cut
>>> -and-pasted into a cfg file (without at least one of those it's just a
>>> pointless reimplementation of lsusb).
>>>
>>> However I think --all/full/host is an optional extra.
>>
>> Juergen suggested having "usb-list" have an --all option in the v3
>> discussion.  If like me you're concerned about confusing people, then
>> having --all and --host is probably the best option.
>>
>> Thoughts?
> 
> If there is no assignable state in usb then I guess I don't really
> understand what usb-list-assignable would even be for, so I don't really
> understand why anyone is arguing what semantics it should have (my initial
> reply was predicated on this state existing and it therefore being useful
> to discuss how the command should behave).
> 
> Given that doing something with usb-list seems most plausible _if_ we need
> some sort of thing like that at all.
> 
> What would "usb-list --all" add over and above using lsusb?
> 
> I take it that as things stand in patch #5:
>     # xl usb-list <vm>
> will list the usb devices attached to <vm> and that:
>     # xl usb-list
> will list the usb devices attached to every vm, is that
> correct?
> 
> So the idea would then be to add some way of listing the devices not included 
> in "xl usb-list", which are notionally attached to dom0, but via physical USB 
> and not PV usb.

The "usb-assignable-list" that Chunyan has submitted will give you a
list of all dom0 USB devices that have not yet been assigned to a guest.
 It should be basically equivalent to "lsusb", except that it filters
out devices which have already been assigned to VMs.

In the e-mail you respond to, I was suggesting that

# xl usb-list --all

would show you usb devices attached to every VM, and also USB devices
attached to no VM, and that

# xl usb-list --host

would show you only host usb devices not attached to any VM.

I think it's the second bit if functionality which Juergen is keen be
available in some form or other.

 -George


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