Re: RFC qdev path semantics

Anthony Liguori
2010-06-22T14:27:17Z

On 06/16/2010 04:46 AM, Markus Armbruster wrote:
> A number of changes to qdev paths have been proposed in various threads.
> It's becoming harder to keep track of them, so let me sum them up in one
> place. Please correct me if I misrepresent your ideas.
>

Honestly, I think we've gone off the deep end here. Let's simplify.

We need to uniquely identify ram allocations for the purposes of
savevm. Let's do this:

qdev has a vmsd property. When the qdev device is initialized, it
invokes vmstate_register_with_alias_id.

Let's have vmstate_register_with_alias_id return a unique identifier.
Today, it should be derived from the section header. In the future, it
should be a qdev path (as should the section header).

We need have a qdev->vmsd_base. pci_add_option_rom() will pass
qdev->vmsd_base + a unique suffix to qemu_ram_alloc() which should be in
the form '/suffix'. This suffix only need to identify the ram area
uniquely for for pci_add_option_rom, it should probably be '/PCI-ROM'.

Today, this means that the ram allocations will be consistent with
VMState which is a good thing on the wire. In the future, when we have
full qdev conversion, we can easily switch to using qdev paths as the
vmsd_base with almost no code change.

Regards,

Anthony Liguori