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

[Andreas Färber]

Am 18.03.2013 21:43, schrieb Igor Mitsyanko:
> 
> On Mar 19, 2013 12:21 AM, "Peter Maydell" <address@hidden
> <mailto:address@hidden>> wrote:
>>
>> On 18 March 2013 19:48, Igor Mitsyanko <address@hidden
> <mailto: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.

QIDL - CC'ing Michael.

Andreas

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