Re: softmmu 'at' instruction support

[Peter Maydell]

On Fri, 19 Nov 2021 at 13:49, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> On Fri, Nov 19, 2021 at 12:54 PM Janne Karhunen
> <janne.karhunen@gmail.com> wrote:
>
> > So 'at' reads in regime_ttbr:
> > 10541         return env->cp15.ttbr0_el[regime_el(env, mmu_idx)];
> > (gdb) p/x env->cp15.ttbr0_el[regime_el(env, mmu_idx)]
> > $1 = 0x41730000
> >
> > Which is wrong. The runtime reads:
> > 10543         return env->cp15.ttbr1_el[regime_el(env, mmu_idx)];
> > (gdb) p/x env->cp15.ttbr1_el[regime_el(env, mmu_idx)]
> > $1 = 0x41731001
> >
> > The determining factor about which one is used is in
> > aa64_va_parameters, and it's the bit 55:
>
> I stand corrected - looks like D5.1 in the arch spec does state that
> the bit 55 makes the selection.
>
> Interesting. Looks like just padding the address linux style with
> 0xffff8 is the key to happiness if you expect answers from ttbr1_el1.

Figure D5-13 is useful here. Essentially TTBR1 is used for
a chunk of the virtual address space starting from the top
(0xFFFF_FFFF_FFFF_FFFF and working downwards based on T1SZ),
and TTBR0 is used for a chunk of the address space starting from
the bottom (0 and working upwards based on T0SZ). There's a gap
in the middle which always gives a translation fault.
This is different from AArch32, where there's no gap, and the
TTBR1 range starts where the TTBR0 one stops.

I think it's better not to think of this as "padding the address",
but instead that valid addresses are always in these ranges.
If you have something whose high bits are not all-0 or all-1
then you should ask yourself how the address got mangled.

Note also that not all ELs have two TTBRs; some have only TTBR0,
in which case you get figure D5-2, with just the starting-from-0
part of the address space being valid.

Big question: I thought we were talking about doing lookups
on virtual address 0 here? That should be using TTBR0, so why
do you expect it to be using TTBR1?

-- PMM