From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N7qqx-0002gF-26
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 08:33:47 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N7qqs-0002aN-A3
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 08:33:46 -0500
Received: from [199.232.76.173] (port=37299 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N7qqs-0002aJ-56
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 08:33:42 -0500
Received: from mail2.shareable.org ([80.68.89.115]:43762)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1N7qqr-0003NA-OY
	for qemu-devel@nongnu.org; Tue, 10 Nov 2009 08:33:42 -0500
Date: Tue, 10 Nov 2009 13:33:38 +0000
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for
	qemu
Message-ID: <20091110133338.GC28509@shareable.org>
References: <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>
	<4AF95BA6.6000602@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4AF95BA6.6000602@redhat.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.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: Avi Kivity <avi@redhat.com>
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>

Avi Kivity wrote:
> 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).

That's great, thanks.  I was wondering if KVM did something magical
with memory to make itself work, and it seems the answer is "it might
have done before", which is fine for my nefarious purpose.

Thanks again for your helpful explanation.

-- Jamie