From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH V6 3/7] libxl: add pvusb API Date: Mon, 14 Sep 2015 12:53:29 +0200 Message-ID: <55F6A729.3080301@suse.com> References: <1439202928-24813-1-git-send-email-cyliu@suse.com> <1439202928-24813-4-git-send-email-cyliu@suse.com> <1441721852.24450.120.camel@citrix.com> <55F2F64F02000066000508CA@relay2.provo.novell.com> <1441978018.3549.33.camel@citrix.com> <55F2DD66.1040507@suse.com> <1441980590.3549.46.camel@citrix.com> <55F2E29D.10805@suse.com> <1441982504.3549.69.camel@citrix.com> <55F6438A.7090403@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Wei Liu , Ian Campbell , Ian Jackson , Chun Yan Liu , "xen-devel@lists.xen.org" , Jim Fehlig , Simon Cao List-Id: xen-devel@lists.xenproject.org On 09/14/2015 12:36 PM, George Dunlap wrote: > On Mon, Sep 14, 2015 at 4:48 AM, Juergen Gross 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