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

[Juergen Gross <jgross@xxxxxxxx>]

On 10/07/2015 01:20 PM, George Dunlap wrote:
> 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.
Exactly.

BTW: I've explained that in another reply, but my mail client has chosen
to send it via another account - I've no idea how that happened. So now
my wife has some xen-devel history as well. ;-)


Juergen


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