Re: [Qemu-devel] [PATCH v3] libxl: usb2 and usb3 controller support for upstream qemu

[Anthony Liguori]

On Thu, Jul 18, 2013 at 6:09 AM, Ian Jackson <address@hidden> wrote:
> Fabio Fantoni writes ("Re: [PATCH v3] libxl: usb2 and usb3 controller support 
> for upstream qemu"):
>> Il 12/07/2013 17:33, George Dunlap ha scritto:
>> > On 12/07/13 13:36, Fabio Fantoni wrote:
> [someone wrote:]
>> >>> I'm just curious, why is this so complicated?  Is this likely to be
>> >>> fragile and break in the future?
> ...
>> >> I tried already but there are problems with retrocompatibility:
>> >> http://lists.xen.org/archives/html/xen-devel/2013-07/msg00491.html
>> >> I was also asking if it is possible to remove some hardcoded options
>> >> without breaking something but I had no reply.
>> >
>> > So this seems to be a response to the first paragraph ("why is this so
>> > complicated, is it fragile").
>
> I'm afraid that I don't think it's really a sufficient response to
> "why is this so complicated, is it fragile?".  "I don't know" is not
> very convincing :-).

It's a multi-function PCI device that provides separate functions for
each legacy interface.  There are three distinct UHCI interfaces
presumably to enable supporting more ports.

In an ideal world, we would support this by having a single -device
ich-usb that did the right thing but we don't really have a way to
model multifunction devices as a single entity today.  Hence, the
complex command line.

The command line interface is a stable interface in QEMU.  This
interface will not change over time.

> My worry would be that these options would change their meaning in the
> future, or indeed that the whole edifice which requires callers to
> specify things at this excruciating level of detail might (sensibly!)
> be abolished.

Patches are welcome :-)  Seriously, I would love for someone to do
proper multi-function support such that we could support hotplugging a
multi-function device.

The current way of creating each function will always be supported though.

Regards,

Anthony Liguori

> Ian.
>