The Linux team has published an intermediate Linux 6.13-rc3 to fix a “hilarious” bug in the kernel-based Virtual Machine code — Phoronix reports, where CPUID updates are taking significantly longer time to be processed on Sapphire Rapids CPUs than they should be, resulting in much older Skylake CPUs being up to 4X faster in regards to CPUID cost.

Phoronix reveals that Google engineers originally discovered this technical issue in how Sapphire Rapids processes CPUID information in nested VMs. Specifically, Google’s Sean Christopherson states, “On Intel’s Emerald Rapids, CPUID is *wildly* expensive, to the point where recomputing XSAVE offsets and sizes results in a 4x increase in latency of nested VM-Enter and VM-Exit (nested transitions can trigger xstate_required_size() multiple times per transition), relative to using cached values. The issue is easily visible by running `perf top` while triggering nested transitions: kvm_update_cpuid_runtime() shows up at a whopping 50%…”

This performance bug/regression won’t be purportedly fixed until Linux 6.14, but the issue is severe enough for the Linux devs to fix the outgoing Linux 6.13 kernel temporarily. Update 6.13-rc3 caches the CPUID data on Sapphire Rapid CPUs, speeding up this process. The Linux 6.14 implementation of the complete fix will result in all the CPUIDs nested in VM-Enter and VM-Exit being completely deleted.

For those unaware, CPUID is an instruction that lets software discover details of the processor it is running on. On Sapphire Rapids, the software reading CPU information through the CPUID instruction takes up to 4X longer than on much older Skylake CPUs. This only occurs inside nested virtualization transitions, which only happen when a VM runs inside a VM.

The Linux 6.13-rc3 comes with various other bug/regression fixes. However, the caching workaround for expensive CPUID handling appears to be one of the more critical updates to the kernel. Again, this caching technique is just a workaround, with Linux 6.14’s complete fix for the issue.