From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() Date: Tue, 15 Jun 2010 10:47:16 +0200 Message-ID: References: <20100614054923.879.33717.stgit@localhost.localdomain> <1276519930.12015.104.camel@x201> <201006141409.08653.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Williamson , chrisw@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, avi@redhat.com, kraxel@redhat.com To: Paul Brook Return-path: Received: from mx1.redhat.com ([209.132.183.28]:32500 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753160Ab0FOIr1 (ORCPT ); Tue, 15 Jun 2010 04:47:27 -0400 In-Reply-To: <201006141409.08653.paul@codesourcery.com> (Paul Brook's message of "Mon, 14 Jun 2010 14:09:06 +0100") Sender: kvm-owner@vger.kernel.org List-ID: Paul Brook writes: > Alex Williamson writes: > >> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote: >> > Could you explain why you add "identified properties of the immediate >> > parent bus and device"? They make the result ver much *not* a "dev >> > path" in the qdev sense... >> >> In order to try to get a unique string. Without looking into device >> properties, two e1000s would both be: >> >> /main-system-bus/pci.0/e1000 >> /main-system-bus/pci.0/e1000 >> >> Which is no better than simply "e1000" and would require us to fall back >> to instance ids again. The goal here is that anything that makes use of >> passing a dev when registering a vmstate gets an instance id of zero. > > You already got the information you need, you just put it in the wrong place. > The canonical ID for the device could be its bus address. In practice we'd > probably want to allow the user to specify it by name, provided these are > unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would > as an aias for [...]:_09.0. Device names have a restricted namespace, so we > can use an initial prefix to disambiguate a name/label from a bus address. > > 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). When that's inconvenient or impossible, we can still punt to user: make device ID mandatory. We obviously need a way to unambigously name a device. It's okay to have multiple names for the same device. If the device has a device ID, that's an unambigous name. qdev paths may be ambigous when path components are resolved to driver names instead of IDs. Alex proposed to disambiguate by adding "identified properties of the immediate parent bus and device" to the path component. For PCI, these are dev.fn. Likewise for any other bus where devices have unambigous bus address. The driver name carries no information! For other buses, we need to make something up. Note that addressing by bus address rather than name is generally useful, not just in the context of savevm. For instance, I'd appreciate being able to say something like "device_del pci.0/04.0". An easy way to get that is to reserve part of the name space for bus addresses. If the path component starts with a letter, it's an ID or driver name. If it starts with say '@', it's a bus address in bus-specific syntax. The bus provides a method to look it up. That way, we gain a useful feature, and avoid having an savevm-specific "device path" that isn't recognized anywhere else. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39827 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OORnu-0002Rb-3L for qemu-devel@nongnu.org; Tue, 15 Jun 2010 04:47:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OORnr-0006Tj-1t for qemu-devel@nongnu.org; Tue, 15 Jun 2010 04:47:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17109) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OORnq-0006TM-Ql for qemu-devel@nongnu.org; Tue, 15 Jun 2010 04:47:27 -0400 From: Markus Armbruster Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() References: <20100614054923.879.33717.stgit@localhost.localdomain> <1276519930.12015.104.camel@x201> <201006141409.08653.paul@codesourcery.com> Date: Tue, 15 Jun 2010 10:47:16 +0200 In-Reply-To: <201006141409.08653.paul@codesourcery.com> (Paul Brook's message of "Mon, 14 Jun 2010 14:09:06 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: chrisw@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, Alex Williamson , kraxel@redhat.com, avi@redhat.com Paul Brook writes: > Alex Williamson writes: > >> On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote: >> > Could you explain why you add "identified properties of the immediate >> > parent bus and device"? They make the result ver much *not* a "dev >> > path" in the qdev sense... >> >> In order to try to get a unique string. Without looking into device >> properties, two e1000s would both be: >> >> /main-system-bus/pci.0/e1000 >> /main-system-bus/pci.0/e1000 >> >> Which is no better than simply "e1000" and would require us to fall back >> to instance ids again. The goal here is that anything that makes use of >> passing a dev when registering a vmstate gets an instance id of zero. > > You already got the information you need, you just put it in the wrong place. > The canonical ID for the device could be its bus address. In practice we'd > probably want to allow the user to specify it by name, provided these are > unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would > as an aias for [...]:_09.0. Device names have a restricted namespace, so we > can use an initial prefix to disambiguate a name/label from a bus address. > > 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). When that's inconvenient or impossible, we can still punt to user: make device ID mandatory. We obviously need a way to unambigously name a device. It's okay to have multiple names for the same device. If the device has a device ID, that's an unambigous name. qdev paths may be ambigous when path components are resolved to driver names instead of IDs. Alex proposed to disambiguate by adding "identified properties of the immediate parent bus and device" to the path component. For PCI, these are dev.fn. Likewise for any other bus where devices have unambigous bus address. The driver name carries no information! For other buses, we need to make something up. Note that addressing by bus address rather than name is generally useful, not just in the context of savevm. For instance, I'd appreciate being able to say something like "device_del pci.0/04.0". An easy way to get that is to reserve part of the name space for bus addresses. If the path component starts with a letter, it's an ID or driver name. If it starts with say '@', it's a bus address in bus-specific syntax. The bus provides a method to look it up. That way, we gain a useful feature, and avoid having an savevm-specific "device path" that isn't recognized anywhere else.