The KVM subsystem is about to lose one of its more notorious data structures. Paolo Bonzini, the Red Hat engineer who maintains KVM, has merged a branch named kvm-chainsaw into KVM's next tree, and Phoronix picked it up on July twenty sixth. What it does is split struct kvm_mmu, a structure that had accumulated three unrelated jobs, into three separate structures that each do one of them. There is no user visible feature here and no benchmark to quote. What there is, if it lands in the Linux 7.3 merge window expected in the second half of August, is a great deal less room for a specific class of nested virtualization bug.
The short answer
Paolo Bonzini has merged the kvm-chainsaw branch into KVM's next tree, splitting struct kvm_mmu into kvm_pagewalk for walking guest page tables, a slimmer kvm_mmu for building shadow page tables, and kvm_page_format for operating on entries that already exist. The series was first posted to the kernel and kvm lists on May eleventh, and Phoronix reported the merge on July twenty sixth. Target is the Linux 7.3 merge window, expected in the second half of August. No user visible change, but a documented source of nested virtualization confusion goes away.
Naming a branch kvm-chainsaw tells you roughly what to expect from the diff. It also tells you the maintainer had been looking at this structure for a while.
What kvm_mmu had become
KVM has to do a lot of bookkeeping about page tables, because a virtual machine has its own idea of memory layout and the host has to make that idea true without letting the guest touch anything it should not. The structure that held most of that bookkeeping was struct kvm_mmu.
Over time it took on three distinct responsibilities. It described the format of the guest's page tables, meaning the shape of the entries and which bits mean what for the mode the guest is running in. It walked those page tables, translating an address the guest handed over into something the host can act on. And it built page tables, constructing the shadow structures KVM maintains on the host side.
Those three things touch the same data, which is how they ended up in the same place. They are not the same thing, which is why they should not have.
The practical cost showed up as duplication and as confusion. Bonzini singles out the relationship between guest_mmu and nested_mmu, where the naming had drifted far enough from the behaviour that comments describing them were wrong. When you are reading nested virtualization code, an L2 guest running inside an L1 guest running on the host, a misleading comment about which structure describes what is not a cosmetic problem.
The split
kvm_pagewalk becomes the page table walker. In the merged branch there are two per vCPU, gva_walk and ngpa_walk. The older walk_mmu pointer, which had to be switched depending on whether an L1 or an L2 guest was running, is replaced by a single gva_walk that covers both cases. Removing a conditional that ran through nested code paths is a large part of the point.
kvm_mmu keeps the building role, and only that role. It constructs shadow pages, and it uses a walker to do it: always gva_walk when it is the root_mmu, always ngpa_walk when it is the guest_mmu. That is a rule you can state in one line, which was not previously the case.
kvm_page_format covers operations on entries that already exist, and it absorbs code that had been scattered: the logic around permission_mask() merges with the pre-existing rsvd_bits structures, so the question of which bits are reserved and which permissions apply is answered in one place.
The May posting of the series ran to twenty two patches with a diffstat in the low hundreds of lines each way across fifteen files, which is a useful reminder that a refactor's importance is not measured by its size. Almost all of the change is moving field accesses from one structure to another. The value is in what becomes possible afterwards, and Bonzini notes one such thing directly: supporting shadow page table entries where the executable bit differs between supervisor and user mode, expressed through memory attributes, was awkward to fit into the old structure.
The tooling note
Bonzini disclosed that he used a large language model for the mechanical parts of the refactor, and the comparison he chose is the interesting bit. He described it as a natural language Coccinelle.
Coccinelle is a tool kernel developers have used for years to apply a semantic patch, a described transformation, across an entire tree. When you need to change the same call pattern in four thousand places, you write the rule rather than the four thousand edits. Positioning an LLM in that slot is a claim about scope: it did the transformation, not the design. Bonzini is explicit that the architectural decisions remained his.
Whether that framing holds up is something the kernel community will work out on its own, and it is not a settled question there. Debian voted on a general resolution about LLM written contributions this month. What is worth noting here is simply that the disclosure was made, and made specifically enough that a reviewer knows what to look for.
What to do about it
Nothing, for now, which is the correct answer for most kernel internals news.
If you run nested virtualization in anger, meaning VMs inside VMs in production rather than as a lab curiosity, this is worth knowing about because that is where the confusion being cleaned up actually lived. Bugs in that area have historically been difficult to reproduce and difficult to read, and the code becoming clearer is how that improves over the next few releases.
If you maintain anything out of tree that touches KVM's MMU internals, the picture is different and the work is real. Field accesses move, walk_mmu goes away, and there is no compatibility shim for a structure that was never a stable interface in the first place. The branch is in next now, which is the window in which finding out is cheap.
Sources and further reading
- LWN: KVM, apply chainsaw to struct kvm_mmu
- Phoronix: KVM chainsaw expected to hit Linux 7.3 for dealing with god data structure
- The patch series cover letter on the kernel mailing list
- The KVM git tree
- Kernel documentation: the x86 KVM shadow MMU
Frequently asked questions
What was wrong with struct kvm_mmu?
It was doing three jobs at once. It described the format of the guest's page tables, it walked those page tables, and it built the page tables KVM itself uses. Those are related activities but they are not the same activity, and packing them into one structure meant that code reaching for one of the three had to carry the other two along. Bonzini's own cover letter calls it a god data structure, which is the standard name for exactly this shape of problem: a type that grew by accretion until nobody could describe its purpose in one sentence.
What are the three replacements?
kvm_pagewalk is the page table walker, and there are two per vCPU in the merged branch, named gva_walk and ngpa_walk. kvm_mmu keeps the page table building role and uses a walker to construct shadow pages. kvm_page_format handles operations on page table entries that already exist, and it absorbs the code that used to sit around permission_mask() together with the pre-existing rsvd_bits structures. Each of the three now has a name that tells you what it is for.
Does this change anything for someone running VMs today?
Not directly. There is no new feature, no configuration option and no performance claim attached to this work. It is a refactor, and a successful refactor is one that nothing notices. The indirect effect is the one that matters over time: code that is clearer is code where the next bug is easier to see, and this particular structure sat underneath nested virtualization, which is one of the harder parts of KVM to reason about. It also unblocks work that was awkward to express before, including support for shadow page table entries where the executable bits for supervisor and user mode differ.
When would this reach a kernel I can install?
The branch is in KVM's next tree, which is the staging area for the following merge window. Linux 7.3's merge window is expected in the second half of August, so if it goes in there, the stable 7.3 release follows the usual two months or so of release candidates. Distribution kernels then pick it up on their own schedules, which for an enterprise distribution can mean a year or more. Nothing about this is urgent from an operations point of view.
Is it true that an LLM was used on this patch series?
Bonzini disclosed it himself, and the framing he used is worth reading carefully. He described using the model as a natural language Coccinelle, comparing it to the semantic patching tool kernel developers already use to apply the same mechanical transformation across thousands of call sites. The architectural decisions, which is to say the actual design of the three way split, stayed with him. That is a narrow and clearly bounded use, and the disclosure is the part that makes it reviewable at all.