Re: [Qemu-devel] [PATCH 0/5] VMState cleanups

[Peter Maydell]

On 22 February 2012 16:04, Andreas Färber <address@hidden> wrote:
> Am 22.02.2012 16:42, schrieb Peter Maydell:
>> On 22 February 2012 15:37, Andreas Färber <address@hidden> wrote:
>>> NB: Your cpu-vmstate patches were not applied so far and they appear to
>>> conflict with the plans we've made for redesigning cp15 on ARM: We want
>>> to convert today's static fields to some list and were hoping to have a
>>> mapping function for backwards compatibility. That works easiest in
>>> imperative code.
>>
>> I thought the idea for cp15 for vmstate was (like ppc) to basically
>> have a uint32_t cp15_regs[512] which we save/load the whole of, and
>> then the mapping function just assigns semantics to some subset
>> of that array? vmstate can do a plain array without problems.
>
> I thought we had concluded that the (3+3+4+4)² or so registers were too
> large for that so that Alex suggested to leave the old load/save in
> place (but getting/setting through a mapping function) and dynamically
> appending only the new cp15 registers we don't have fields for yet when
> some arrive. Or so I've understood.

So what I thought Alex was suggesting was to nuke the existing
save/load, and instead we have this generic array. All the
current env->cp15.c1_scr &co turn from being uint32_t to uint32_t*,
and there's an init function per CPU which maps those to point at
slots in the cp15_regs[] array. Indexes into cp15_regs[] are
just arbitrary (though they can't change for a particular CPU
variant or you'd break migration).

The point of this is basically to decouple the save/load format
for different ARM cpu variants from each other, so we can add
registers for (say) A15 without breaking migration compatibility
for (say) A9.

> I was planning some cp15 coding once I've moved some more stuff out of
> CPU_COMMON and resolved the pxa270 CPU classes mess.

I really am going to get on and finish up the half-a-series I have,
honest...

-- PMM