From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH V4 3/7] libxl: add pvusb API Date: Tue, 16 Jun 2015 12:23:01 +0100 Message-ID: References: <1433906441-3280-1-git-send-email-cyliu@suse.com> <1433906441-3280-4-git-send-email-cyliu@suse.com> <557EE03F.5040108@suse.com> <557F18E8.8050305@suse.com> <557FFFA9.2070002@suse.com> <5580064D.10600@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5580064D.10600@suse.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: Juergen Gross Cc: Wei Liu , Ian Campbell , Ian Jackson , Chunyan Liu , "xen-devel@lists.xen.org" , Jim Fehlig , Simon Cao List-Id: xen-devel@lists.xenproject.org On Tue, Jun 16, 2015 at 12:19 PM, Juergen Gross wrote: > On 06/16/2015 01:11 PM, George Dunlap wrote: >> >> On Tue, Jun 16, 2015 at 11:51 AM, Juergen Gross wrote: >>>> >>>> The "busid" interface that Chunyan is describing requires the caller >>>> to find out that long name -- 2-3.1.2 -- rather than the traditional >>>> short name (002:010). Just accepting "2-3" is not sufficient. >>> >>> >>> >>> qemu with my patch will find the device only if the long name is used. >>> So the "port" in qemu would be "3.1.2" in your example above. >> >> >> Ah, right -- sorry, looking at the patch I saw that "port" was >> converted using strtoul, but now I see that was "bus", and that "port" >> is a string. That's what I was missing. >> >>> BTW: be careful with the syntax: x:y is used by qemu to specify a device >>> by vendorId:productId, you should write "002.010" to use the short name >>> above. >> >> >> Yes, thanks for the reminder. I knew there was some way to >> distinguish bus.addr and vendor:device, but I'd forgotten the exact >> semantics. >> >> So as Juergen says, the typical way to write these would be: >> - bus-port; e.g., 2-3.1.2 is bus=2, port=3.1.2. Stable in topology, >> not in device > > > Nah, not stable in topology. At least on my laptop I've seen a memory > stick plugged in at the same position as "3-3" or as "1-3". > > I'm pretty sure this is just a matter of timing during boot: the busses > are all (or at least some of them) queried at the same time and the > first answering gets number 1, the next 2, and so on. And timing seems > to be different enough to result in unstable bus numbers. Right -- I meant "stable in topology within one boot", but at least two of you have now understood me to mean "across reboots" by default, so that's obviously a detail that needs to be specified. :-) -George