On Sat, Dec 21, 2013 at 4:16 AM, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > On 20 December 2013 10:00, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: >> I'll have a think about this, because there are some wrinkles relating >> to reset that might be usefully solved this way. > > So my conclusion here is that really this boils down to how we > want to deal with sysregs for AArch64 capable CPUs in general. > There are two models I can think of: > > Option 1: > * we provide new reginfo definitions that describe the AArch64 > views of the system registers > * for the AArch32 views, we just fall through and use the existing > definitions we've written for AArch32-only CPUs > > Option 2: > * we provide new reginfo definitions for the AArch64 views of > the registers, which include annotations to say whether there > is an AArch32 view of this register So to clarify, would MIDR and friends be in this bucket? And does t obsolete the old MIDR def such there is only one CPRegInfo globally? > * for the few registers which aren't neatly arranged so the > crn/crm/opc1/opc2 line up, we just split up into a separate > reginfo for AArch64 and AArch32 ACK, that sounds awkward but there nothing we can do abt it. how many are there? The few I checked always line up. > * register_cp_regs_for_features() has separate AArch32 > and AArch64 versions > Do we need this? With this scheme its still possible to enforce exclusivity in the CPRegInfo themselves. > Option 1 is what my initial patch was assuming. Option 2 > is what the idea of being able to mark a reginfo as "this > provides both AArch32 and AArch64 register views" > implies, I think. > > Having thought about it a bit I actually prefer Option 2 > of these -- it means that for a 64 bit CPU the reginfo > dealing with a particular CPUState field will be in one > place rather than two, and we also get a chance to > audit which cp regs go into v8 AArch64 emulated CPUs, > so we don't leak old backwards-compatible dummy > definitions by accident. Agreed. Regards, Peter > > thanks > -- PMM > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
