Parallels 26.1.1 incorrectly reports SVE2 capability in ARM guest on Apple M4 Pro

Problem Description

On Parallels Desktop 26.1.1 (build 57288) running on Apple M4 Pro, ARM64 Linux guests incorrectly advertise SVE2support through AT_HWCAP2, even though the hardware does not implement SVE or SVE2 instructions.

This causes applications using Vectorscan/Hyperscan or other SVE2-optimized code paths to crash with Illegal instruction (SIGILL) errors. The problem can be verified inside the guest with:

LD_SHOW_AUXV=1 /bin/true | egrep 'AT_HWCAP2|AT_HWCAP'
dmesg | grep -i sve

Result:
AT_HWCAP: efb3ffff
AT_HWCAP2: 0x1383

Expected Result (example):
AT_HWCAP: 0xefb3ffff
AT_HWCAP2: 0x81

Please fix the incorrect CPU feature reporting in Parallels' ARM virtualization layer so that SVE2 is not exposed when the host CPU does not actually support it.

 

Addendum: CPU feature flags reported inside the guest
Command & output
lscpu | grep Flags
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 flagm2 frint svei8mm svebf16

Interpretation

• The ARM64 guest advertises SVE2 (sve2) and related sub-features (svei8mm, svebf16).
• On Apple M4 Pro, SVE/SVE2 is not implemented; only NEON/ASIMD is available.
• This contradicts the auxv check and kernel logs used earlier:

LD_SHOW_AUXV=1 /bin/true | egrep 'AT_HWCAP2|AT_HWCAP'
dmesg | grep -i sve

Interpretation
AT_HWCAP: efb3ffff
AT_HWCAP2: 0x1383 # SVE2-related bits appear set
(no SVE init in dmesg)

Impact

• Libraries that dispatch on reported CPU features (e.g., Vectorscan/Hyperscan) select SVE2 code paths and abort with SIGILL (Illegal instruction) in ARM64 Linux guests under Parallels on Apple Silicon.

Requested fix

• Please correct the ARM guest CPU feature exposure so that SVE/SVE2 are not reported (neither via /proc/cpuinfo/lscpu nor AT_HWCAP2) when the host CPU does not implement them.
• Ensure consistency across ID registers → /proc/cpuinfo → auxv (AT_HWCAP/AT_HWCAP2) so runtime dispatch reliably falls back to NEON on Apple Silicon.
  

 

Root Cause Identified -- Incorrect SVE2 Exposure from Parallels + Linux Kernel Behavior
After detailed analysis and confirmation from Vectorscan maintainers and ARM kernel developers, the root cause is clear. When running ARM64 Linux guests on Parallels Desktop 26.1.1 (build 57288) on Apple M4 Pro, the virtual CPU configuration exposed by Parallels reports SVE2 capability bits via ID_AA64ZFR0_EL1, although the hardware does not implement SVE. This combination (SME present, SVE absent, SVE2 advertised) is architecturally inconsistent.
The Linux kernel up to 6.1 did not validate this and propagated the false flags to user space via AT_HWCAP2. Consequently, libraries such as Vectorscan or Hyperscan detect SVE2 support and execute unsupported instructions, causing Illegal instruction (SIGILL) crashes in rspamd and similar software.

Fix and Workaround
The Linux kernel community addressed this in [PATCH] arm64: Filter out SVE hwcaps when FEAT_SVE isn't implemented (Marc Zyngier, Jan 2025): https://lore.kernel.org/all/[email protected]/
The patch makes the kernel robust against wrong guest configurations by filtering out all SVE/SVE2 caps unless FEAT_SVE is set in ID_AA64PFR0_EL1.
However, the real root cause lies in Parallels' virtual CPU setup, which should not expose ZFR0 SVE2 fields when PFR0.SVE = 0. Until both sides are fixed, the issue can be avoided by disabling SVE in the guest kernel using arm64.nosve=1 in the GRUB command line. After reboot, AT_HWCAP2 should no longer contain SVE2 bits (0x181).

Conclusion
Root cause: Parallels exposes an inconsistent ARM feature set.
Kernel behavior: Up to 6.1, Linux accepted and forwarded false SVE2 flags.
Impact: Any SVE2-optimized library crashes on Apple M4.
Workaround: Add arm64.nosve=1.
Permanent fix: Kernel patch + Parallels adjustment of virtual CPU registers.