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