|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field |
Date: | Wed, 09 Jun 2010 08:57:44 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 |
On 06/09/2010 06:58 AM, Avi Kivity wrote:
On 06/09/2010 05:54 AM, Paul Brook wrote:On 06/08/2010 09:30 PM, Paul Brook wrote:This looks pretty bogus. It should be associated with the device, ratherThe 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);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 nowwe 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.
Keep in mind, this has to be a stable string across versions of qemu since this is savevm/migration. Are we absolutely confident that the full qdev path isn't going to change? I'm more confident that a unique device name is going to be static across qemu versions.
Regards, Anthony Liguori
System memory can be part of a system device.
[Prev in Thread] | Current Thread | [Next in Thread] |