ID_AA64PFR1_EL1 value under UTM is 0x00 in HVF mode.

[pmsjt]

The ID_AA64PFR1_EL1 register contains varied information about processor features. In the Apple M1, the real value of ID_AA64PFR1_EL1 is 0x20. This equates to the ID_AA64PFR1_EL1.SSBS = 2, which tells software that the CPU is capable of efficiently managing Side Channel Attack protection associated with SSB.

When the CPUs real ID_AA64PFR1_EL1.SSBS value is 2 but the hypervisor virtualizes it as 0, the underlying operating system will assume the CPU is not capable of managing SSBS. This results in a state where performance is affected (the CPU defaults to always running in safe-mode, with SSB disabled, even when context could permit it to take advantage of it in a safe manner).

I am observing that when running a VM under UTM, ID_AA64PFR1_EL1 reads as all zero.

In contrast, under Parallels, ID_AA64PFR1_EL1 = 0x20, which is the correct (pass-through) value. So this does not seem like something HVF alone is causing.

Note that this is not particular to QEMU either. I also experimented running a VM under QEMU + KVM on Linux (Ubuntu 22.04) using an Ampere Altra host. Just like on the M1, the Ampera Altra has ID_AA64PFR1_EL1 = 0x20. In this setup VMs do read ID_AA64PFR1_EL1 as 0x20, so QEMU with KVM is passing through the host value.

[osy]

@agraf Any thoughts on this?