[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.