The Linux team released an intermediate version of Linux 6.13-rc3 to fix a “funny” bug in the core-based virtual machine code – Phoronix reportswhere the processing time for CPUID updates is significantly longer sapphire rapids The CPU is faster than it should be, causing older Skylake CPUs to be 4x faster at CPUID cost.
Phoronix revealed Google Engineers originally discovered this technical issue in how Sapphire Rapids handles CPUID information in nested virtual machines. Specifically, Google’s Sean Christopherson said, “On Intel’s Emerald Rapids, CPUID is so expensive that recalculating XSAVE offsets and sizes results in a 4x increase in latency for nested VM-Enter and VM-Exit (nested conversions trigger xstate_required_size multiple times per conversion ()) ), the problem is easily seen by executing “perf top” when nested conversion is triggered: kvm_update_cpuid_runtime() shows up to 50%…”
It is said that this performance bug/regression will not be fixed until Linux 6.14, but the problem is serious enough for Linux developers to temporarily fix the upcoming Linux 6.13 kernel. Update 6.13-rc3 caches CPUID data on Sapphire Rapid CPUs to speed up this process. A complete fix implemented in Linux 6.14 will cause all CPUIDs nested in VM-Enter and VM-Exit to be completely removed.
For those who don’t know, a CPUID is a command that allows software to discover the details of the processor it’s running on. On Sapphire Rapids, the time required for software to read CPU information through the CPUID instruction is 4 times longer than on the old Skylake CPU. This only happens inside a nested virtualization transformation, which only happens when a virtual machine is running inside a virtual machine.
Linux 6.13-rc3 comes with various other bug/regression fixes. However, the cache workaround for expensive CPUID handling appears to be one of the more important updates to the core. Again, this caching technique is just a workaround and the issue is fully fixed in Linux 6.14.