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

[Alexander Graf]

On 22.02.2012, at 17:09, Peter Maydell wrote:

> 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).

Yup. A nice side effect of this is that you have a known-small size of 
cp15_regs[]. But I suggested a lot of things during that discussion, so I quite 
frankly don't remember if that was the conclusion or just one idea ;)


Alex