Re: softmmu 'at' instruction support

[Janne Karhunen]

On Thu, Nov 18, 2021 at 5:40 PM Peter Maydell <peter.maydell@linaro.org> wrote:

> > 11610     ttbr = regime_ttbr(env, mmu_idx, param.select);
> > (gdb) n
> > 11616     if (param.epd) {
> > (gdb) p/x ttbr
> > $1 = 0x41730000
> >
> > So it starts looking from the wrong table (off by one page) ... ?
>
> My guess is that your guest code and QEMU disagree about how aligned
> the page table needs to be, and that extra 1 in bit 12 is being
> cleared out because QEMU is implementing it as RES0.

I added bug because it still looks like one to me:
https://gitlab.com/qemu-project/qemu/-/issues/735

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:

    /*
     * Bit 55 is always between the two regions, and is canonical for
     * determining if address tagging is enabled.
     */
    select = extract64(va, 55, 1);
    if (!select) {

Which, IMHO, is just a Linux convention to set up the high bits.  I
can work around that issue by setting that bit, and then it goes a bit
further:

..
        target_ulong top_bits = sextract64(address, inputsize,
                                           addrsize - inputsize);
        if (-top_bits != param.select) {
..

And fails here. I can understand this check a bit better and arrange
it, but before going there I'd like to understand why this wasn't used
as TTBRN to 'regime_ttbr' ?
uint32_t el = regime_el(env, mmu_idx);

It determines the calling el just nicely before, but doesn't use this
and goes about using the magical bit 55?


--
Janne