[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?

 -George

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.