From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MNpMg-00020x-64
	for qemu-devel@nongnu.org; Mon, 06 Jul 2009 10:40:18 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MNpMb-0001uN-Ap
	for qemu-devel@nongnu.org; Mon, 06 Jul 2009 10:40:17 -0400
Received: from [199.232.76.173] (port=54642 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MNpMb-0001tG-63
	for qemu-devel@nongnu.org; Mon, 06 Jul 2009 10:40:13 -0400
Received: from mx2.redhat.com ([66.187.237.31]:35875)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1MNpMZ-0004Q9-T8
	for qemu-devel@nongnu.org; Mon, 06 Jul 2009 10:40:12 -0400
Message-ID: <4A520CC6.7060802@redhat.com>
Date: Mon, 06 Jul 2009 16:40:06 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH 0/4] Machine config files
References: <20090610173803.4674.82538.stgit@wren.home>
	<878wjx374h.fsf@pike.pond.sub.org>
	<4A3269C3.3050307@redhat.com> <4A327E2C.1060207@siemens.com>
	<20090706124928.GB11998@redhat.com> <4A51FF7B.4000602@redhat.com>
	<20090706135616.GA12141@redhat.com>
	<20090706140129.GB12141@redhat.com>
In-Reply-To: <20090706140129.GB12141@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; 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.gnu.org/pipermail/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: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org

On 07/06/09 16:01, Michael S. Tsirkin wrote:
>>> Current savevm
>>> doesn't do that, thats why you have to start the virtual machine with
>>> the complete set of command line arguments even when resuming /
>>> migrating.
>
> It seems that it'd be trivial to solve this just by adding a fixed size header
> telling you which load function to call. No?

No.  Go read the code.

User adds -somedev params,more=options to the command line.  Qemu asks 
the corresponding driver to creates a device instance.  Every device 
instance registers loadvm/savevm callbacks to load/save state (tagged 
with name + instance id).

When loading vm state qemu will see name + instance id.  There is no way 
to figure the actual driver from that.

Additionall issue: There is no standardized way to create a device 
instance.  This one will be fixed by qdev though.

It might make sense to integrate savevm callbacks into qdev, then you'd 
have actually a chance to figure which driver belongs to your piece of 
savevm state.  I suspect it isn't enougth to make it work though, you 
still need to know the position of the device in the device tree.  To 
answer questions like "is your pci device behind a bridge and if so 
which one?".

cheers,
   Gerd