From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N7pmo-0008I3-MD
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 07:25:26 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N7pmj-0008Gt-AE
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 07:25:25 -0500
Received: from [199.232.76.173] (port=54002 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N7pmj-0008Gi-51
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 07:25:21 -0500
Received: from mx1.redhat.com ([209.132.183.28]:39120)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1N7pmi-0006Or-NG
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 07:25:20 -0500
Message-ID: <4AF95BA6.6000602@redhat.com>
Date: Tue, 10 Nov 2009 14:25:10 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support
	for qemu
References: <20091105163702.GC21630@shareable.org>
	<4AF30129.7080203@us.ibm.com> <200911051820.48878.arnd@arndb.de>
	<4AF3154F.8090901@redhat.com> <4AF36DE9.3040803@us.ibm.com>
	<4AF3CF8C.1030408@redhat.com> <4AF44A33.6010602@us.ibm.com>
	<4AF53D8C.7080708@redhat.com>
	<20091107104402.GA10410@shareable.org>
	<4AF558A6.4030804@redhat.com> <20091109193521.GF3808@shareable.org>
In-Reply-To: <20091109193521.GF3808@shareable.org>
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: Jamie Lokier <jamie@shareable.org>
Cc: Mark McLoughlin <markmc@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, Arnd Bergmann <arndbergmann@googlemail.com>, agl@linux.vnet.ibm.com, Arnd Bergmann <arnd@arndb.de>, Juan Quintela <quintela@redhat.com>, Dustin Kirkland <kirkland@canonical.com>, qemu-devel@nongnu.org, Michael Tsirkin <mst@redhat.com>

On 11/09/2009 09:35 PM, Jamie Lokier wrote:
>
> What I'd like to know is, if all of QEMU's state is appropriately
> recreated in the child instance, and KVM's device is reopened with a
> copy of the kvm state (by using the recently introduced ioctls to get
> and set it), will it fork the _guest RAM_ mapped into KVM in the way
> that fork does?
>    

Guest RAM is just ordinary userspace memory.  If you told Linux to COW 
it, it will COW it.  If you told Linux not to COW it, it will not COW 
it.  kvm has nothing to say in the matter (at least with kernels 2.6.27 
and up).

-- 
error compiling committee.c: too many arguments to function