From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Mdgk4-0004As-SQ
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 04:42:00 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Mdgjz-00046G-CB
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 04:42:00 -0400
Received: from [199.232.76.173] (port=54744 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Mdgjz-000467-66
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 04:41:55 -0400
Received: from [66.187.237.31] (port=41338 helo=mx2.redhat.com)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1Mdgjy-0008LY-Kt
	for qemu-devel@nongnu.org; Wed, 19 Aug 2009 04:41:54 -0400
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7J8fr3W006819
	for <qemu-devel@nongnu.org>; Wed, 19 Aug 2009 04:41:53 -0400
Message-ID: <4A8BB101.9000305@redhat.com>
Date: Wed, 19 Aug 2009 10:00:01 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH 5/5] Port apic to new VMState design
References: <cover.1250601335.git.quintela@redhat.com>	<a3855a79d668644c469314af26cc3b4e67ae0054.1250601335.git.quintela@redhat.com>	<20090818142405.GA16563@1und1.de>
	<m37hx1tc9l.fsf@neno.mitica> <20090818152112.GA5483@1und1.de>
In-Reply-To: <20090818152112.GA5483@1und1.de>
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: Juan Quintela <quintela@redhat.com>, qemu-devel@nongnu.org


> Basically what I am asking is if you couldn't just add an optional
> callback so some additional stuff can be done after the "basic" state
> has been loaded - or if that isn't desired at least a callback that
> allows verifying the loaded values and aborting execution.

I think we are going to need post-processing callbacks anyway.  Several 
drivers have to do some actions after loading the state information. 
There you'll be able to set the stats size and also perform sanity 
checks on the loaded state.

> That is completely different from what I meant.
> Changing the RAM compromises the VM and only the VM, an exploit in a
> device emulation might allow to compromise the _host_. Is it now clearer
> what I meant?

When you are able modify the savevm state you already have access to the 
host ...

cheers,
   Gerd