From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55959 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOaSQ-0000gA-Sb for qemu-devel@nongnu.org; Tue, 15 Jun 2010 14:01:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOaSO-0008CH-Sg for qemu-devel@nongnu.org; Tue, 15 Jun 2010 14:01:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43564) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOaSO-0008Bn-M4 for qemu-devel@nongnu.org; Tue, 15 Jun 2010 14:01:52 -0400 Subject: Re: [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string From: Alex Williamson In-Reply-To: References: <20100614054923.879.33717.stgit@localhost.localdomain> <4C15D413.6020803@redhat.com> <1276545389.12015.499.camel@x201> Content-Type: text/plain; charset="UTF-8" Date: Tue, 15 Jun 2010 12:01:33 -0600 Message-ID: <1276624893.12015.715.camel@x201> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: chrisw@redhat.com, Gerd Hoffmann , kvm@vger.kernel.org, qemu-devel@nongnu.org, paul@codesourcery.com, avi@redhat.com On Tue, 2010-06-15 at 10:53 +0200, Markus Armbruster wrote: > Alex Williamson writes: > > > On Mon, 2010-06-14 at 09:02 +0200, Gerd Hoffmann wrote: > >> Hi, > >> > >> > My premise with this attempt is that we walk the hierarchy and use the > >> > names to create the base of the path. As we get to the device, > >> > particularly to the parent bus of the device, we need to start looking at > >> > properties to ensure uniqueness. > >> > >> You'll need that for every bus along the way down to the device. Create > >> a virtual machine with two lsi scsi host adapters, then attach a disk > >> with scsi id 0 to each. Just the scsi id isn't good enougth to identify > >> the device. You'll need the lsi pci address too. > > > > Yep, see below. > > > >> > For now, the only properties I've tagged as path > >> > properties are PCI bus addresses and MAC addresses. > >> > >> mac address isn't needed here. You need the property which specifies > >> the bus address. For PCI this obviously is the PCI address. For scsi > >> the scsi id. For ISA you can use the I/O port base. virtio-serial the > >> port number, ... > > > > PCI: addr > > SCSI: scsi-id > > ISA: serial/parallel = iobase, others?? > > If there's no iobase (pathological case), require ID. > > > ide-drive: unit > > Bus name is IDE, but it's clear enough what you mean :) I put ide-drive here because the unit is a property of the device, not the bus. > > I2C: address > > > > virtio-serial doesn't seem to make a DeviceState per port, so I think it > > can be skipped. > > Really? > > Anyway, its port number should do as bus address. Maybe I'm not specifying it correctly. I see a max_nr_ports property, but I don't see that each port is a separate qdev. > > I'm sure I'm still missing some... > > s390-virtio > SSI > System I'll need some help coming up with useful properties to key on for these. I had hoped there's only one System bus. > USB usb-storage seems to have a useful drive property that lets me distinguish these devices: /i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb0/scsi.0/scsi-disk.0 /i440FX-pcihost/pci.0/piix3-usb-uhci.01.2/usb.0/usb-storage.usb1/scsi.0/scsi-disk.0 ^^^^ drive But otherwise USB is disappointingly devoid of useful properties at the bus level. Alex