Le travail KVM de Linux 7.3 sépare les responsabilités accumulées dans kvm_mmu. Il clarifie la conversion des adresses virtuelles invitées, sans ajouter trois étages matériels ni annoncer un gain de vitesse mesuré pour chaque VM.
Une réorganisation des responsabilités
La demande de fusion de Paolo Bonzini du 25 août, intégrée par la fusion amont, sépare format des tables, parcours des tables invitées et construction des tables. La conversion des adresses virtuelles invitées utilise kvm->arch.gva_walk comme entrée commune. L’ancienne distinction portait sur deux structures kvm_mmu selon l’intervention d’EPT/NPT imbriqués ; parler de deux implémentations entièrement indépendantes était excessif.
Le texte présente aussi la mutualisation des contrôles de permissions comme une préparation au support XS/XU. Préparer une fonction ne signifie pas qu’elle est complète et exposée à tous les invités.
Ne pas confondre code et étages d’adressage
La documentation MMU de KVM distingue adresses virtuelles invitées, physiques invitées et physiques de l’hôte. La traduction matérielle de second niveau et la virtualisation imbriquée apportent leurs propres correspondances. Diviser une structure logicielle en trois responsabilités n’ajoute pas trois traductions obligatoires à chaque accès mémoire.
L’illustration montre donc des responsabilités, plutôt que trois recherches matérielles successives. Le format détermine l’interprétation d’une entrée ; le parcours suit les correspondances ; la construction gère les tables nécessaires à KVM. Ces tâches interagissent sans désigner trois fois la même adresse.
Le correctif temporel a un périmètre précis
La demande de fusion évite les mises à jour de l’état d’exécution Xen quand le temps recule effectivement, ce qui prévient un faux temps volé prolongé. Il s’agit du chemin compatible Xen de KVM, pas de l’affirmation que tout steal time élevé d’un invité Linux serait une erreur comptable.
Si un invité rapporte un temps volé inhabituel, identifiez noyau hôte, horloge invitée et interfaces paravirtualisées exposées. Comparez la métrique aux indices de contention et de planification sur l’hôte. Une surcharge réelle et un défaut de comptabilisation ne demandent pas le même remède. Ne supprimez pas une alerte parce qu’un changelog mentionne un pourcentage semblable.
Évaluer les chemins effectivement utilisés
Avant une mise à jour d’hôte, conservez un démarrage de secours et testez une VM jetable représentative. Vérifiez démarrage, arrêt, pression mémoire et fonctions de gestion utilisées dans votre parc. Si une VM héberge elle-même un hyperviseur, testez explicitement ce cas : le démarrage d’un invité ordinaire n’exerce pas les mêmes chemins.
Associez chaque résultat aux versions hôte et invitée et changez une couche à la fois. Cet article explique des modifications fusionnées ; il ne rapporte pas un benchmark PeopleAreGeek et ne présente pas le noyau de développement comme une mise à jour stable de production.
Sources
Demande de fusion KVM et intégration vérifiées ; structures et parcours distingués, temporisation Xen précisée et nettoyage séparé des nouvelles permissions.