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

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Thu, Apr 25, 2013 at 10:56:14AM +0100, George Dunlap wrote:
> 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.
>

Yep, if qemu can manage all that on its own, then it's good!

-- Pasi
 

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