From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=36744 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OMzsS-00071f-Je
	for qemu-devel@nongnu.org; Fri, 11 Jun 2010 04:46:13 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <kraxel@redhat.com>) id 1OMzsR-0005lr-3T
	for qemu-devel@nongnu.org; Fri, 11 Jun 2010 04:46:12 -0400
Received: from mx1.redhat.com ([209.132.183.28]:10121)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <kraxel@redhat.com>) id 1OMzsQ-0005lQ-Se
	for qemu-devel@nongnu.org; Fri, 11 Jun 2010 04:46:11 -0400
Message-ID: <4C11F7B4.2080506@redhat.com>
Date: Fri, 11 Jun 2010 10:45:40 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field
References: <20100608191447.4451.47795.stgit@localhost.localdomain>	
	<201006091318.49556.paul@codesourcery.com>
	<1276101449.3079.74.camel@x201>	
	<201006092136.38569.paul@codesourcery.com>
	<4C10A106.1050108@redhat.com> <1276180408.2992.12.camel@x201>
In-Reply-To: <1276180408.2992.12.camel@x201>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Alex Williamson <alex.williamson@redhat.com>
Cc: chrisw@redhat.com, kvm@vger.kernel.org, quintela@redhat.com, qemu-devel@nongnu.org, Paul Brook <paul@codesourcery.com>

On 06/10/10 16:33, Alex Williamson wrote:
> On Thu, 2010-06-10 at 10:23 +0200, Gerd Hoffmann wrote:
>>> I may have been a bit misleading here. What we really want to do is use the
>>> same matching algorithm as is used by the rest of the device state. Currently
>>> this is a vmstate name and [arbitrary] numeric id. I don't remember whether
>>> there's a convenient link from a device to its associated vmstate - if there
>>> isn't there probably should be.
>>
>> DeviceState->info->vmsd->name for the name.
>> Dunno about the numeric id, I think savevm.c doesn't export it.
>
> Ok, we can certainly do<vmsd->name>.<vmsd->instance>\<driver string>.
> It seems like this highlights a deficiency in the vmstate matching
> though.  If on the source we do:
>
>> pci_add addr=4 nic model=e1000
>> pci_add addr=3 nic model=e1000
>
> Then we start the target, ordering the nics sequentially, are we going
> to store the vmstate into the opposite nics?

I think so.  We should be able to handle that better.  Nevertheless it 
makes sense to use the same naming scheme for device state and device 
ram.  If we fix this for the device state some day (using qdev most 
likely), we'll go change device ram handling the same way.

cheers,
   Gerd