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 ;) Alex
