Re: [Qemu-devel] [PATCH v2 2/2] hw/arm_gic_common: Use vmstate struct rather than save/load functions

[Igor Mitsyanko]

On Mar 19, 2013 12:21 AM, "Peter Maydell" <address@hidden> wrote:
>
> On 18 March 2013 19:48, Igor Mitsyanko <address@hidden> wrote:
> >> On 03/18/2013 09:47 PM, Peter Maydell wrote:
> >>>
> >>> +        VMSTATE_BUFFER_UNSAFE(last_active, GICState, 0,
> >>> +                              GIC_MAXIRQ * NCPU * sizeof(uint16_t)),
>
> > I'm not sure about this one, do we have any guarantees that it will always
> > be tightly packed? What will happen when we will try to migrate VM between
> > BE and LE hosts?
>
> Ugh. I think the packing is ok but I hadn't thought about the
> endianness issue.
>
> Gerd and I were talking on IRC about 2D arrays. I think we came to
> the conclusion that you could provide a new set of vmstate macros
> for 2D arrays which basically work just like the existing 1D array
> ones except that the typecheck is different.
>
> (vmstate.h is getting hugely repetitive to the point that I'm
> really tempted to say we should just autogenerate it. That way
> you could define a fairly small set of things (arrays, base types,
> safe vs unsafe, etc) and have a script generate the cross product,
> rather than the current setup where there is a lot of hand written
> repetition and a tendency to gaps in the coverage where nobody's
> using them yet.)
>
> -- PMM

I can recall a qemu-devel discussion over a long-term QOM goals a while ago.Somebody suggested that in the future we will define devices state structures using some special macro which will be parsed during compilation, serializing each member for both QOM introspection and vmstate migration.