Re: [Qemu-devel] tcg & sparc mmu

Re: [Qemu-devel] tcg & sparc mmu

[Richard Henderson]

On 05/21/2015 02:06 AM, Artyom Tarasenko wrote:
> Hi Richard,
> 
> looking at target-sparc/cpu.h and target-sparc/ldst_helper.c I have an
> impression, that 2 mmu modes are not enough for sparc (32) machines:
> they have 4 types of accesses: the combination of user/privileged and
> data/code.

Data vs code doesn't need separate mmu modes.  Just different methods of
access.  That said, sparc64 has 6 modes...

> Also afaics cpu_ldu{b,w,l,q}_code uses the currently selected MMU mode.
> if this is correct, the current implementation of ASI 0x9 ( /*
> Supervisor code access */) in target-sparc/ldst_helper.c is imprecise,
> it would use the current mmu translation which is not necessarily
> privileged.

On sparc32, we are guaranteed to be privileged, and there's a check for that in
the translator.

#ifndef TARGET_SPARC64
                    if (IS_IMM)
                        goto illegal_insn;
                    if (!supervisor(dc))
                        goto priv_insn;
#endif

On sparc64, there are two modes higher than kernel: nucleus and hypervisor.
For these, the access is being done with the wrong mode.  Further, there's no
check in helper_ld_asi for permissions.  The double-bug means there isn't
currently a hole in user accessing supervisor code, but to fix one bug requires
that we fix the other.

> Also I wonder how to implement a user_code access (ASI 0x8). Do I have
> to add more NB_MMU_MODES?

No, you just need to use the right function.  In this case helper_ld*_cmmu,
which includes an mmu_idx parameter, performs a read with "code" or execute
permissions rather than "data" or read permissions.

This whole area could stand to be totally re-written, btw.  Especially to
support the sparcv9 immediate asi with simple loads from non-default modes, the
byte-swapping asis, and the fpu data movement asis.


r~