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 * 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 * register_cp_regs_for_features() has separate AArch32 and AArch64 versions 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. thanks -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
