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

[Anthony Liguori]

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<address@hidden>  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