From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48653 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMJwv-0005gD-5V for qemu-devel@nongnu.org; Wed, 09 Jun 2010 08:00:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMJvp-0006PF-Vy for qemu-devel@nongnu.org; Wed, 09 Jun 2010 07:58:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16980) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMJvp-0006P5-O1 for qemu-devel@nongnu.org; Wed, 09 Jun 2010 07:58:53 -0400 Message-ID: <4C0F81F2.4030106@redhat.com> Date: Wed, 09 Jun 2010 14:58:42 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field References: <20100608191447.4451.47795.stgit@localhost.localdomain> <201006090330.10324.paul@codesourcery.com> <4C0EFF39.9070602@codemonkey.ws> <201006090354.05197.paul@codesourcery.com> In-Reply-To: <201006090354.05197.paul@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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, kvm@vger.kernel.org, quintela@redhat.com, qemu-devel@nongnu.org, Alex Williamson On 06/09/2010 05:54 AM, Paul Brook wrote: >> On 06/08/2010 09:30 PM, Paul Brook wrote: >> >>>> The offset given to a block created via qemu_ram_alloc/map() is >>>> arbitrary, let the caller specify a name so we can make a positive >>>> match. >>>> >>>> >>>> @@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev) >>>> + snprintf(name, sizeof(name), "pci:%02x.%x.rom", >>>> + PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn)); >>>> + pdev->rom_offset = qemu_ram_alloc(name, size); >>>> >>> This looks pretty bogus. It should be associated with the device, rather >>> than incorrectly trying to generate a globally unique name. >>> >> 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 agree, this is duplicating the qdev tree in a string. Devices/BARs should have ram qdev fields and so ram can be enumerated completely via qdev. System memory can be part of a system device. -- error compiling committee.c: too many arguments to function