Linux 7.3’s KVM work separates responsibilities that had accumulated in kvm_mmu. The result is a clearer route for translating guest virtual addresses, not three new hardware translation stages or a measured speed boost for every VM.
A refactor of responsibilities
Paolo Bonzini’s 25 August pull request, integrated by the upstream merge, separates page-table format, guest-table walking and page-table building. Guest virtual address conversion uses kvm->arch.gva_walk as its common entry. The old distinction involved two kvm_mmu structures selected according to nested EPT/NPT involvement; describing it as two entirely independent walker implementations was too strong.
The pull also describes shared permission checks as groundwork toward XS/XU support. Groundwork does not establish that a new permission feature is complete and exposed to every guest.
Do not confuse code structure with address stages
The KVM MMU documentation distinguishes guest virtual, guest physical and host physical addresses. Hardware-assisted second-level translation and nested virtualization introduce their own mappings. Splitting one software structure into three responsibilities does not add three mandatory translations to each memory access.
The illustration therefore shows responsibilities, rather than drawing three sequential hardware lookups. A format description answers how an entry is interpreted; a walker follows mappings; a builder manages the tables KVM needs. These tasks interact without being three interchangeable names for the same address.
The timing fix has a specific scope
The pull skips Xen runstate updates when time effectively moves backward, preventing a particular prolonged false steal-time report. That is KVM’s Xen-compatible timing path, not a claim that every Linux guest’s high steal time is a software accounting bug.
If a guest reports unexpected steal time, first identify the host kernel, guest clock and exposed paravirtual interfaces. Correlate the guest metric with host contention and scheduling evidence. A real overloaded host and incorrect time accounting require different remedies. Do not suppress an alert just because a kernel changelog mentions a similar percentage.
Evaluate the paths you actually use
For a host update, preserve a recovery boot path and test a representative disposable guest. Check boot, shutdown, memory pressure and the management features your estate uses. If you run a hypervisor inside a VM, test that nested configuration explicitly: a normal guest boot does not exercise the same paths.
Record host and guest versions with each result, and change one layer at a time. This article explains merged changes; it does not report a PeopleAreGeek benchmark or establish that the development kernel is a stable production upgrade.
Sources
Verified the KVM pull and merge; corrected structure versus walker wording, scoped Xen runstate timing and separated cleanup from new permission support.