Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Juergen Gross <jgross@xxxxxxxx>]

On 09/14/2015 12:36 PM, George Dunlap wrote:
> On Mon, Sep 14, 2015 at 4:48 AM, Juergen Gross <jgross@xxxxxxxx> wrote:
> > On 09/11/2015 04:41 PM, Ian Campbell wrote:
> > > On Fri, 2015-09-11 at 16:18 +0200, Juergen Gross wrote:
> > > > On 09/11/2015 04:09 PM, Ian Campbell wrote:
> > > > > On Fri, 2015-09-11 at 15:55 +0200, Juergen Gross wrote:
> > > > > > On 09/11/2015 03:26 PM, Ian Campbell wrote:
> > > > > > > On Thu, 2015-09-10 at 23:42 -0600, Chun Yan Liu wrote:
> > > > > > > > > Do these fields have any particular size requirements arising
> > > > > > > > > from
> > > > > > > > > e.g. the
> > > > > > > > > USB spec or from possible dom0 implementations?
> > > > > > > > >
> > > > > > > > > If they have a well defined fixed size from a USB spec then
> > > > > > > > > maybe
> > > > > > > > > we
> > > > > > > > > could
> > > > > > > > > use the appropriate fixed size types?
> > > > > > > >
> > > > > > > > Di> dn't see the size limitation. In Linux kernel code, busnum
> > > > > > > > and
> > > > > > > > devnum (here
> > > > > > > > 'hostbus, hostaddr') are both 'int' type.
> > > > > > >
> > > > > > > Is that a Linux-specific implementation detail or a fundamental
> > > > > > > property of
> > > > > > > USB? We should be designing the interface around Linux
> > > > > > > implementation
> > > > > > > details. It seems like something in the USB spec ought to define
> > > > > > > precisely
> > > > > > > the number of bits in both a bus number and a device address within
> > > > > > > that
> > > > > > > bus.
> > > > > >
> > > > > > The USB spec is only about _the_ bus. How many buses a host can
> > > > > > operate and how they are numbered is outside the USB spec.
> > > > > >
> > > > > > Devices are addressed via their ports in the USB protocol. devnum
> > > > > > is a unique index for a device on the bus, the USB protocol
> > > > > > equivalent
> > > > > > is a list of ports of:
> > > > > > - 1 member in case of direct attached devices
> > > > > > - multiple members in case of hubs between bus and device
> > > > >
> > > > > Thanks for the info. So an "address" in the USB protocol is actually a
> > > > > "path" and "hostbus" is an implementation dependent shorthand for all
> > > > > but
> > > > > the last link in that path.
> > > >
> > > > I'm not sure in which direction you are looking. "address" is a path.
> > > > A path is normally a list of ports starting at the host and walking
> > > > through all hubs until you reach the device. The "bus" is the root
> > > > of that path. So the number of buses the host knows of is the number
> > > > of USB host adapters without any hub.
> > >
> > > OK, I thought I understood but the above suggests not.
> > >
> > > In USB speak, the address is a list of port numbers, which you follow from
> > > the host bus which is the root.
> > >
> > > In Linux speak a "bus" is actually each hub along that path.
> >
> > No. Each hub is just a port which happens to have more ports behind it.
> >
> > > Let me try a worked example and see if I've got it right. Lets take this
> > > topology:
> > >
> > > ROOT0
> > >    |-PORT0 ----+--HUB1
> > >    |-PORT1-,   |-PORT0 -- DEVICE A
> > >            |   `-PORT1 -- DEVICE B
> > >            |
> > >            `--HUB2
> > >                |-PORT0 -- DEVICE C
> > >                `-PORT1 -- HUB3
> > >                            |-PORT0 -- DEVICE D
> > >                            `-PORT1 -x
> > >
> > > ROOT1 -- ... other stuff
> > >
> > > In the USB protocol there are two buses corresponding to ROOT0 and ROOT1.
> > >
> > > So in the protocol the address of DEVICE D on the bus associated with
> > > ROOT0
> > > is [1,1,0], that is PORT1 on ROOT0 => PORT1 on HUB2 => PORT0 on HUB3.
> > >
> > > DEVICE A is [0,0] on the bus associated with ROOT0, similarly.
> > >
> > > In the Linux numbering scheme each ROOTn or HUBn is given a bus number,
> > > somewhat arbitrarily (although I'm sure there is a scheme by which they
> > > allocated). So perhaps:
> > >
> > > ROOT0==BUS1
> >
> > Correct.
> >
> > > HUB1==BUS2
> >
> > No, Just Bus1-Port0 or Bus1:Devnum1
> >
> > > HUB2==BUS2
> >
> > Bus1-Port1 or Bus1:Devnum2
> >
> > > HUB3==BUS4
> >
> > Bus1-Port1.Port1 or Bus1:Devnum3
> >
> > > ROOT1==BUS42
> >
> > Bus2
> >
> > > And in this scheme the address is hostbus+hostaddr, so DEVICE D is [3,0],
> > > that is hostbus==3==HUB3, and port 0. And DEVICE A is [2,0]
> >
> > Device D: Bus1-Port1.Port1.Port0 or e.g. Bus1:Devnum4
> > Device A: Bus1-Port0.Port0 or e.g. Bus1:Devnum5
> >
> > > Is that right?
> > >
> > > > One bus can have up to 31 ports.
> > >
> > > So the answer is that hostaddr can be 5 bits?
> >
> > 5*8 (7 hubs and a device at the last level) == 40, that's the 1 trillion
> > I suggested before. Things are a little bit more complicated. A devnum
> > in a bus is never assigned twice. So when you plug in a device, it might
> > get devnum 6. Unplug it and replug it again will lead to devnum 7.
> >
> > > >    In theory I think up to 7 cascaded
> > > > hubs are possible, but I don't think the resulting theoretical maximum
> > > > of about 1 trillion devices on a bus is to be considered. :-)
> > >
> > > And this suggests that in principal a Linux hostbus could be 5*7 bits ==
> > > 35
> > > bits, maybe. Or at least that any USB address can be encoded in that many
> > > bits.
> >
> > Busnum can grow to arbitrary values. A new USB bus detected will get a
> > new bus number. Removing it and adding it again will again use a new
> > number.
> FWIW libusb seems to define these as uint8:
>
> http://libusb.org/static/api-1.0/group__dev.html#gaf2718609d50c8ded2704e4051b3d2925
>
> (I *think* that "bus number" and "device address" correspond to busnum
> and devnum...)
>
> Anyone want to look into the Linux source code to find out how big it
> will allow busnum / devnum to grow?
drivers/usb/core/hcd.c is using a bitmap to find the next bus number
currently not in use. It's size is USB_MAXBUS which in turn has the
value 64.

choose_devnum() in drivers/usb/core/hub.c is doing a similar job for
device numbers. Here the highest number supported is 127.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel