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 05:48:26 +0200 Message-ID: <55F6438A.7090403@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1441982504.3549.69.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Chun Yan Liu , xen-devel@lists.xen.org Cc: george.dunlap@eu.citrix.com, Ian.Jackson@eu.citrix.com, Jim Fehlig , Simon Cao , wei.liu2@citrix.com List-Id: xen-devel@lists.xenproject.org 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. Juergen