qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface


From: Stefan Berger
Subject: Re: [Qemu-devel] [RFC] New Migration Protocol using Visitor Interface
Date: Mon, 03 Oct 2011 09:10:19 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11

On 10/03/2011 08:55 AM, Anthony Liguori wrote:
On 10/02/2011 04:08 PM, Michael S. Tsirkin wrote:
On Sun, Oct 02, 2011 at 04:21:47PM -0400, Stefan Berger wrote:

4) Implement the BERVisitor and make this the default migration protocol.

Most of the work will be in 1), though with the implementation in this series we should be able to do it incrementally. I'm not sure if the best approach is doing the mechanical phase 1 conversion, then doing phase 2 sometime after 4), doing phase 1 + 2 as part of 1), or just doing VMState conversions which gives basically the same capabilities as phase 1 + 2.

Thoughts?
Is anyone working on this? If not I may give it a shot (tomorrow++)
for at least some of the primitives... for enabling vNVRAM metadata
of course. Indefinite length encoding of constructed data types I
suppose won't be used otherwise the visitor interface seems wrong
for parsing and skipping of extra data towards the end of a
structure if version n wrote the stream and appended some of its
version n data and now version m<  n is trying to read the struct
and needs to skip the version [m+1, n ] data fields ... in that case
the de-serialization of the stream should probably be stream-driven
rather than structure-driven.

    Stefan

Yes I've been struggling with that exactly.
Anthony, any thoughts?

It just depends on how you write your visitor. If you used sequences, you'd probably do something like this:

start_struct ->
  check for sequence tag, push starting offset and size onto stack
  increment offset to next tag

type_int (et al) ->
  check for explicit type, parse data
  increment offset to next tag

end_struct ->
  pop starting offset and size to temp variables
  set offset to starting offset + size

This is roughly how the QMP input marshaller works FWIW.

I am doing that. Indefinite length encoding *would* be a problem because you cannot push the size onto the stack so that you could skip to the end of the structure.

   Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]