On Mon, 21 Sept 2026 at 15:29, Alex Bennée <[email protected]> wrote: > > Since kernel commit b130a8f70cbbf9 (KVM: arm64: Check advertised > Stage-2 page size capability) the relevant Stage 2 have been pegged at > 1 f(4KB granule not supported at stage 2) by the kernel. As a result > the behaviour of the test differs when run on real HW compared to > under emulation: > > id_aa64mmfr0_el1 : 0x00000111ff000000 > !!extra bits!! : 0x0000011100000000 > > Update the test with a new helper to explicitly test for fixed bits > and update v8_user_idregs to match real systems.
Huh, 2020; that's not a recent change at all... I don't understand what the above output is intended to tell me, though. What are "extra bits"? In the actual implementation code in helper.c all we define is exported bits and fixed bits. I think we could stand to be a bit more verbose in the test program output in saying what the test thinks the problem is. > Resolves: https://gitlab.com/qemu-project/qemu/-/work_items/4566 > Signed-off-by: Alex Bennée <[email protected]> > --- > target/arm/helper.c | 7 +++++-- > tests/tcg/aarch64/sysregs.c | 31 ++++++++++++++++++++++++++++--- > 2 files changed, 33 insertions(+), 5 deletions(-) > > diff --git a/target/arm/helper.c b/target/arm/helper.c > index c3f607e6d6b..7e65f072a4a 100644 > --- a/target/arm/helper.c > +++ b/target/arm/helper.c > @@ -6902,8 +6902,11 @@ void register_cp_regs_for_features(ARMCPU *cpu) > R_ID_AA64FPFR0_F8CVT_MASK }, > { .name = "ID_AA64MMFR0_EL1", > .exported_bits = R_ID_AA64MMFR0_ECV_MASK, > - .fixed_bits = (0xfu << R_ID_AA64MMFR0_TGRAN64_SHIFT) | > - (0xfu << R_ID_AA64MMFR0_TGRAN4_SHIFT) }, > + .fixed_bits = (0xfULL << R_ID_AA64MMFR0_TGRAN64_SHIFT) | > + (0xfULL << R_ID_AA64MMFR0_TGRAN4_SHIFT) | > + (0x1ULL << R_ID_AA64MMFR0_TGRAN4_2_SHIFT) | > + (0x1ULL << R_ID_AA64MMFR0_TGRAN64_2_SHIFT) | > + (0x1ULL << R_ID_AA64MMFR0_TGRAN16_2_SHIFT) }, This change looks OK: the rule for the ID registers at EL0 (per https://docs.kernel.org/arch/arm64/cpu-feature-registers.html ) is that fields not visible to userspace should have the value indicating "feature is missing". That is: * for TGran16: 0 * for TGran64 and TGran4: 0b1111 * for TGran16_2, TGran64_2, TGran4_2: 0b0001 and that's what we now define for the fixed_bits value. I think we could reasonably add a brief comment, though: /* * Linux does not expose the TGRAN* fields to userspace and so they * must read as the "this is not implemented" value for those fields * (which is 0, 0b0001 or 0b1111 depending on the field) */ thanks -- PMM
