The Linux kernel 6.13-rc3 includes a change that addresses a performance regression in the KVM hypervisor related to slow processing of CPUID calls on new CPUs. For instance, on Intel Emerald Rapids CPUs, CPUID operations are performed 3-4 times slower than on Intel Skylake CPUs. This issue led to reduced performance in the KVM hypervisor, which utilizes CPUID during the save and restore state process of the CPU with every control transfer to a virtual machine when using nested virtualization. To resolve this issue, a simplified patch has been accepted into the 6.13 kernel branch, allowing for up to a 40% reduction in operation time even on Skylake family CPUs, thanks to CPUID caching. A full version of the patch that further improves performance will be introduced in kernel 6.14.
Additionally, there has been a discussion on the Linux kernel developers' mailing list about the cessation of support for 32-bit systems in the hypervisor. KVMInitially, a patch was proposed for the kernel that removes KVM virtualization support on the x86-32 platform. In response, concerns were raised that x86-32 support might be useful for testing host mode functionality on 32-bit systems in general, as the kernel still retains three other 32-bit architectures supported by KVM. A counter-patch was then presented, this time removing KVM support for all 32-bit systems.
The desire to eliminate support for 32-bit systems is explained by the fact that even on popular 32-bit ARM processors, such as ARM Cortex A7, virtualization has not developed and usage has been infrequent. of virtual machines On 32-bit ARM systems, the usage was so rare that support for these systems in KVM was removed in 2020 without any objections. It is noted that for the remaining 32-bit systems, the changes will only affect exotic platforms that have long been obsolete or never gained popularity. Among the processors affected by the patch are: Intel Core Duo/Silverthorne, PowerPC e300/e500/e600, and MIPS P5600. The patch has been published as RFC, meaning it is open for discussion.
Source: opennet.ru
