From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=46787 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OOoSB-0006xp-0J
	for qemu-devel@nongnu.org; Wed, 16 Jun 2010 04:58:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <paolo.bonzini@gmail.com>) id 1OOoS9-00011R-3l
	for qemu-devel@nongnu.org; Wed, 16 Jun 2010 04:58:33 -0400
Received: from fg-out-1718.google.com ([72.14.220.157]:44181)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <paolo.bonzini@gmail.com>) id 1OOoS8-00011I-Vn
	for qemu-devel@nongnu.org; Wed, 16 Jun 2010 04:58:33 -0400
Received: by fg-out-1718.google.com with SMTP id 22so1139370fge.10
	for <qemu-devel@nongnu.org>; Wed, 16 Jun 2010 01:58:31 -0700 (PDT)
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
Message-ID: <4C189235.60401@redhat.com>
Date: Wed, 16 Jun 2010 10:58:29 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <20100615151812.GA24131@x200.localdomain>
In-Reply-To: <20100615151812.GA24131@x200.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: KVM call minutes for June 15
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.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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Chris Wright <chrisw@redhat.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org

On 06/15/2010 05:18 PM, Chris Wright wrote:
> - size for each section would be useful (breaks protocol)
>    - while size is possibly useful, breaks protocol

It is not necessary to break the protocol.  If you're okay with only 
having the size information when the migration data has been saved to a 
file, you can put the directory at the end of the migration data, after 
the EOF section.  Something like

    QEMU_VM_SECTION_EOF
    QEMU_VM_SECTION_DIRECTORY
       copy of the migration data, with the actual data replaced
       by a single 8-byte pointer to the beginning of the section:

       QEMU_VM_SECTION_START
       <section id>
       5 "block"
       <instance id>
       <version id>
       <8-byte pointer>

       QEMU_VM_SECTION_START
       <section id>
       3 "ram"
       <instance id>
       <version id>
       <8-byte pointer>

       ...
       QEMU_VM_SECTION_FULL
       <section id>
       10 "cpu_common"
       <instance id>
       <version id>
       <8-byte pointer>

       ...
       QEMU_VM_SECTION_EOF
       <8-byte pointer>

       QEMU_VM_SECTION_DIRECTORY
       <8-byte pointer>

Note that by definition the last 8 bytes will point to the beginning of 
the directory.  You can read the last 18 bytes to reduce (to almost 
zero) the possibility of a false positive.

The directory table can be built at save time and streamed after the EOF 
without causing an error if the receiver closes its connection during 
the streaming of the directory.

Paolo