From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field Date: Wed, 09 Jun 2010 10:37:29 -0600 Message-ID: <1276101449.3079.74.camel@x201> References: <20100608191447.4451.47795.stgit@localhost.localdomain> <201006090354.05197.paul@codesourcery.com> <1276057143.3079.57.camel@x201> <201006091318.49556.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , qemu-devel@nongnu.org, chrisw@redhat.com, kvm@vger.kernel.org, quintela@redhat.com To: Paul Brook Return-path: Received: from mx1.redhat.com ([209.132.183.28]:15304 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757990Ab0FIQzy (ORCPT ); Wed, 9 Jun 2010 12:55:54 -0400 In-Reply-To: <201006091318.49556.paul@codesourcery.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, 2010-06-09 at 13:18 +0100, Paul Brook wrote: > > > > Not all ram is associated with a device. > > > > > > Maybe not, but where it is we should be using that information. > > > Absolute minimum we should be using the existing qdev address rather than > > > inventing a new one. Duplicating this logic inside every device seems > > > like a bad idea so I suggest identifying ram blocks by a (name, device) > > > pair. For now we can allow a NULL device for system memory. > > > > I'm not sure if this is what you're after, but what if we change it to > > something like: > > > > + snprintf(name, sizeof(name), "%s.%02x.%x.rom-%s", > > + pdev->bus->qbus.name, PCI_SLOT(pdev->devfn), > > + PCI_FUNC(pdev->devfn), pdev->qdev.info->name); > > > > This gives us things like "pci.0.03.0.rom-rtl8139". For pci-assign, we > > can expand on the host details, such as: > > .. > > Giving us "pci.0.04.0.bar0-pci-assign(0000:01:10.0)". Anywhere closer? > > Not really. This identifier is device and bus independent, which is why I > suggested passing the device to qemu_ram_alloc. This can then figure out how > to the identify the device. It should probably do this the same way that we > identify the saved state for the device. Currently I think this is an > arbitrary vmstate name/id, but I expect this to change to a qdev address > (e.g. /i440FX-pcihost/pci.0/_addr_04.0"). Ok, that seems fairly reasonable, so from a device pointer we can get something like "/i440FX-pcihost/pci.0/_addr_04.0", then we can add something like ":rom" or ":bar.0" to it via an extra string. qemu_ram_alloc(DeviceState *dev, const char *info, size) Does a function already exist to print out a qdev address path? I don't want to guess at something based on only this example. Is there a reserved/unused character we can use to separate the qdev device string from the supplied name? Thanks, Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58061 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMOZI-0005ky-6H for qemu-devel@nongnu.org; Wed, 09 Jun 2010 12:55:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMOZH-0001Do-14 for qemu-devel@nongnu.org; Wed, 09 Jun 2010 12:55:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53686) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMOZG-0001Dc-QH for qemu-devel@nongnu.org; Wed, 09 Jun 2010 12:55:55 -0400 Subject: Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field From: Alex Williamson In-Reply-To: <201006091318.49556.paul@codesourcery.com> References: <20100608191447.4451.47795.stgit@localhost.localdomain> <201006090354.05197.paul@codesourcery.com> <1276057143.3079.57.camel@x201> <201006091318.49556.paul@codesourcery.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Jun 2010 10:37:29 -0600 Message-ID: <1276101449.3079.74.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: Paul Brook Cc: chrisw@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org On Wed, 2010-06-09 at 13:18 +0100, Paul Brook wrote: > > > > Not all ram is associated with a device. > > > > > > Maybe not, but where it is we should be using that information. > > > Absolute minimum we should be using the existing qdev address rather than > > > inventing a new one. Duplicating this logic inside every device seems > > > like a bad idea so I suggest identifying ram blocks by a (name, device) > > > pair. For now we can allow a NULL device for system memory. > > > > I'm not sure if this is what you're after, but what if we change it to > > something like: > > > > + snprintf(name, sizeof(name), "%s.%02x.%x.rom-%s", > > + pdev->bus->qbus.name, PCI_SLOT(pdev->devfn), > > + PCI_FUNC(pdev->devfn), pdev->qdev.info->name); > > > > This gives us things like "pci.0.03.0.rom-rtl8139". For pci-assign, we > > can expand on the host details, such as: > > .. > > Giving us "pci.0.04.0.bar0-pci-assign(0000:01:10.0)". Anywhere closer? > > Not really. This identifier is device and bus independent, which is why I > suggested passing the device to qemu_ram_alloc. This can then figure out how > to the identify the device. It should probably do this the same way that we > identify the saved state for the device. Currently I think this is an > arbitrary vmstate name/id, but I expect this to change to a qdev address > (e.g. /i440FX-pcihost/pci.0/_addr_04.0"). Ok, that seems fairly reasonable, so from a device pointer we can get something like "/i440FX-pcihost/pci.0/_addr_04.0", then we can add something like ":rom" or ":bar.0" to it via an extra string. qemu_ram_alloc(DeviceState *dev, const char *info, size) Does a function already exist to print out a qdev address path? I don't want to guess at something based on only this example. Is there a reserved/unused character we can use to separate the qdev device string from the supplied name? Thanks, Alex