On 3/18/25 18:16, Richard Henderson wrote:
On 3/18/25 17:02, Pierrick Bouvier wrote:
On 3/18/25 14:31, Richard Henderson wrote:
The implementation of cpu_mmu_index was split between cpu-common.h
and cpu-all.h, depending on CONFIG_USER_ONLY. We already have the
plumbing common to user and system mode. Using MMU_USER_IDX
requires the cpu.h for a specific target, and so is restricted to
when we're compiling per-target.
A side question: Why is MMU_USER_IDX different depending on architecture?
I'm trying to understand why (and by what) previous indexes are reserved when
MMU_USER_IDX
is not zero.
Depends on the translator, but often: cpu_mmu_index may be encoded into
tb_flags, and the
translator *also* uses this encoding to determine the priv state. So if, in
user-only
mode, we fail to encode MMU_USER_IDX into tb_flags, we'll get incorrect priv
checks in the
translator and fail to raise SIGILL for privledged operations.
Depending on the target, the mmu_index space may be quite complicated, with
various
meanings assigned to various bits. Thus "0" may not be reasonable for
MMU_USER_IDX.
See, for instance, enum ARMMMUIdx or ppc hreg_compute_hflags_value().
(Both of which, amusingly, use MMU_USER_IDX 0; neither here nor there.)
Thanks for your answer.
If I understand correctly, this is simply an (arbitrary) choice related
to each target architecture implemented in QEMU, and it does not match
any property of a *real* cpu. Is that correct?
In other words, it could have been implemented in a way that
MMU_USER_IDX is the same for all arch, but it hasn't been done this way.
Is that correct?
I'm not looking for modifying anything related to this, just want to
make sure I get it right.
r~
