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

[Juan Quintela <quintela@redhat.com>]

Alexander Graf <agraf@suse.de> wrote:
> On 22.02.2012, at 17:09, Peter Maydell wrote:
>
>> On 22 February 2012 16:04, Andreas Färber <afaerber@suse.de> wrote:
>>> Am 22.02.2012 16:42, schrieb Peter Maydell:
>>>> On 22 February 2012 15:37, Andreas Färber <afaerber@suse.de> 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 ;)

I have to search that discussion, but I would like to send things as:

{ register_name, register value} array, otherwise inter-version
migration is just impossible (or very painful, that is similar).

Notice that this would also be very useful for x86 and MSR's.  Just now
we send every MSR ad-hock with a new position.

Later, Juan.