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.)
-- PMM
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
