Re: [PATCH RFC] libxl: Introduce functions to add and remove USB devices to an HVM guest

From: Ian Jackson <Ian.Jackson@eu.citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH RFC] libxl: Introduce functions to add and remove USB devices to an HVM guest
Date: Tue, 9 Apr 2013 19:19:27 +0100	[thread overview]
Message-ID: <20836.23471.371602.527092@mariner.uk.xensource.com> (raw)
In-Reply-To: <51645075.9070309@eu.citrix.com>

George Dunlap writes ("Re: [Xen-devel] [PATCH RFC] libxl: Introduce functions to add and remove USB devices to an HVM guest"):
> On 09/04/13 17:30, Ian Jackson wrote:
> > I think in principle you could specify a backend domid for a non-stub
> > dm too.
> 
> How is that supposed to work?

It would set up a PV frontend in qemu in dom0.  I think this is a bit
silly because it's hard to see why you'd want to but it's not an
inherently absurd configuration.  I'm not saying this should be
implemented, but it demonstrates that things are more orthogonal than
they seem.

> > libxl can tell whether the guest is using a stub-dm.
> 
> Yes, but the question is about all the extra random plumbing that libxl 
> would be doing, and the extra codepaths that will be in use, and whether 
> doing all that automatically is really a good interface or not.

I think it is.  It's what happens when you ask for emulated block or
network devices in the stubdom case.  I don't see how USB is
different.

> For example, most distro kernels (apparently) have buggy PVUSB 
> back-ends; possibly stubdoms have buggy PVUSB front-ends.

stubdoms are part of the Xen support infrastructure.  If they have
buggy front-ends we should fix them.  We don't have a compatibility
guarantee to uphold.

> And then suppose that he decides he wants security / scalability /
> whatever, and implements stubdoms.  But he doesn't realize the
> implications; so the next time he happens to pass in a device, it
> suddenly starts using the buggy PVUSB path, and hilarity
> ensues.

This is no different with s/USB/block/.

> We could then consider adding "vendorid:productid" as a 
> properly-supported interface for either PVUSB or DEVICEMODEL at some 
> point in the future -- i.e., have libxl look it up, check that it's 
> unique, and translate it into hostbus.hostaddr.

Well you might want something more automatic.

I guess the question now is whether to include vid:pid in the API.
Maybe that would be in a device spec struct form introduced later.

It occurs to me to wonder whether one might want to pass through "any
and all devices with this vid:pid".

Ian.