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.

 

I can reproduce the same class of issue on a newer Parallels Desktop version.

Environment:

Code:

Host hardware: Apple M4 Mac
Host OS: macOS 15.7.7
Host build: 24G720
Parallels Desktop: 26.4.0 (57513)
Guest OS: Ubuntu 22.04.5 LTS ARM64
Guest kernel: Linux 5.15.0-185-generic aarch64
glibc: 2.35

Inside the guest, the base sve feature is absent, but SVE2-related features are still exposed:

Features: 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 bf16 afp

Code:

AT_HWCAP:  efb3ffff
AT_HWCAP2: 0x105383

Important part:

Code:

sve:     absent
sve2:    present
svei8mm: present
svebf16: present

This causes runtime-dispatching libraries to select unsupported code paths and crash with SIGILL.

A minimal reproducer using Python cryptography:

Code:

python3 -m venv ~/crypto-latest-wheel
~/crypto-latest-wheel/bin/python -m pip install --upgrade pip setuptools
~/crypto-latest-wheel/bin/python -m pip install --only-binary=:all: cryptography

PYTHONFAULTHANDLER=1 \
~/crypto-latest-wheel/bin/python -X faulthandler \
-c 'from cryptography.hazmat.primitives import hashes; print(hashes.SHA256().name)'

Installed wheel:

cryptography-49.0.0-cp39-abi3-manylinux_2_34_aarch64.whl

Result:

Code:

Fatal Python error: Illegal instruction
...
File ".../cryptography/hazmat/primitives/hashes.py", line 9 in <module>
Illegal instruction (core dumped)

The same command succeeds when OpenSSL ARM CPU capability dispatch is disabled:

Code:

OPENSSL_armcap=0 \
PYTHONFAULTHANDLER=1 \
~/crypto-latest-wheel/bin/python -X faulthandler \
-c 'from cryptography.hazmat.primitives import hashes; print(hashes.SHA256().name)'

Output:

sha256

I also tested the suggested kernel boot parameter arm64.nosve=1.

After reboot, the parameter is active:

Code:

/proc/cmdline:
BOOT_IMAGE=/vmlinuz-5.15.0-185-generic root=/dev/mapper/... ro arm64.nosve=1

However, the guest still exposes the same SVE2-related userspace flags:

Code:

Features: ... dcpodp sve2 flagm2 frint svei8mm svebf16 bf16 afp
AT_HWCAP:  efb3ffff
AT_HWCAP2: 0x105383

So in this Ubuntu 22.04.5 / Linux 5.15 ARM64 guest under Parallels Desktop 26.4.0 on Apple M4, arm64.nosve=1 does not remove the inconsistent SVE2-related HWCAP2 bits.

This still looks like inconsistent ARM64 CPU feature exposure from the virtual CPU configuration: base sve is absent, but SVE2-related features are advertised to userspace.