On 21.08.2012, at 00:13, Peter Maydell wrote: > On 20 August 2012 22:46, Alexander Graf <agraf@xxxxxxx> wrote: >> On 20.08.2012, at 23:41, Peter Maydell wrote: >>> One random idea I had was that we could continue to use the >>> GET/SET_MSRS API, but we define some part of the space (eg >>> top half of index == 0x20) for more convenient direct access >>> to this state. Certainly for the cache registers, we'd only >>> need to actually implement this if the kernel supported >>> showing the guest fake values, in which case it will have the >>> fake values in some bit of its structures and use these >>> when handling the cache registers on guest access traps. In >>> that case actually doing the save/load bit would be pretty >>> trivial (in fact easier than handling userspace accesses >>> via fiddling the select register!). >> >> How many bits of cp15 space do you have? Couldn't you just use >> the ONE_REG API, allocate a block for your "normal" cp15 encoding >> and add the special cases as special ONE_REG entries above? > > The idea of the GET/SET_MSRS index encoding is that we left > ourselves lots of space for other purposes (we're planning > to use it for save/load of floating point registers and also > VGIC state). The index looks like this: > > 64-bit coprocessor register: > ...|19 18 17 16|15|14 13 12 11 10 9 8| 7 6 5 4 |3 2 1 0| > ...0 0 | cp num | 1| 0 0 0 0 0 0 0| opc1 | CRm | > > 32-bit coprocessor register: > ...|19 18 17 16|15|14|13 12 11|10 9 8 7 |6 5 4 |3 2 1 0| > ...0 0 | cp num | 0| 0| opc1 | CRn | opc2 | CRm | > > Non-coprocessor register: > > | 32 31 30 29 28 27 26 25 24 23 22 21 20|19 18 17 16 15 ... > | < some non-zero value > | ... > > > (so effectively the top 16 bits are "what block of registers?" > where we've allocated blocks 0..15 for cp0..cp15 and I'm > suggesting block 16 for random more convenient access to > cp15 state.) My question still holds. Why not use ONE_REG for this? What advantage does GET/SET_MSRS give you? Alex _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
