From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:51783)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1UIflO-0005K3-2c
	for qemu-devel@nongnu.org; Thu, 21 Mar 2013 09:42:41 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1UIflI-0006vX-Of
	for qemu-devel@nongnu.org; Thu, 21 Mar 2013 09:42:37 -0400
Received: from mx1.redhat.com ([209.132.183.28]:36116)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1UIflI-0006v4-C7
	for qemu-devel@nongnu.org; Thu, 21 Mar 2013 09:42:32 -0400
Message-ID: <514B0E3F.5070309@redhat.com>
Date: Thu, 21 Mar 2013 14:42:23 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <5142CCB6.7000004@linux.vnet.ibm.com> <51471686.3030505@redhat.com>
	<514AABFC.1030605@linux.vnet.ibm.com> <514AF393.8030109@redhat.com>
	<20130321133802.GA15276@stefanha-thinkpad.redhat.com>
In-Reply-To: <20130321133802.GA15276@stefanha-thinkpad.redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC] qmp interface for save vmstate to image
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Pavel Hrdina <phrdina@redhat.com>, Juan Quintela <quintela@redhat.com>, qemu-devel <qemu-devel@nongnu.org>, Dietmar Maurer <dietmar@proxmox.com>, Wenchao Xia <xiawenc@linux.vnet.ibm.com>

Il 21/03/2013 14:38, Stefan Hajnoczi ha scritto:
> There already is a guest RAM cloning mechanism: fork the QEMU process.
> Then you have a copy-on-write guest RAM.
> 
> In a little more detail:
> 
> 1. save non-RAM device state
> 2. quiesce QEMU to a state that is safe for forking
> 3. create an EventNotifier for live savevm completion signal
> 4. fork and pass completion EventNotifier to child
> 5. parent continues running VM
> 6. child performs vmsave of copy-on-write guest RAM
> 7. child signals completion EventNotifier and terminates
> 8. parent raises live savevm completion QMP event

Forking a threaded program is not so easy, but it could be done if the
child is very simple and only uses syscalls to communicate back with the
parent:

1. save non-RAM device state
2. quiesce QEMU to a state that is safe for forking
3. create a memory map and a pipe
4. fork and pass the write end of the pipe to the child
5. parent continues running VM
6. child reads the memory map and writes data to the pipe
7. parent copies data from the pipe to the migration stream
8. child exits, parent raises live savevm completion QMP event

Paolo