qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: RFC qdev path semantics


From: Anthony Liguori
Subject: [Qemu-devel] Re: RFC qdev path semantics
Date: Tue, 22 Jun 2010 09:27:18 -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/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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]