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

[Igor Mitsyanko <i.mitsyanko@samsung.com>]

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.