Re: [Xen-devel] [PATCH v6 2/2] xl: Add commands for usb hot-plug

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-04-25 at 12:57 +0100, George Dunlap wrote:
> On 04/25/2013 12:38 PM, Ian Campbell wrote:
> > On Thu, 2013-04-25 at 11:16 +0100, George Dunlap wrote:
> >>>> +    for (i = 0; i < num; i++) {
> >>>> +        printf("%8s  ", 
> >>>> (dev[i].protocol==LIBXL_USB_PROTOCOL_PV)?"pv":"dm");
> >>>
> >>> You can use libxl_usb_protocol_to_string here.
> >>
> >> Could do, but I didn't necessarily want the long version ("devicemodel").
> >
> > TBH the more I think about it the more I think DM/DEVICEMODEL in this
> > interface is leaking an implementation detail, after all the user
> > doesn't really care who/what is emulating a USB controller.
> >
> > Protocol = {PV,OHCI,XHCI}?
> 
> As we covered before:

> 1. I have no way of selecting OHCI vs XHCI at this point

OK, so maybe HCI (as the generic term for a USB host controller) or EMU
or something is more appropriate. I'm not too fussed about the
distinction between {O,U,X}HCI right now.

> 2. Even if I did, why should the caller have to keep track of what kind 
> of USB hardware is exposed to the guest?

Perhaps because they have to make sure they have the appropriate drivers
in the guest?

In particular if qemu decides to use xhci will that work seemlessly with
Windows XP? I think XHCI is supposed to be backwards compatible with
OHCI but I'm not really sure how that works in practice.

> They should be able to just  say "Add" and have stuff sorted out.

Sure.

> 3. The point of saying DEVICEMODEL is that it's not PV.  An HVM guest 
> may be able to do either, and should be allowed to choose.

But not PV does not imply device model, except by
inspecting/understanding implementation details. What you are really
asking for is an emulated USB host controller and you don't care where
it comes from.

> 4. In any case, PROTOCOL_AUTO should be the expected default thing which 
> should be called 99% of the time, unless there's a reason to choose 
> otherwise.
> 
> 5. #4 doesn't undermine #2 as an argument, because the caller should be 
> able to specify "use qemu" without having to remember which hardware is 
> currently exposed to the guest.

My point is that the user doesn't want to specify "use qemu" they want
to specify "use an emulated USB host controller".

How does spice USB redirection fit into this scheme? Remember that SPICE
is also, as an implementation detail, implemented by QEMU.

Ian.


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