Paolo Bonzini's KVM pull request for Linux 7.3 landed in Linus Torvalds' tree on August 25, 2026, and Phoronix wrote it up on August 30 as the merge window closed. There is almost nothing here that shows up in a release note aimed at users. What is here is the change the KVM x86 maintainers have been calling the chainsaw: kvm_mmu, one of the structures everything in the shadow paging path touches, gets split into three, and every guest virtual address now goes through the same walker. Underneath the refactor sit two fixes that virtualisation admins will actually notice.
The short answer
The KVM changes for Linux 7.3 were merged on August 25, 2026 and are almost entirely cleanup and bug fixes. The headline item is the chainsaw: kvm_mmu is split into three parts describing page table format, walking guest page tables and building page tables, and every guest virtual address conversion now goes through a single walker instead of two structures chosen by nesting depth. Page fault vmexits reuse the permission checking machinery already used for guest page faults. Two fixes stand out for operators: KVM now skips Xen runstate updates when time goes backwards, so guests stop reporting 100 percent steal time for very long periods, and the VMX preemption timer is capped to work around an erratum on all existing Intel processors supporting CPUID 0x15.
A pull request that adds nothing users can see is easy to skip. This one is worth reading anyway, because of what it moves rather than what it adds.
One walker, not two
The kvm_mmu structure describes how KVM handles a guest's memory management unit, and over the years it came to mean three things at once. It described the format of page tables. It described how to walk the guest's page tables. It described how to build the page tables KVM installs in hardware. Linux 7.3 splits those apart.
The consequence that matters follows immediately. Before this, converting a guest virtual address used one of two kvm_mmu structures, chosen by whether the walk included nested EPT on Intel or NPT on AMD. Now there is one entry point, kvm->arch.gva_walk, used in both cases. Two implementations of the same logic that must agree are a standing invitation to diverge, and the place they diverge is nested virtualisation, which is precisely the configuration hardest to reason about and most likely to be running someone else's workload.
The same series makes page fault vmexits reuse the permission checking machinery already used for guest page faults, so permission logic exists in one place instead of two. The maintainers describe all of this as both a cleanup and a first step toward supporting XS and XU memory permissions, which is the honest framing: the refactor is not the feature, it is what makes the feature affordable later.
Alongside it, the x86 code got what the pull calls spring cleaning. A regs.c file appears, msrs.c and msrs.h appear, and code that had accumulated in x86.c and asm/kvm_host.h moves out to where it belongs. More KVM internal declarations leave kvm_host.h entirely, and nested virtualisation operations move to static calls.
The two fixes an operator will feel
The first is the Xen timing fix. KVM now skips Xen runstate time updates when time has effectively gone backwards. The symptom it removes is described plainly in the pull: a guest reporting 100 percent steal time for a very, very long time. If you alert on steal time, or if a scheduler in your stack reacts to it, that is a metric lying to you and to everything downstream of it. The same area drops a defunct masterclock update from Xen shared info initialisation, which could produce an incorrect kvmclock by forcing an unnecessary switch in and out of masterclock mode, and stops KVM updating the Xen paravirtualised timing CPUID leaf at runtime, because it was writing the wrong sub leaf.
The second is Intel specific. KVM now caps the maximum value it writes into the VMX preemption timer, working around an erratum that affects all existing Intel processors supporting CPUID leaf 0x15. Nearby sit fixes for servicing local TLB flushes after a failed nested VM enter, which closed a case where KVM could miss a flush on a later successful entry reusing the same L2 VPID, and further VPID virtualisation fixes where hardware TLBs were not being flushed.
On AMD hosts, KVM now allocates full pages for SEV and SEV-ES encrypt and decrypt operations, fixing data corruption caused by the AMD platform security processor driver assigning to be written pages to firmware. It also forcefully invalidates SNP VMSA pages when the backing guest_memfd page is zapped, and removes a dying virtual machine from the guest address log notifier list before the machine is actually destroyed.
Beyond x86
RISC-V is where the new function is. Guests gain Svadu, Zicfiss and Zicfilp firmware feature support, dirty logging gains eager page splitting when it is enabled, HFENCE request handling is optimised for SMP guests, dirty log clearing skips zero bits in the mask, HFENCE range loops are guarded against overflow, and CPU power management notifiers arrive for non retentive idle states. There is also a fix for kernel mode vector context save and restore for guests.
Arm64 adds slot based PMU events, paired with new user space API that forces the caller to select a specific PMU implementation rather than guessing. pKVM gains lazy save and restore of vCPU state, with a set of fixes around how vCPU state moves between the untrusted host and the hypervisor. LoongArch advertises capabilities it already supported and fixes timer and memory mapped input output bugs. s390 is fixes for vfio-ap, the gmap rework and vsie, plus preparation for sharing code with arm64.
Why a cleanup release is a good sign
Virtualisation code is the part of the kernel where a subtle bug is most expensive, because the blast radius is every guest on the host. A merge window that spends its budget splitting an overloaded structure and collapsing two walkers into one is a maintenance investment, not a stall.
It also fits what Linux 7.3 has looked like elsewhere: RWF_DONTCACHE reaching block devices, MGLRU learning not to evict hot executables, a lot of careful work on paths that were already there. If you run hypervisors, read the Xen and Intel timer notes before you plan the upgrade, and treat the rest as the reason the next few releases will be easier to trust.
Sources and further reading
- Merge tag for-linus of git://git.kernel.org/pub/scm/virt/kvm/kvm, torvalds/linux, August 25, 2026
- KVM pull request for Linux 7.3, Paolo Bonzini, lore.kernel.org, August 25, 2026
- The "KVM Chainsaw" Clean-Up Merged For Linux 7.3 Along With Other Fixes, Phoronix, August 30, 2026
Frequently asked questions
What is the KVM chainsaw actually splitting?
kvm_mmu, the structure that describes how KVM handles a guest's memory management unit. It had accumulated three different jobs: describing the format of page tables, walking the guest's page tables, and building the page tables KVM installs in hardware. The pull splits those into three separate parts. On its own that changes no behaviour, which is exactly why it is safe to do in a merge window. It matters because everything in shadow paging and nested virtualisation reads that structure, so a structure that means three things at once is where subtle bugs go to hide.
Why does one walker instead of two matter?
Because the previous code picked between two different kvm_mmu structures depending on whether the address walk involved nested EPT or NPT. Two code paths that are supposed to produce the same answer are two chances to diverge, and nested virtualisation is where divergence hurts most. Linux 7.3 makes kvm->arch.gva_walk the single entry point for converting a guest virtual address, whatever the nesting situation. The same series also makes page fault vmexits reuse the permission checking machinery already used for guest page faults, so permission logic stops being written twice.
Which fix will I notice on a running fleet?
The Xen one. KVM now skips Xen runstate time updates when time has effectively gone backwards. Without that, a guest could report 100 percent steal time for a very long stretch, which is a metric plenty of teams alert on and plenty of schedulers react to. If you run Xen paravirtualised timing under KVM and have ever chased a steal time figure that made no sense against actual host load, this is the change to read.
What is the VMX preemption timer change on Intel hosts?
KVM now caps the maximum value written into the VMX preemption timer to work around an erratum that affects every existing Intel processor supporting CPUID leaf 0x15. It is a workaround rather than a feature, and it is the kind of thing you inherit silently by upgrading the kernel. There are also fixes for servicing local TLB flushes after a failed nested VM enter, which closed a window where KVM could miss a flush on a later successful entry using the same L2 VPID, and further VPID virtualisation fixes.
What changed outside x86?
RISC-V got the most new function: Svadu, Zicfiss and Zicfilp FWFT support for guests, eager page splitting when dirty logging is enabled, optimised HFENCE request handling for SMP guests, faster dirty log clearing that skips zero bits, and CPU power management notifiers for non retentive idle states. Arm64 added slot based PMU events with new user space API that forces you to name a specific PMU implementation, plus lazy save and restore of vCPU state for pKVM. LoongArch and s390 are mostly fixes and hardening.