From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH V4 3/7] libxl: add pvusb API Date: Tue, 16 Jun 2015 13:19:41 +0200 Message-ID: <5580064D.10600@suse.com> 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> 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 , Chunyan Liu , "xen-devel@lists.xen.org" , Jim Fehlig , Simon Cao List-Id: xen-devel@lists.xenproject.org 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. Juergen > - bus.addr: e.g., 2.10 is bus=2, address=10. Unique every time a > device is plugged in (so no risk of aliasing, but not stable across > reboots) > - vendorid:deviceid: e.g., 1050:0111 is vendorid=1050, deviceid=0111. > Stable on device class (so same no matter when or where you plug it > in, but can't tell two identical devices apart). > > -George >