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

[Andreas Färber]

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

> 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.

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg