From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=36163 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OMktP-0002Jm-H0
	for qemu-devel@nongnu.org; Thu, 10 Jun 2010 12:46:12 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <paul@codesourcery.com>) id 1OMktN-0001SK-Mu
	for qemu-devel@nongnu.org; Thu, 10 Jun 2010 12:46:11 -0400
Received: from mail.codesourcery.com ([38.113.113.100]:60850)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <paul@codesourcery.com>) id 1OMktN-0001Rm-Cn
	for qemu-devel@nongnu.org; Thu, 10 Jun 2010 12:46:09 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field
Date: Thu, 10 Jun 2010 17:45:06 +0100
References: <20100608191447.4451.47795.stgit@localhost.localdomain>
	<1276101449.3079.74.camel@x201>
	<20100610164016.GG14393@x200.localdomain>
In-Reply-To: <20100610164016.GG14393@x200.localdomain>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201006101745.07039.paul@codesourcery.com>
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: Chris Wright <chrisw@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>, quintela@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org

> > > to the identify the device. It should probably do this the same way
> > > that we identify the saved state for the device.  Currently I think
> > > this is an arbitrary vmstate name/id, but I expect this to change to a
> > > qdev address (e.g. /i440FX-pcihost/pci.0/_addr_04.0").
> > 
> > Ok, that seems fairly reasonable, so from a device pointer we can get
> > something like "/i440FX-pcihost/pci.0/_addr_04.0", then we can add
> > something like ":rom" or ":bar.0" to it via an extra string.
> 
> In the fun game of what ifs...
> 
> The cmdline starts w/ device A placed at pci bus addr 00:04.0 (so
> matched on source and target).  The source does hotunplug of 04.0 and
> replaces it w/ new device.  I think we need something that is more
> uniquely identifying the block.  Not sure that device name is correct or
> a generation ID.

You shouldn't be solving this problem for RAM blocks. You should be solving it 
for the device state.

Paul