In VEX/priv/main_main.c (check_hwcaps) we have: Bool have_rdm = ((hwcaps & VEX_HWCAPS_ARM64_RDM) != 0); Bool have_atomics = ((hwcaps & VEX_HWCAPS_ARM64_ATOMICS) != 0); if (have_rdm != have_atomics) invalid_hwcaps(arch, hwcaps, "Mismatch detected between RDMA and atomics features.\n"); This was added as part of https://bugs.kde.org/show_bug.cgi?id=414268 commit cb52fee5ddbc2c0e936fd1efe5107a1afcf375cf "Bug 414268 - Enable AArch64 feature detection and decoding for v8.x instruct ions (where x>0)" But there are (virtual) machines out there that don't have that (RDM and ATOMICS) combination. So we refuse to run on those. VEX: Mismatch detected between RDMA and atomics features. Found: v8-rdm Cannot continue. Good-bye
Got access to a QEMU vm which has: processor : 0 BogoMIPS : 40.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid asimdrdm CPU implementer : 0x51 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xc00 CPU revision : 1 Which valgrind detects as: Arch and hwcaps: ARM64, LittleEndian, v8-rdm Removing the sanity check: diff --git a/VEX/priv/main_main.c b/VEX/priv/main_main.c index 1253cf588..482047c7a 100644 --- a/VEX/priv/main_main.c +++ b/VEX/priv/main_main.c @@ -2163,11 +2163,6 @@ static void check_hwcaps ( VexArch arch, UInt hwcaps ) if (have_fp16 != have_vfp16) invalid_hwcaps(arch, hwcaps, "Mismatch detected between scalar and vector FP16 features.\n"); - Bool have_rdm = ((hwcaps & VEX_HWCAPS_ARM64_RDM) != 0); - Bool have_atomics = ((hwcaps & VEX_HWCAPS_ARM64_ATOMICS) != 0); - if (have_rdm != have_atomics) - invalid_hwcaps(arch, hwcaps, - "Mismatch detected between RDMA and atomics features.\n"); return; } It looks like everything works fine (make regtest results look good).
BTW. It turns out qemu doesn't do atomics, but does doe rdm: https://www.qemu.org/docs/master/system/arm/emulation.html Which is why you see rdm without atomics when running under qemu. I think this is a valid configuration (basically armv8.0 + rdm extension) so we should allow it, unless there is something in VEX that isn't able to support that (but from some test runs it seems everything works fine).
(In reply to Mark Wielaard from comment #2) > BTW. It turns out qemu doesn't do atomics, but does doe rdm: > https://www.qemu.org/docs/master/system/arm/emulation.html > > Which is why you see rdm without atomics when running under qemu. I was wrong. The Large Systems Extension FEAT_LSE includes atomics and should be supported by qemu. > I think this is a valid configuration (basically armv8.0 + rdm extension) so > we should allow it, unless there is something in VEX that isn't able to > support that (but from some test runs it seems everything works fine). But I still think it is a configuration that we should support. If only since there are such configurations out there.
After a discussion with Assad Hashmi and Peter Maydell I have pushed the proposed patch as: commit 13427e2ae745f9c5a665174b245d6dcebcf159d9 Author: Mark Wielaard <mark@klomp.org> Date: Fri Feb 11 17:50:47 2022 +0100 arm64: Mismatch detected between RDMA and atomics features check_hwcaps contains code that tries to enforce Arm architecture's rules for the support of features (FEAT_) on v8.1. Specifically for v8.1 FEAT_RDM and FEAT_LSE (named FEAT_ATOMICS in Valgrind) are mandatory. But an v8.x implementation can implement any of the v8.{x+1} features, or not, as it chooses. Also under QEMU, which tends to implement features on an "as-demanded" basis, you sometimes end up with an odd combination of features, which does not strictly comply with the architecture. So ignore the "v8.x" architecture levels, and look only only at "is feature X present or not". Unless the features are really not independent. https://bugs.kde.org/show_bug.cgi?id=449494