Re: [Xen-devel] [PATCH v6 1/2] libxl: Introduce functions to add and remove USB devices to an HVM guest

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 04/25/2013 08:44 AM, Ian Campbell wrote:
> On Wed, 2013-04-24 at 18:49 +0100, Pasi KÃrkkÃinen wrote:
> > On Wed, Apr 24, 2013 at 04:51:46PM +0100, Ian Campbell wrote:
> > > On Wed, 2013-04-24 at 16:45 +0100, George Dunlap wrote:
> > > > On 24/04/13 14:51, Ian Campbell wrote:
> > > > > On Wed, 2013-04-24 at 14:32 +0100, George Dunlap wrote:
> > > > >
> > > > > > There's also the translation of "AUTO" protocol into PV or HVM, and
> > > > > This made me wonder, how is libxl_device_usb_protocol different from the
> > > > > type of the domain? Can you (or is the intention) use PV with an HVM
> > > > > domain? I suppose DEVICEMODEL is HVM only?
> > > > The intention is to allow HVM guests to use either DEVICEMODEL or PV as
> > > > protocols.
> > > >
> > > > > Is "protocol" really the right word for this? I'd half expect it to mean
> > > > > USB 1.0 vs 2.0 vs 3.0. For NICS we call this Enum libxl_nic_type. FWIW
> > > > But we're already using 'type' for the device type. :-)
> > > >
> > > > I think for nics it makes sense to call it a 'type', as for NICs we
> > > > refer to the *emulated device* as a NIC, or the PV device as a NIC,
> > > > which is then (virtually) plugged into a bridge somewhere.  But in this
> > > > case I don't think it makes sense, as it's the actual host device you
> > > > care about, and the way the guest talks to it is either via PV or qemu.
> > > > "Protocol" may not be the very best option, but at least it gives you
> > > > the idea of a conduit.
> > > It's more like a "method" then?
> > "protocol" reminded me about something.. when using devicemodel/qemu method,
> > do we currently allow specifying if the usb device should be connected to
> > usb2 (ehci) or usb3 (xhci) virtual controller?
> Perhaps EMU_USB2 and EMU_USB3 would be preferable names to DEVICEMODEL?
>
> Not sure which the current devicemodel mode uses, the code doesn't
> appear to ask qemu for one or the other explicitly, I'd imagine the
> default would be USB2? The qmeu manpage only mentions UHCI.
The purpose qemu's manpage / online docs appear mainly to be to distract 
and mislead unbelievers, making sure that only the truly worthy learn 
its secrets.  A more useful document is hidden inside qemu's source 
tree: docs/qdev-device-use.txt.  It sort of hints at the idea of being 
able to attach a USB device to a specific bus, but doesn't go into 
detail about how it might actually be done.
But in any case, we now seem to be getting back into "exposing too much 
of qemu's internals to the user".  Suppose you switch from having only a 
USB2 controller to a USB3 controller -- do you really want to have the 
user or the toolstack keep track of which is which?
If you just tell qemu to plug stuff in, it will manage the topology 
automatically (apparently including things like adding a USB hub 
on-the-fly).  That is I think the only functionality the vast majority 
of users will want to have.  If we ever get to the point of needing to 
specify that kind of topology, I think we should just add new flags / 
features at that time.
 -George

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