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~
