From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=36620 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OR4Re-0008Nz-Oe
	for qemu-devel@nongnu.org; Tue, 22 Jun 2010 10:27:24 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OR4Rc-0002AF-Tv
	for qemu-devel@nongnu.org; Tue, 22 Jun 2010 10:27:22 -0400
Received: from mail-gw0-f45.google.com ([74.125.83.45]:61988)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OR4Rc-00029y-RV
	for qemu-devel@nongnu.org; Tue, 22 Jun 2010 10:27:20 -0400
Received: by gwb19 with SMTP id 19so681413gwb.4
	for <qemu-devel@nongnu.org>; Tue, 22 Jun 2010 07:27:18 -0700 (PDT)
Message-ID: <4C20C846.2050505@codemonkey.ws>
Date: Tue, 22 Jun 2010 09:27:18 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <20100614054923.879.33717.stgit@localhost.localdomain>
	<m3d3vr48f6.fsf@blackfin.pond.sub.org>
In-Reply-To: <m3d3vr48f6.fsf@blackfin.pond.sub.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: RFC qdev path semantics
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: chrisw@redhat.com, kvm@vger.kernel.org, qemu-devel@nongnu.org, Alex Williamson <alex.williamson@redhat.com>, kraxel@redhat.com, avi@redhat.com, paul@codesourcery.com

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