Hello,
Richard Henderson <richard.hender...@linaro.org> writes:
> Based-on: 20250727074202.83141-1-richard.hender...@linaro.org
> ("[PATCH for-10.2 v9 0/6] target/arm: Add FEAT_MEC to max cpu")
>
> Tree: https://gitlab.com/rth7680/qemu/-/tree/tgt-arm-gcs
>
> This includes the prerequisite features, ATS1A and S1PIE, and
> not a prerequisite but closely related, S2PIE.
>
> This passes the linux kselftests for gcs, with a 48-bit VA.
> I also include a few smoke tests in tests/tcg/.
>
> There's something subtly wrong with a 52-bit VA. Most everything
> works fine, but the first GCS lookup faults on a missing level 3
> page table entry: a Translation fault, not a Permission fault.
> The kernel then panics. Either there's something amiss with our
> implementation of FEAT_LPA2, or there's a kernel bug.
>
> This includes a best-effort linux-user implementation. Since we
> don't have softmmu in user-only (yet), gcs stack pages get normal
> read/write access. This means we cannot write-protect the pages
> in the same way the system implementation can. But all of the
> other parts of GCS work fine, which is good enough for testing.
>
> Changes for v2:
> - Add arm_mmuidx_is_valid
> - Revise and merge back the linux-user/aarch64 changes for
> syndromes and ESR records.
I finally managed to test your branch with my GDB patches for GCS
support in Linux userspace.
Most of the GDB tests pass. The only failure is in a test which sets the
GCSPR in a process to a bogus value. This causes the process to get a
SIGBUS:
(gdb) set $gcspr = 0xbadc0ffee
(gdb) continue
Continuing.
Program received signal SIGBUS, Bus error.
normal_function0 () at /path/to/gdb/testsuite/gdb.arch/aarch64-gcs.c:121
121 __asm__ volatile ("ret\n");
In the FVP emulator, the process gets a SIGSEGV instead, so that is what
my test expects:
(gdb) set $gcspr = 0xbadc0ffee
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
normal_function0 () at /path/to/gdb/testsuite/gdb.arch/aarch64-gcs.c:121
121 __asm__ volatile ("ret\n");
I don't know whether this is a bug or just a different permissible
behaviour, in which case I can easily adjust my test to expect either
signal.
I'm using Linux v6.16.0-rc7.
--
Thiago
