All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Chun Yan Liu <cyliu@suse.com>
Cc: lars.kurth@citrix.com, george.dunlap@eu.citrix.com,
	xen-devel@lists.xen.org, ian.jackson@citrix.com,
	caobosimon@gmail.com
Subject: Re: [PATCH RFC V2 1/5] libxl: add pvusb definitions
Date: Wed, 4 Mar 2015 10:00:43 +0000	[thread overview]
Message-ID: <1425463243.25940.102.camel@citrix.com> (raw)
In-Reply-To: <54F7241D02000066000A562A@relay2.provo.novell.com>

On Wed, 2015-03-04 at 00:26 -0700, Chun Yan Liu wrote:
> 
> >>> On 3/3/2015 at 07:10 PM, in message <1425381019.24959.87.camel@citrix.com>, Ian
> Campbell <ian.campbell@citrix.com> wrote: 
> > On Mon, 2015-01-19 at 16:28 +0800, Chunyan Liu wrote: 
> >  
> > Sorry for the long delay in replying. 
> >  
> > > To attach a usb device, a virtual usb controller should be created first. 
> > > This patch defines usbctrl and usbdevice related structs. 
> >  
> > Per <54CA17DF0200006600095E3D@relay2.provo.novell.com> please could you 
> > mention here that the HVM guest related parts (i.e. 
> > LIBXL_USBCTRL_TYPE_DEVICEMODEL) and libxl_usb_type are placeholders for 
> > emulated HVM support. 
> 
> Yes, I agree it's better placed in libxl_usb_type rather than ctrl_type.
> 
> >  
> > In fact I wonder if it should just be omitted, we will need a LIBXL_HAVE 
> > for HVM USB support anyway once it is implemented so we can add the enum 
> > then. 
> 
> It won't harm to omit it for current pvusb work. Acceptable to me to
> add enum later when adding HVM qemu emulated usb device implementation.

I suppose users of libxl would like to be able to expose to their users
whether or not HVM USB passthrough will work (i.e. to hide UI options).
So I think we will want the #define eventually so they can know at
compile time if HVM USB will work.

We could add a negative one now (LIBXC_NO_HVM_USB_PASSTHROUGH) and
remove it later, but that's icky I think.

So I think omit the HVM stuff for now, it's less confusing overall that
way.

George, is that OK with you?

> >  
> > > +    ]) 
> > > + 
> > > +libxl_device_usb = Struct("device_usb", [ 
> > > +    ("ctrl", integer), 
> >  
> > Is this an index into something? If so what? 
> 
> To usb controller index.
> A usb device should be connected to a usb port of a usb controller.
> e.g.: there is 2 usb controllers in system, each with 8 ports, then:
> 1st usb controller index will be 0, port will be 1~8.
> 2nd usb controller index will be 1, port will be 1~8.
> To attach a usb device through pvusb way, it should be pointed to
> connect to which controller and which port.

I guess what I'm missing is how do I create this controller? I saw
nothing in the guest cfg which would allow me to create one.

Is there some way to say "I don't care, find a controller and use it"?

> >  
> > There seems to be no usbctrl array added to the domain_config struct, so 
> > I'm unsure how this is used. 
> >  
> > > +    ("port", integer), 
> >  
> > Port on the hub? 
> > > +    ("intf", string), 
> >  
> > What is this one? (This may just be my lack of usb knowledge)
> 
> It means sysfs interface for the usb device under /sys/bus/usb/devices/,
> like: 2-1.6.

Thanks. I think given Georges feedback we will be dropping this?
> ntly not used.
> 
> > > + 
> > > @@ -547,6 +578,7 @@ libxl_domain_config = Struct("domain_config", [ 
> > >      ("disks", Array(libxl_device_disk, "num_disks")), 
> > >      ("nics", Array(libxl_device_nic, "num_nics")), 
> > >      ("pcidevs", Array(libxl_device_pci, "num_pcidevs")), 
> > > +    ("usbs", Array(libxl_device_usb, "num_usbs")), 
> >  
> > So, I'm unsure how this interacts with the controllers, which it doesn't 
> > seem to be possible to specify at domain build time.
> 
> In domain config, user only needs to specify usb=['2-1.6'], by default, it will
> create a default usb contoller, and probe the 1st available controller:port for
> the usb device to attach. So, it can work to specify usbs here only.
> 
> Reason didn't include controller in libxl_domain_config: for HVM qemu emulated
> usb device, all work is done in qemu (create usb controller and attach usb device),
> no controller exists in libxl in that case.

OK, so it's an HVM only thing. I think that makes sense, but then how
does the libxl_device_usb.ctrl field make sense or how do I use it?

  reply	other threads:[~2015-03-04 10:00 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-19  8:28 [PATCH RFC V2 0/5] pvusb toolstack work Chunyan Liu
2015-01-19  8:28 ` [PATCH RFC V2 1/5] libxl: add pvusb definitions Chunyan Liu
2015-03-03 11:10   ` Ian Campbell
2015-03-03 16:45     ` George Dunlap
2015-03-04  7:26     ` Chun Yan Liu
2015-03-04 10:00       ` Ian Campbell [this message]
2015-03-04 12:26         ` George Dunlap
2015-03-04 12:33           ` Ian Campbell
2015-03-05  5:04             ` Chun Yan Liu
2015-03-03 17:15   ` George Dunlap
2015-03-04  8:28     ` Chun Yan Liu
2015-03-04 14:41       ` George Dunlap
2015-03-05  6:07         ` Chun Yan Liu
2015-01-19  8:28 ` [PATCH RFC V2 2/5] libxl: export some functions for pvusb use Chunyan Liu
2015-03-03 11:10   ` Ian Campbell
2015-01-19  8:28 ` [PATCH RFC V2 3/5] libxl: add pvusb API Chunyan Liu
2015-01-28 15:54   ` Ian Campbell
2015-01-29  3:24     ` Chun Yan Liu
2015-02-10 10:08   ` Jürgen Groß
2015-02-10 16:01   ` Jürgen Groß
2015-03-03 11:38   ` Ian Campbell
2015-03-04  7:47     ` Chun Yan Liu
2015-03-06 16:50   ` George Dunlap
2015-03-09  9:39     ` Ian Campbell
2015-03-09 10:17       ` George Dunlap
2015-03-09 10:41         ` Ian Campbell
2015-03-20  9:37     ` Chun Yan Liu
2015-03-17 14:03   ` Juergen Gross
2015-01-19  8:28 ` [PATCH RFC V2 4/5] xl: add pvusb commands Chunyan Liu
2015-02-10  6:25   ` Jürgen Groß
2015-03-03 11:43   ` Ian Campbell
2015-03-04  7:48     ` Chun Yan Liu
2015-03-06 17:25   ` George Dunlap
2015-03-20  9:02     ` Chun Yan Liu
2015-01-19  8:28 ` [PATCH RFC V2 5/5] domcreate: support pvusb in configuration file Chunyan Liu
2015-03-03 11:44   ` Ian Campbell
2015-01-28 15:51 ` [PATCH RFC V2 0/5] pvusb toolstack work Ian Campbell
2015-01-28 16:07   ` Pasi Kärkkäinen
2015-01-28 16:17     ` Ian Campbell
2015-01-29  3:22   ` Chun Yan Liu

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=1425463243.25940.102.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=caobosimon@gmail.com \
    --cc=cyliu@suse.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=ian.jackson@citrix.com \
    --cc=lars.kurth@citrix.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.