On Mon, Aug 20, 2012 at 5:55 AM, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > As I've been working through trying to drive kvm cp15 save/load > via qemu's cpreg hashtable, I ran into an interesting question. > > Some bits of cp15 don't trivially expose their state as a single > register. For example, the cache status registers have a number > of different values which are accessed via writing to a 'select' > register to pick which of them is visible in the 'value' register. > Some of the perf registers come in "write 1 to set, 0 is ignored" > and "write 1 to clear, 0 is ignored" pairs. > > The current kernel ABI just exposes these as registers the same > way the hardware does. Userspace can use this to read/write > the state, but it would have to do it via a sequence of "write > select reg; read value reg; write select reg; read value reg..." > which defeats the intention of the 'many regs' ABI slightly. > > I guess fundamentally somebody has to do the mapping from the > register interface the hw provides to "slurp the state in > and out", so the question is whether it should be userspace > (as now) or the kernel... > > I don't have a concrete suggestion for this yet, I just thought > I'd raise the issue in case somebody else had a good idea. > Is there a current need (or reasonably foreseeable future one) to read these registers from user space? If so, I think the multi-kernel crossing approach sounds awful, but an interface for this sounds on the other hand complicated and annoying. I guess to me awful trumps complicated and annoying and the kernel should do the work, but I sure hope it's not a priority. -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm