From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45857 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOEVy-0005vF-18 for qemu-devel@nongnu.org; Mon, 14 Jun 2010 14:36:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOEVv-0001jb-8U for qemu-devel@nongnu.org; Mon, 14 Jun 2010 14:36:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65416) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOEVv-0001jQ-0G for qemu-devel@nongnu.org; Mon, 14 Jun 2010 14:36:03 -0400 Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() From: Alex Williamson In-Reply-To: <4C165DA5.70105@siemens.com> References: <20100614054923.879.33717.stgit@localhost.localdomain> <1276519930.12015.104.camel@x201> <201006141409.08653.paul@codesourcery.com> <1276529350.12015.136.camel@x201> <4C16522F.3020006@siemens.com> <1276533496.12015.191.camel@x201> <4C165DA5.70105@siemens.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 14 Jun 2010 12:35:43 -0600 Message-ID: <1276540543.12015.353.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: Jan Kiszka Cc: "chrisw@redhat.com" , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , Markus Armbruster , "kraxel@redhat.com" , "avi@redhat.com" , Paul Brook 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. > >>>> For busses that don't have a consistent addressing scheme then some sort of > >>>> instance ID is unavoidable. I guess it may be possible to invent something > >>>> based on other device properties (e.g. address of the first IO port/memory > >>>> region). > >>> Instance IDs aren't always bad, we just run into trouble with hotplug > >>> and maybe creating unique ramblock names. But, such busses typically > >>> don't support hotplug and don't have multiple instances of the same > >>> device on the bus, so I don't expect us to hit many issues there as long > >>> as we can get a stable address path. Thanks, > >>> > >> If stable instance numbers are required, we could simply keep them in > >> DeviceState and search for the smallest free one on additions. Actually, > >> I'm more in favor of this direction than including the bus address. That > >> way we could keep a canonical format across all buses and do not have to > >> provide possibly complex ID generation rules for each of them. > > > > 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. > > Still, I'm worried about having to define numbering schemes for all the > buses qemu supports. Maybe we can run a mixture: address-based for > hotplug-capably buses (they tend to be cooperative in this regard) and > simple instance numbers for the rest, likely the majority. Yep, I share that concern, which is I say instance numbers aren't always bad. If we have devices that we don't care about doing hotplug on, we can live with instance numbers. Thanks, Alex