Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field

[Anthony Liguori <anthony@codemonkey.ws>]

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:
>>>>> 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.

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.
>