Re: [PATCH v6 2/2] xl: Add commands for usb hot-plug

[George Dunlap <george.dunlap@eu.citrix.com>]

On 04/25/2013 01:08 PM, Ian Campbell wrote:
> On Thu, 2013-04-25 at 12:57 +0100, George Dunlap wrote:
>> On 04/25/2013 12:38 PM, Ian Campbell wrote:
>>> On Thu, 2013-04-25 at 11:16 +0100, George Dunlap wrote:
>>>>>> +    for (i = 0; i < num; i++) {
>>>>>> +        printf("%8s  ", (dev[i].protocol==LIBXL_USB_PROTOCOL_PV)?"pv":"dm");
>>>>>
>>>>> You can use libxl_usb_protocol_to_string here.
>>>>
>>>> Could do, but I didn't necessarily want the long version ("devicemodel").
>>>
>>> TBH the more I think about it the more I think DM/DEVICEMODEL in this
>>> interface is leaking an implementation detail, after all the user
>>> doesn't really care who/what is emulating a USB controller.
>>>
>>> Protocol = {PV,OHCI,XHCI}?
>>
>> As we covered before:
>
>> 1. I have no way of selecting OHCI vs XHCI at this point
>
> OK, so maybe HCI (as the generic term for a USB host controller) or EMU
> or something is more appropriate. I'm not too fussed about the
> distinction between {O,U,X}HCI right now.
>
>> 2. Even if I did, why should the caller have to keep track of what kind
>> of USB hardware is exposed to the guest?
>
> Perhaps because they have to make sure they have the appropriate drivers
> in the guest?
>
> In particular if qemu decides to use xhci will that work seemlessly with
> Windows XP? I think XHCI is supposed to be backwards compatible with
> OHCI but I'm not really sure how that works in practice.
>
>> They should be able to just  say "Add" and have stuff sorted out.
>
> Sure.
>
>> 3. The point of saying DEVICEMODEL is that it's not PV.  An HVM guest
>> may be able to do either, and should be allowed to choose.
>
> But not PV does not imply device model, except by
> inspecting/understanding implementation details. What you are really
> asking for is an emulated USB host controller and you don't care where
> it comes from.
>
>> 4. In any case, PROTOCOL_AUTO should be the expected default thing which
>> should be called 99% of the time, unless there's a reason to choose
>> otherwise.
>>
>> 5. #4 doesn't undermine #2 as an argument, because the caller should be
>> able to specify "use qemu" without having to remember which hardware is
>> currently exposed to the guest.
>
> My point is that the user doesn't want to specify "use qemu" they want
> to specify "use an emulated USB host controller".

Right -- so your only problem is that you don't want users to have to 
know "emulated" <=> "device model".  That's fine.

>
> How does spice USB redirection fit into this scheme? Remember that SPICE
> is also, as an implementation detail, implemented by QEMU.

I don't know much about spice, but wouldn't that be the job of the spice 
client to handle that?

It would be kind of scary if the admin of a machine could tell a remote 
spice client to expose arbitrary devices on that host to the vm. :-)

  -George