From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v6 2/2] xl: Add commands for usb hot-plug Date: Thu, 25 Apr 2013 13:14:30 +0100 Message-ID: <51791E26.5090300@eu.citrix.com> References: <1366387166-21197-1-git-send-email-george.dunlap@eu.citrix.com> <1366387166-21197-2-git-send-email-george.dunlap@eu.citrix.com> <1366807503.20256.333.camel@zakaz.uk.xensource.com> <51790282.8090903@eu.citrix.com> <1366889888.20256.514.camel@zakaz.uk.xensource.com> <51791A3E.1080801@eu.citrix.com> <1366891688.20256.525.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1366891688.20256.525.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "sstanisi@cbnco.com" , Roger Pau Monne , Ian Jackson , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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