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

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/09/2012 04:23 PM, Peter Maydell wrote:
> Ping re the VMState and variable sized arrays issue. I don't
> see any consensus in this discussion for a different approach,
> so should we just commit Mitsyanko's patchset?

I don't know if I mentioned this, but do we really need variable sizes?

Can we just use a fixed size (pre-allocated) array and then use a VMSTATE_SUB_ARRAY?

If it's truly variable size with no upper bound, then that's actually a security 
problem since it implies a guest can do unbounded memory allocation.

Regards,

Anthony Liguori

>
> - PMM
>
> On 31 January 2012 13:15, Andreas Färber<afaerber@suse.de>  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)
>>
>> Therefore I'm waiting for some resolution.
>>
>> Regards,
>> Andreas
>