La demande de fusion KVM de Paolo Bonzini pour Linux 7.3 est arrivée dans l'arbre de Linus Torvalds le 25 août 2026, et Phoronix l'a détaillée le 30 août à la clôture de la fenêtre de fusion. Il n'y a presque rien ici qui figurerait dans des notes de version destinées aux utilisateurs. Ce qui s'y trouve, c'est le chantier que les mainteneurs x86 de KVM appellent la tronçonneuse : kvm_mmu, l'une des structures que tout le chemin de pagination fantôme manipule, se scinde en trois, et toute adresse virtuelle invitée passe désormais par le même parcours. Sous le remaniement se cachent deux correctifs que les administrateurs de virtualisation vont remarquer.
The short answer
Les changements KVM de Linux 7.3 ont été fusionnés le 25 août 2026 et relèvent presque entièrement du nettoyage et de la correction de bogues. La pièce maîtresse est la tronçonneuse : kvm_mmu est scindé en trois parties décrivant le format des tables de pages, leur parcours et leur construction, et toute conversion d'adresse virtuelle invitée passe désormais par un parcours unique au lieu de deux structures choisies selon l'imbrication. Deux correctifs comptent pour les exploitants : KVM ignore les mises à jour de runstate Xen quand le temps recule, ce qui met fin aux invités annonçant 100 pour cent de vol de temps pendant de très longues périodes, et le minuteur de préemption VMX est plafonné pour contourner une erratum présente sur tous les processeurs Intel supportant CPUID 0x15.
Une demande de fusion qui n'apporte rien de visible se saute facilement. Celle ci mérite la lecture, pour ce qu'elle déplace plutôt que pour ce qu'elle ajoute.
Un seul parcours, plus deux
La structure kvm_mmu décrit la façon dont KVM traite l'unité de gestion mémoire d'un invité, et elle en était venue à signifier trois choses à la fois. Elle décrivait le format des tables de pages. Elle décrivait le parcours des tables de pages de l'invité. Elle décrivait la construction des tables que KVM installe dans le matériel. Linux 7.3 sépare ces rôles.
La conséquence importante suit immédiatement. Auparavant, convertir une adresse virtuelle invitée passait par l'une de deux structures kvm_mmu, choisie selon que le parcours incluait ou non de l'EPT imbriqué chez Intel ou du NPT chez AMD. Il y a désormais un point d'entrée unique, kvm->arch.gva_walk, utilisé dans les deux cas. Deux implémentations d'une même logique tenues de s'accorder sont une invitation permanente à diverger, et l'endroit où elles divergent est la virtualisation imbriquée, soit exactement la configuration la plus difficile à raisonner et la plus susceptible d'héberger la charge de quelqu'un d'autre.
La même série fait réutiliser aux sorties de machine virtuelle sur défaut de page la vérification de permissions déjà employée pour les défauts de page invités, si bien que cette logique n'existe plus qu'à un seul endroit. Les mainteneurs présentent l'ensemble à la fois comme un nettoyage et comme un premier pas vers le support des permissions mémoire XS et XU, ce qui est la formulation honnête : le remaniement n'est pas la fonction, il est ce qui rendra la fonction abordable plus tard.
À côté, le code x86 a reçu ce que la demande appelle un grand ménage. Un fichier regs.c apparaît, msrs.c et msrs.h apparaissent, et le code accumulé dans x86.c et asm/kvm_host.h part vers sa place. D'autres déclarations internes quittent kvm_host.h, et les opérations de virtualisation imbriquée passent à des appels statiques.
Les deux correctifs qu'un exploitant sentira
Le premier concerne la temporisation Xen. KVM ignore désormais les mises à jour de runstate Xen quand le temps est effectivement revenu en arrière. Le symptôme supprimé est décrit sans détour dans la demande de fusion : un invité annonçant 100 pour cent de vol de temps pendant une très, très longue durée. Si vous déclenchez des alertes sur le vol de temps, ou si un ordonnanceur de votre pile y réagit, c'est une métrique qui vous ment, et qui ment à tout ce qui en dépend. Le même domaine supprime une mise à jour d'horloge maîtresse devenue inutile à l'initialisation des informations partagées Xen, susceptible de produire une kvmclock incorrecte en forçant un basculement superflu, et cesse la mise à jour à chaud de la feuille CPUID de temporisation paravirtualisée Xen, car KVM écrivait la mauvaise sous feuille.
Le second est propre à Intel. KVM plafonne la valeur maximale écrite dans le minuteur de préemption VMX, pour contourner une erratum touchant tous les processeurs Intel existants qui supportent la feuille CPUID 0x15. À côté figurent des correctifs sur le traitement des vidages de TLB locaux après une entrée imbriquée échouée, qui refermait un cas où KVM pouvait manquer un vidage lors d'une entrée réussie ultérieure réutilisant le même VPID L2, et d'autres correctifs où les TLB matériels n'étaient pas vidés.
Sur les hôtes AMD, KVM alloue désormais des pages entières pour les opérations de chiffrement et de déchiffrement SEV et SEV-ES, ce qui corrige une corruption de données provoquée par le pilote du processeur de sécurité AMD assignant au micrologiciel des pages destinées à être écrites. Il invalide aussi de force les pages VMSA SNP lorsque la page guest_memfd sous jacente est annulée, et retire une machine virtuelle mourante de la liste des notificateurs de journal d'accès invité avant sa destruction effective.
Au delà du x86
RISC-V concentre les nouveautés. Les invités gagnent le support Svadu, Zicfiss et Zicfilp par FWFT, la journalisation des pages sales gagne un découpage anticipé des pages à son activation, le traitement des requêtes HFENCE est optimisé pour les invités multiprocesseurs, l'effacement du journal saute les bits nuls, les boucles de plage HFENCE sont protégées contre le dépassement, et des notificateurs de gestion d'énergie arrivent pour les états de repos non rémanents. Un correctif porte aussi sur la sauvegarde et la restauration du contexte vectoriel en mode noyau pour les invités.
Arm64 ajoute des événements PMU par emplacement, accompagnés d'une interface utilisateur qui contraint l'appelant à désigner une implémentation PMU précise plutôt qu'à deviner. pKVM reçoit une sauvegarde et une restauration paresseuses de l'état vCPU, avec une série de correctifs sur la circulation de cet état entre l'hôte non fiable et l'hyperviseur. LoongArch annonce des capacités déjà supportées et corrige des bogues de minuterie et d'entrées sorties mappées en mémoire. s390 apporte des correctifs pour vfio-ap, la refonte gmap et vsie, plus une préparation au partage de code avec arm64.
Pourquoi une version de nettoyage est bon signe
Le code de virtualisation est la partie du noyau où un bogue subtil coûte le plus cher, car le rayon d'action est l'ensemble des invités de l'hôte. Une fenêtre de fusion qui consacre son budget à scinder une structure surchargée et à réunir deux parcours en un seul est un investissement de maintenance, pas un temps mort.
Cela correspond aussi à ce que Linux 7.3 a produit ailleurs : RWF_DONTCACHE atteignant les périphériques bloc, MGLRU apprenant à ne plus évincer les exécutables chauds, beaucoup de travail soigneux sur des chemins déjà existants. Si vous exploitez des hyperviseurs, lisez les notes Xen et Intel avant de planifier la montée de version, et considérez le reste comme la raison pour laquelle les prochaines versions seront plus faciles à croire.
Sources et pour aller plus loin
- Merge tag for-linus de git://git.kernel.org/pub/scm/virt/kvm/kvm, torvalds/linux, 25 août 2026
- Demande de fusion KVM pour Linux 7.3, Paolo Bonzini, lore.kernel.org, 25 août 2026
- The "KVM Chainsaw" Clean-Up Merged For Linux 7.3 Along With Other Fixes, Phoronix, 30 août 2026
Questions fréquentes
Que scinde exactement la tronçonneuse KVM ?
kvm_mmu, la structure qui décrit la façon dont KVM traite l'unité de gestion mémoire d'une machine invitée. Elle avait accumulé trois rôles : décrire le format des tables de pages, décrire le parcours des tables de pages de l'invité, et décrire la construction des tables que KVM installe dans le matériel. La fusion sépare ces trois rôles. En soi, cela ne change aucun comportement, et c'est précisément ce qui rend l'opération sûre en fenêtre de fusion. L'intérêt est que tout le code de pagination fantôme et de virtualisation imbriquée lit cette structure, or une structure qui signifie trois choses à la fois est l'endroit où les bogues subtils se cachent.
Pourquoi un seul parcours plutôt que deux change quelque chose ?
Parce que le code précédent choisissait entre deux structures kvm_mmu selon que le parcours d'adresse impliquait ou non de l'EPT imbriqué côté Intel ou du NPT côté AMD. Deux chemins censés produire la même réponse offrent deux occasions de diverger, et la virtualisation imbriquée est l'endroit où une divergence coûte le plus cher. Linux 7.3 fait de kvm->arch.gva_walk le point d'entrée unique pour convertir une adresse virtuelle invitée, quelle que soit la profondeur d'imbrication. La même série fait réutiliser aux sorties de machine virtuelle sur défaut de page la vérification de permissions déjà employée pour les défauts de page invités.
Quel correctif se verra sur un parc en production ?
Celui de Xen. KVM ignore désormais les mises à jour de runstate Xen quand le temps est effectivement revenu en arrière. Sans cela, une machine invitée pouvait annoncer 100 pour cent de vol de temps pendant une très longue durée, une métrique que beaucoup d'équipes surveillent et à laquelle certains ordonnanceurs réagissent. Si vous exploitez la temporisation paravirtualisée Xen sous KVM et que vous avez déjà poursuivi un chiffre de vol de temps incohérent avec la charge réelle de l'hôte, c'est le changement à lire.
Que fait le correctif du minuteur de préemption VMX sur les hôtes Intel ?
KVM plafonne désormais la valeur maximale écrite dans le minuteur de préemption VMX pour contourner une erratum qui touche tous les processeurs Intel existants supportant la feuille CPUID 0x15. C'est un contournement et non une fonction, et c'est typiquement ce que l'on hérite silencieusement en montant de noyau. S'y ajoutent des correctifs sur le traitement des vidages de TLB locaux après une entrée imbriquée échouée, qui fermait une fenêtre où KVM pouvait manquer un vidage lors d'une entrée réussie ultérieure réutilisant le même VPID de niveau L2, ainsi que d'autres correctifs de virtualisation des VPID.
Qu'est ce qui change hors x86 ?
RISC-V reçoit le plus de nouveautés : support Svadu, Zicfiss et Zicfilp par FWFT pour les invités, découpage anticipé des pages à l'activation de la journalisation des pages sales, traitement optimisé des requêtes HFENCE pour les invités multiprocesseurs, effacement plus rapide du journal en sautant les bits nuls, et notificateurs de gestion d'énergie pour les états de repos non rémanents. Arm64 ajoute des événements PMU par emplacement, avec une interface utilisateur qui oblige à désigner une implémentation PMU précise, plus une sauvegarde et une restauration paresseuses de l'état vCPU pour pKVM. LoongArch et s390 se limitent à des correctifs et à du durcissement.