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