From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54113 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOHQy-0005ZQ-3L for qemu-devel@nongnu.org; Mon, 14 Jun 2010 17:43:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOHQw-0007jj-JM for qemu-devel@nongnu.org; Mon, 14 Jun 2010 17:43:07 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:57588) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOHQw-0007jN-Ci for qemu-devel@nongnu.org; Mon, 14 Jun 2010 17:43:06 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() Date: Mon, 14 Jun 2010 22:43:01 +0100 References: <20100614054923.879.33717.stgit@localhost.localdomain> <4C165DA5.70105@siemens.com> <1276540543.12015.353.camel@x201> In-Reply-To: <1276540543.12015.353.camel@x201> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201006142243.02163.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: "chrisw@redhat.com" , "kvm@vger.kernel.org" , Jan Kiszka , Markus Armbruster , "qemu-devel@nongnu.org" , "kraxel@redhat.com" , "avi@redhat.com" > On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote: > > Alex Williamson wrote: > > > On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote: > > >> And instead of introducing another hierarchy level with the bus > > >> address, I would also prefer to add this as prefix or suffix to the > > >> device name, e.g. .. > > > > > > That's what I had started with. The first post in this thread has > > > "pci.0,addr=09.0" as a single hierarchy level. The "addr=" may be > > > unnecessary there, but I also prefer something along those lines. For > > > PCI it'd make sense to have :, which comes out to > > > "pci.0:09.0". (Maybe rather than flagging properties as being relevant > > > to the path and printing them generically, we should extract specific > > > properties based on the bus type.) > > > > Not bus.addr, driver.addr. We only have one PCI bus here, not as many as > > there are slots on that bus. > > Ok, I can get it down to something like: > > /i440FX-pcihost/pci.0/virtio-blk-pci,09.0 > > The addr on the device is initially a little non-intuitive to me since > it's a property of the bus, but I guess it make sense if we think of > that level as slot, which includes an address and driver. That indicates you're thinking about things the wrong way. The point of this path is to uniquely identify an entity. /i440FX-pcihost/pci0 identifies a PCI bus attached to the i440FX-pcihost device. To identify a device attached to that bus all you need to know is the devfn of the device. For an end-user it may be helpful to allow devices to be identified by the device type (assuming only one device of a particular type on that bus), or specify the device type as a crude error checking mechanism. However we're talking about canonical addresses. These need not include the device type. Verifying that the device is actually what you expect is a separate problem, and the device type is not sufficient for that. i.e. /i440FX-pcihost/pci.0/,09.0 Is an appropriate canonical address. > > > I started down that path, but it still breaks for hotplug. If we start > > > a VM with two e1000 NICs, then remove the first, we can no longer > > > migrate because the target can't represent having a single e1000 with a > > > non-zero instance ID. > > > > That's indeed a good point. That's a feature. If you start with two NICs and remove the first, the chances are that the second will be in a different place to the nice created in a single-nic config. Allowing migration between these two will cause a PCI device to suddenly change location. This is not physically or logically possible, and everyone looses. Hot-removing a nic and then hotplugging a new nic in the same location may result in something that is reasonable to migrate. Paul