From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string Date: Wed, 16 Jun 2010 10:34:30 +0200 Message-ID: References: <20100614054923.879.33717.stgit@localhost.localdomain> <4C15D413.6020803@redhat.com> <1276545389.12015.499.camel@x201> <1276624893.12015.715.camel@x201> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: chrisw@redhat.com, Gerd Hoffmann , kvm@vger.kernel.org, qemu-devel@nongnu.org, paul@codesourcery.com, avi@redhat.com To: Alex Williamson Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19946 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752138Ab0FPIel (ORCPT ); Wed, 16 Jun 2010 04:34:41 -0400 In-Reply-To: <1276624893.12015.715.camel@x201> (Alex Williamson's message of "Tue, 15 Jun 2010 12:01:33 -0600") Sender: kvm-owner@vger.kernel.org List-ID: Alex Williamson writes: > 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. I consider that a (very minor) bug. >> > 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 see property "nr" in virtconsole_info and virtserialport_info. I can't see any other virtio-serial devices. >> > 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. Paul suggested physical ports. Doesn't look like we have them, but that should be fixable.