On Thu, 10 Jul 2025 at 22:11, Gustavo Romero <[email protected]> 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

Reply via email to