On Mac computers with Apple silicon chips, ARM64 Linux guests running in Parallels Desktop® for Mac may incorrectly advertise support for the Scalable Vector Extension 2 (SVE2) through AT_HWCAP2, even though Apple silicon chips do not implement SVE or SVE2 instructions. Applications that detect processor features at runtime then select an SVE2-optimised code path and crash. This article explains the cause and describes how to resolve it.
An application running inside an ARM64 Linux virtual machine stops unexpectedly with the message Illegal instruction, or terminates with the signal SIGILL. Vectorscan and Hyperscan are known to be affected, but the problem can occur in any application that queries processor capabilities at runtime and branches into SVE2 code paths.
Linux kernels earlier than version 6.1 determine SVE support by reading the ID_AA64ZFR0_EL1.SVEver register field. According to ARM documentation, the fields in ID_AA64ZFR0_EL1 are only valid when SVE is implemented, and the correct field to test for the presence of SVE is ID_AA64PFR0_EL1.SVE.
Apple silicon chips do not implement the SVE extensions defined in Armv9.2. Because ID_AA64ZFR0_EL1.SVEver cannot be set to zero without departing from the Armv9.2 specification, an affected guest kernel reads this field without first confirming that SVE is present and reports SVE2 as available. The result is an inconsistent processor feature state inside the guest: SVE2 is advertised, while SVE itself is absent.
Determining whether your Linux Virtual Machine Is Affected
1. Open the Terminal application in the Linux guest and run the following commands:
LD_SHOW_AUXV=1 /bin/true | grep -E 'AT_HWCAP2|AT_HWCAP'dmesg | grep -i sve
2. On an affected virtual machine, the first command returns output similar to the following:
AT_HWCAP: 0xefb3ffffAT_HWCAP2: 0x1383
Bit 1 of AT_HWCAP2 corresponds to HWCAP2_SVE2. In the example above, 0x1383 has bit 1 set, so the guest is advertising SVE2. The second command returns no output, confirming that the kernel never initialised SVE. Together, these two results confirm that SVE2 is being reported incorrectly.
Solution 1: Upgrade the Linux kernel (recommended)
Upgrade the kernel in the Linux guest to version 6.1 or later. This version tests ID_AA64PFR0_EL1.SVE before reading the SVE feature fields, so SVE2 is no longer advertised on hardware that does not implement it.
Consult the documentation for your Linux distribution for the correct kernel upgrade procedure. After you restart the virtual machine, run the commands in the previous section again. Bit 1 of AT_HWCAP2 is now clear, and affected applications start normally.
Solution 2: Disable SVE at boot
If you cannot upgrade the kernel immediately, disable SVE through a kernel boot parameter. Add the following parameter to the kernel command line in your bootloader, for example GRUB:
arm64.nosve
This parameter is an alias for id_aa64pfr0.sve=0, which forces the sanitised value of the SVE field in ID_AA64PFR0_EL1 to zero. Either form is accepted.
Note: The arm64.nosve parameter was introduced in Linux kernel 6.0. It is not available in kernels earlier than that version. If the guest runs a kernel older than 6.0, upgrading the kernel as described in Solution 1 is the only available course of action.
For instructions on editing kernel boot parameters, refer to the documentation for your Linux distribution. After you restart the virtual machine, confirm that the change took effect by running the commands in the section above and checking that bit 1 of AT_HWCAP2 is no longer set.
Note: This behaviour originates in the guest kernel's feature detection logic rather than in Parallels Desktop. The same inconsistency can be observed in other virtualisation products on Apple silicon that expose the host processor identification registers to the guest.
Was this article helpful?
Tell us how we can improve it.