Re: [Qemu-devel] KVM call agenda for tuesday 31

[Igor Mitsyanko]

On 08/08/2012 08:25 PM, Andreas Färber wrote:
> Am 31.01.2012 15:01, schrieb Mitsyanko Igor:
> > On 01/31/2012 05:15 PM, Andreas Färber wrote:
> > > Am 31.01.2012 00:53, schrieb Anthony Liguori:
> > > > On 01/30/2012 05:41 PM, Andreas Färber wrote:
> > > > > Am 30.01.2012 19:55, schrieb Juan Quintela:
> > > > > > Please send in any agenda items you are interested in covering.
> > > > > VMState:
> > > > > Anthony specifically said that VMState were not affected by QOM and
> > > > > that
> > > > > patches should not be deferred until the merge. Yet there's no review
> > > > > and/or decision-making for a month now. Ping^2 for AHCI+SDHC.
> > > > Do you have pointers (to pending VMState patches)?
> > > http://patchwork.ozlabs.org/patch/137732/ (PATCH v4)
> > >
> > > It's basically about how to deal with variable-sized arrays. (Alex
> > > mentioned it on one call around November.) I found ways to deal with
> > > subsets of arrays embedded within the struct and variable-sized list of
> > > pointers to structs but no solution for a malloc()'ed array of structs.
> > > Maybe I'm just too stupid to see. Anyway, no one commented since Xmas.
> > >
> > > Igor posted (and refined for v2) a patch with a callback-based approach
> > > that I find promising. From my view, unofficially Juan is the VMState
> > > guy, he's been cc'ed. Are we lacking an official maintainer that cares?
> > > Or is Juan the official, undocumented maintainer but simply busy?
> > >
> > > SUSE's interest is making AHCI migratable, and my VMState workaround for
> > > that is simply ugly:
> > >
> > > http://patchwork.ozlabs.org/patch/133066/ (RFC)
> > If I'm not mistaken, if you change AHCIState's ".ports" type to uint32_t
> > you can use existing VMSTATE_BUFFER_MULTIPLY macro like this:
> >
> > VMSTATE_BUFFER_MULTIPLY(dev, AHCIState, 0, NULL, 0, ports,
> > sizeof(AHCIDevice))
> Igor, I finally got around to rebasing and trying this: Am I seeing
> correctly that this tries to serialize the whole of AHCIDevice as an
> opaque buffer? The difficulty here was that we were looking for a way to
> serialize a variable number of structured elements with their own
> &vmstate_ahci_device specifying what fields to serialize.
>
> Juan, how should we proceed there? Do as Igor suggested? Some VMSTATE_
> macro I'm overlooking? Or do we need some new macro for this use case?
>
> Regards,
> Andreas

Hi Andreas, that was a bad suggestion, sorry for that, we can't treat 
structures as opaque buffers because that wouldn't work when migrating 
between hosts with different alignment/endianess.
Perhaps you can use VMSTATE_STRUCT_VARRAY_UINT32 for this, if I'm not 
again mistaken.

> > VMSTATE_BUFFER_MULTIPLY currently lacks VMS_POINTER flag and therefore
> > doesn't make any use of _start field (you don't need it anyway)
> >
> > Nevertheless, VMSTATE_BUFFER_MULTIPLY is just a partial solution to a
> > bigger set of possible problems. SD card's vmstate implementation
> > requires shift operation, SDHC gets size from switch {} statement,
> > something else later may require division or addition e.t.c.,
> > get_bufsize callback will cover all possible cases.