xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>,
	LibVirt Development List <libvir-list@redhat.com>,
	Jim Fehlig <jfehlig@suse.com>,
	xen-devel@lists.xen.org, sstanisi@cbnco.com,
	Fabio Fantoni <fabio.fantoni@m2r.biz>,
	Anthony Perard <anthony.perard@citrix.com>,
	Ian Jackson <ian.jackson@citrix.com>,
	"Simon (Bo) Cao" <caobosimon@gmail.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH v7 RFC 0/2] libxl USB prototype and design discussion
Date: Wed, 18 Jun 2014 14:15:28 +0100	[thread overview]
Message-ID: <53A190F0.2080106@eu.citrix.com> (raw)
In-Reply-To: <1403096222.32540.14.camel@kazak.uk.xensource.com>

On 06/18/2014 01:57 PM, Ian Campbell wrote:
>> * Is it possible for the toolstack to tell if domU has a working and
>> connected PVUSB front-end?
> It can observe the state variable being 4 I suppose. Why do you need to
> know?

It might be nice to be able to create both a pv and an emulated 
controller in the config file, and then have "xl usb-attach [foo]" to 
automatically plug it into the PV controller if the PV frontend seems to 
be up, and into the emulated controller if it doesn't seem to be up.

But that doesn't change the elements of the interface, just what the 
default would be if the controller field is empty.

>> * Do we want to be able to create virtual hubs for qemu-backed
>> controllers at some point in the future?  Is there any groundwork we
>> want to lay for that?
> qemu-backed emulated or PV controllers?
>
> I don't think emulated would make sense for a PV guest and if qemu
> wanted to be a PV backend it would have to implement the usual xenstore
> watches etc.

I mean, emulate an actual USB hub -- you know, it plugs into your USB 
controller and you can plug other USB devices into it.

I'm inclined not to bother with it at this point.

>> -- snip --
>>
>> Given that, here is a potential config file format:
>>
>> -- snip --
>> # Create two controllers, one pv, one emulated
>> usbcontroller=['type=pv,name=pv0,usbversion=2,numports=4',
>>                 'type=emul,name=hci0,usbversion=2']
>>
>> # Create a controller with the defaults; PV for PV guests, emul for HVM guests
>> usbcontroller=['']
>>
>> # Same as above, but defaulting to version 2
>> usbversion=2
>>
>> # I think we should be able to automatically detect which format to
>> # use; so I think we should re-use usbdevice.  I could be convinced otherwise.
>> usbdevice=['type=tablet','type=hostdev,hostaddr=4.3,bus=pv0']
> Does this require that the usbcontroller have been specified?
>
> I think it would be good if xl would by default create some number of
> appropriate controllers without my having to specify them explicitly,
> iow just saying usbdevice=[...] should be enough.
>
> I'm not saying that you shouldn't support more specific syntax for
> people who want more control, just that it shouldn't be required to do
> so.
>
> (I'm just talking xl here, at the libxl layer I think it would be fine
> to require them to be explicit).

That makes sense.

>> * Rather than having to specify a controller, automatically hot-plug
>> controllers as-needed.
> At the xl level I think this would be good.

OK, sounds good.  Thanks for the input.

  -George

  parent reply	other threads:[~2014-06-18 13:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1401716658-22393-1-git-send-email-george.dunlap@eu.citrix.com>
2014-06-02 13:44 ` [PATCH v7 RFC 1/2] libxl: Introduce functions to add and remove USB devices to an HVM guest George Dunlap
2014-06-18 13:08   ` Ian Campbell
2014-06-18 13:22     ` George Dunlap
2014-06-18 13:49       ` Ian Campbell
2014-06-18 13:58         ` George Dunlap
2014-06-18 14:30           ` Ian Campbell
2014-06-18 14:47             ` George Dunlap
2014-06-02 13:44 ` [PATCH v7 RFC 2/2] xl: Add commands for usb hot-plug George Dunlap
2014-06-05 10:14 ` [PATCH v7 RFC 0/2] libxl USB prototype and design discussion Daniel P. Berrange
     [not found] ` <20140605101438.GD19077@redhat.com>
2014-06-05 15:04   ` George Dunlap
2014-06-18 12:57 ` Ian Campbell
     [not found] ` <1403096222.32540.14.camel@kazak.uk.xensource.com>
2014-06-18 13:15   ` George Dunlap [this message]
2014-06-18 14:04   ` George Dunlap
     [not found]   ` <53A19C67.3070809@eu.citrix.com>
2014-06-30 14:41     ` Simon Cao
2014-06-02 13:44 George Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53A190F0.2080106@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=berrange@redhat.com \
    --cc=caobosimon@gmail.com \
    --cc=fabio.fantoni@m2r.biz \
    --cc=ian.jackson@citrix.com \
    --cc=jfehlig@suse.com \
    --cc=libvir-list@redhat.com \
    --cc=roger.pau@citrix.com \
    --cc=sstanisi@cbnco.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).