Since v4:

- Moved MECID_WIDTH from cpu.h to internal.h
- Fixed stray ';'s in access and write functions
- Use of GET_IDREG/FIELD_DP64/SET_IDREG for setting feature in ID regs
- Sorted correctly isar_feature_aa64_* AA64MMFR3 tests
- Simplified/unified accessfn for cache instructions
- Fixed how cache instruction-related registers are registered in the cpu

Since v5:
- Fixed missing checks for ARM_FEATURE_EL3 in sctlr2_el2_access and
  tcr2_el2_access functions

v1: https://mail.gnu.org/archive/html/qemu-devel/2025-06/msg04598.html 
v2: https://mail.gnu.org/archive/html/qemu-devel/2025-07/msg01799.html
v3: https://mail.gnu.org/archive/html/qemu-devel/2025-07/msg02338.html
v4: https://mail.gnu.org/archive/html/qemu-devel/2025-07/msg02488.html
v5: https://mail.gnu.org/archive/html/qemu-devel/2025-07/msg02689.html

This series adds support for all FEAT_MEC registers and cache instructions to
the Arm64 max CPU.

It includes the FEAT_MEC registers and cache maintenance instructions, but does
not modify the translation regimes to support the MECIDs, so no encryption is
supported yet. However, software stacks that rely on FEAT_MEC should work
properly at this point.

I'm currently exploring possibilities to support FEAT_MEC encryption (or
obfuscation, for testing purposes) in QEMU for the various translation regimes
on arm64, hence the encryption part of FEAT_MEC will be contributed later and is
not targeted for QEMU 10.1.


Cheers,
Gustavo

Gustavo Romero (6):
  target/arm: Add the MECEn SCR_EL3 bit
  target/arm: Add FEAT_MEC registers
  target/arm: Add FEAT_SCTLR2
  target/arm: Add FEAT_TCR2
  target/arm: Implement FEAT_MEC cache instructions
  target/arm: Advertise FEAT_MEC in cpu max

 docs/system/arm/emulation.rst |   5 +
 target/arm/cpu-features.h     |  15 +++
 target/arm/cpu.h              |  27 ++++
 target/arm/helper.c           | 236 ++++++++++++++++++++++++++++++++++
 target/arm/internals.h        |  23 ++++
 target/arm/tcg/cpu64.c        |   7 +-
 6 files changed, 312 insertions(+), 1 deletion(-)

-- 
2.34.1

On Thu, 10 Jul 2025 at 22:11, Gustavo Romero <gustavo.romero@linaro.org> wrote:
>
> Since v4:
>
> - Moved MECID_WIDTH from cpu.h to internal.h
> - Fixed stray ';'s in access and write functions
> - Use of GET_IDREG/FIELD_DP64/SET_IDREG for setting feature in ID regs
> - Sorted correctly isar_feature_aa64_* AA64MMFR3 tests
> - Simplified/unified accessfn for cache instructions
> - Fixed how cache instruction-related registers are registered in the cpu
>
> Since v5:
> - Fixed missing checks for ARM_FEATURE_EL3 in sctlr2_el2_access and
>   tcr2_el2_access functions
>
> v1: https://mail.gnu.org/archive/html/qemu-devel/2025-06/msg04598.html
> v2: https://mail.gnu.org/archive/html/qemu-devel/2025-07/msg01799.html
> v3: https://mail.gnu.org/archive/html/qemu-devel/2025-07/msg02338.html
> v4: https://mail.gnu.org/archive/html/qemu-devel/2025-07/msg02488.html
> v5: https://mail.gnu.org/archive/html/qemu-devel/2025-07/msg02689.html
>
> This series adds support for all FEAT_MEC registers and cache instructions to
> the Arm64 max CPU.

This fails "make check":

 16/247 qemu:qtest+qtest-aarch64 / qtest-aarch64/test-hmp
     ERROR           40.82s   killed by signal 6 SIGABRT
 18/247 qemu:qtest+qtest-aarch64 / qtest-aarch64/qom-test
     ERROR          181.28s   killed by signal 6 SIGABRT

This is because running sbsa-ref hits an assert:

$ ./build/x86/qemu-system-aarch64 -M sbsa-ref
**
ERROR:../../target/arm/helper.c:4588:define_arm_vh_e2h_redirects_aliases:
assertion failed: (src_reg != NULL)
Bail out! ERROR:../../target/arm/helper.c:4588:define_arm_vh_e2h_redirects_aliases:
assertion failed: (src_reg != NULL)
Aborted (core dumped)

which is because your entry in the E2HAlias list in
define_arm_vh_e2h_redirects_aliases() is missing an
isar_feature_* gate. Without that, the function will
try to define the alias register even when the CPU
doesn't have FEAT_SCTLR2, and asserts because it can't
find the register it's supposed to be aliasing.

I think also that arm_emulate_firmware_reset() should
be setting the new SCR_EL3 bits when the relevant
features are present. Otherwise when we direct boot
a Linux guest at EL1 or EL2 on a config where the CPU
has EL3 it will take an exception when it tries to access
the registers.

You'll also find the series needs rebasing as I've got
RTH's "move code out to cpregs-at.c and cpregs-pmu.c"
patches in target-arm.next.

thanks
-- PMM