Xen 4.22 est sorti le 30 juillet 2026, environ huit mois après la 4.21, et le fil conducteur de cette version est d'empêcher un seul invité de gâcher la machine pour tous les autres. Xenstore gagne des quotas par domaine et une limite de profondeur de watch, si bien qu'un domaine qui déraille ne peut plus consommer sans limite une ressource partagée. Sur x86, Xen prend désormais en charge le Bus Lock Threshold introduit par AMD avec Zen 5, qui permet à l'hyperviseur de plafonner les opérations atomiques lentes qu'un invité impose au socket entier. Arm gagne la suspension d'invité en RAM via PSCI, RISC-V l'extension de timer SSTC, et une série d'interfaces obsolètes disparaît enfin.
The short answer
Xen 4.22 est sortie le 30 juillet 2026, environ huit mois après la 4.21. Xenstore gagne des quotas par domaine et une limite de profondeur de watch, qui plafonnent ce qu'un seul invité peut consommer d'une ressource partagée par tous les autres. Sur x86, Xen prend désormais en charge le Bus Lock Threshold des AMD Zen 5, l'hyperviseur peut donc limiter les opérations atomiques lentes qu'un invité impose au socket entier. Arm gagne la suspension et la reprise d'invité en RAM via PSCI, poursuit le support du MPU Armv8-R et passe à FF-A 1.2. RISC-V reçoit l'extension de timer SSTC et des aides de construction de domaines par device tree. Des interfaces obsolètes de longue date ont été supprimées.
Les versions d'hyperviseur ont rarement une fonctionnalité vedette, et celle-ci ne fait pas exception. Ce que Xen 4.22 apporte, c'est un ensemble de changements qui vont tous dans la même direction : garantir qu'un domaine ne puisse pas dégrader la machine pour les autres. La phrase est moins spectaculaire qu'un nouveau portage d'architecture, et c'est précisément ce qui compte quand on exploite des hôtes en production.
Les quotas Xenstore, à lire en premier
Xenstore est la base clé-valeur partagée que les domaines Xen utilisent pour découvrir leurs propres périphériques, négocier avec le toolstack et surveiller l'état des autres. Elle est petite, bavarde, et partagée par tout ce qui tourne sur l'hôte. Cette combinaison a toujours signifié qu'un domaine au comportement étrange, que ce soit à cause d'un bug d'agent invité ou d'un pilote qui réessaie indéfiniment, peut occuper de l'espace et des emplacements de watch dont les autres domaines ont besoin.
Xen 4.22 ajoute des quotas par domaine et une profondeur de watch pour borner tout cela. Chaque domaine reçoit un plafond, et un domaine qui atteint son plafond est le seul à en subir les conséquences.
Si votre hôte ne fait tourner qu'une charge de confiance, c'est invisible. S'il héberge des domaines pour d'autres personnes, c'est la raison de planifier la mise à jour. L'équité entre locataires appartient exactement à cette catégorie de problèmes où le correctif est ennuyeux et où son absence se manifeste à trois heures du matin.
Les verrous de bus, ou comment un invité ralentit tout un socket
L'ajout côté x86 est la prise en charge du Bus Lock Threshold livré par AMD avec Zen 5.
Le problème sous-jacent est ancien et très précis. Une lecture-modification-écriture atomique verrouille normalement une ligne de cache, ce qui est rapide et reste local au cœur. Quand l'opérande franchit une frontière de ligne de cache, le processeur ne peut pas utiliser ce mécanisme et verrouille le bus mémoire à la place. Tous les cœurs du socket calent pendant ce temps. Un seul invité qui exécute des atomiques mal alignées dans une boucle serrée rend donc tous ses voisins plus lents, et du point de vue de l'hyperviseur il ne fait rien d'inhabituel : il exécute des instructions ordinaires.
Le Bus Lock Threshold donne un compteur à l'hyperviseur. Un invité dispose d'un budget de verrouillages de bus, et quand ce budget est épuisé la main revient à l'hyperviseur, qui décide alors du sort du domaine responsable. Les puces Intel disposent d'une détection comparable depuis quelques générations, il s'agit donc pour Xen de rattraper le matériel AMD plutôt que d'inaugurer un concept.
Arm, RISC-V et la traction automobile
Sur Arm, les invités peuvent désormais être suspendus et repris en RAM via des appels PSCI standard, c'est-à-dire la manière habituelle dont un système d'exploitation demande au firmware d'endormir la machine. Passer par l'interface standard compte, car les noyaux invités n'ont plus besoin de code spécifique à Xen pour participer à la gestion d'énergie de l'hôte. Le support du MPU Armv8-R continue de progresser, visant les déploiements de sûreté critique où il n'y a pas de MMU sur laquelle s'appuyer, et l'implémentation du Firmware Framework for Arm passe à la spécification v1.2.
RISC-V récupère la prise en charge interne de l'extension de timer SSTC, qui donne au superviseur le contrôle direct de son propre registre de comparaison de timer au lieu de passer par la couche inférieure à chaque programmation. S'y ajoute CONFIG_DOMAIN_BUILD_HELPERS, qui simplifie la construction de domaines invités à partir de device trees. RISC-V dans Xen reste un chantier d'activation plutôt qu'une histoire achevée, et la direction est la virtualisation complète des invités à mesure que les extensions d'ISA et le support noyau se stabilisent.
Les noms associés à cette version expliquent les priorités. Ford Motor Company, Honda R&D, Renesas Electronics, EPAM et Vates sont crédités, et l'annonce met en avant les tests de sûreté fonctionnelle et l'outillage software in the loop pour l'automobile. Cody Zuschlag, community manager du projet Xen, présente la 4.22 comme le reflet de la dynamique constante de la communauté et d'un investissement qui se poursuit.
Le centre de gravité a changé par rapport au Xen d'il y a dix ans. L'hyperviseur qui comptait surtout parce qu'un grand cloud public tournait dessus est aujourd'hui financé en bonne partie par des acteurs qui veulent un hyperviseur petit et auditable à l'intérieur d'un véhicule.
Ce que nous en ferions
Lisez d'abord la liste des suppressions. Xen 4.22 retire des interfaces obsolètes de longue date, et d'expérience ce sont les suppressions qui font mal, pas les fonctionnalités. Tout ce qui, dans votre toolstack, votre supervision ou votre configuration d'invités, s'appuie discrètement sur une vieille interface se rappellera à vous au pire moment.
Pour le reste, le calcul est simple. Hôte mono-locataire, pas de Zen 5, rien ne presse. Hôte multi-locataires, matériel Zen 5, ou plateforme Arm où la gestion d'énergie des invités était pénible : cette version a quelque chose pour vous. Et si vous êtes sur un dérivé comme XCP-ng, la version qui compte est celle que livre votre distribution, pas celle qui vient d'être étiquetée en amont.
Xen 4.22 est disponible sur xenproject.org. Le Xen Summit 2026 se tient du 15 au 17 septembre à Munich.
Sources et pour aller plus loin
- Annonce officielle de la sortie de Xen 4.22
- Phoronix : Xen 4.22 released with AMD Zen 5 BLT support, improved RISC-V virtualization
- Page de téléchargement du projet Xen
- Annonce de la version précédente, Xen 4.21
Questions fréquentes
Que change concrètement le quota Xenstore ?
Xenstore est la petite base de configuration partagée avec laquelle dialogue chaque domaine Xen. Elle contient les informations de périphériques, l'état d'alimentation, les échanges avec les agents invités et les watches qui permettent à un domaine d'être prévenu quand un autre écrit une clé. Elle est partagée, ce qui en fait depuis toujours un endroit où un domaine mal élevé peut consommer une ressource dont dépendent tous les autres. Xen 4.22 ajoute des quotas par domaine et une limite de profondeur de watch, l'hyperviseur peut donc plafonner ce qu'un invité détient de cette comptabilité commune. Sur un hôte qui n'héberge qu'une charge de confiance, cela ne change rien. Sur un hôte qui loue des domaines à des inconnus, c'est la différence entre un incident circonscrit et un incident qui touche tout le monde.
À quoi sert exactement le Bus Lock Threshold ?
Une instruction atomique verrouille normalement une seule ligne de cache, ce qui est peu coûteux et reste local au cœur. Quand l'opérande chevauche deux lignes de cache, le processeur ne peut plus procéder ainsi et se rabat sur un verrouillage du bus lui-même, ce qui sérialise les accès mémoire de tous les cœurs du socket pendant des milliers de cycles. Un invité qui exécute une boucle d'atomiques mal alignées ralentit donc tous les autres invités de la même machine physique, sans rien faire que l'hyperviseur intercepte habituellement. AMD a ajouté un Bus Lock Threshold avec Zen 5 pour que l'hyperviseur puisse donner à chaque invité un budget de verrouillages de bus et reprendre la main quand ce budget est épuisé. Xen 4.22 prend en charge cette fonction. Les processeurs Intel disposent d'une détection comparable depuis plusieurs générations, cette version comble donc une asymétrie plutôt qu'elle n'invente une idée.
Quand la 4.21 est-elle sortie, et quel est le rythme des versions ?
Xen 4.21 est sortie le 19 novembre 2025, et la 4.20 le 5 mars 2025. Le projet vise historiquement environ deux versions par an, l'écart d'environ huit mois entre 4.21 et 4.22 est donc un peu plus long que le rythme nominal. Les versions de Xen ne sont pas calendaires comme peut l'être une fenêtre de fusion du noyau Linux, et le calendrier glisse quand le contenu le justifie. Le prochain rendez-vous physique est le Xen Summit 2026, prévu du 15 au 17 septembre à Munich, où se dessine généralement l'orientation de la version suivante.
Qui finance et teste Xen aujourd'hui ?
L'annonce de la 4.22 crédite Ford Motor Company, Honda R&D, Renesas Electronics, EPAM et Vates, en insistant sur les tests de sûreté fonctionnelle et sur l'outillage software in the loop pour l'automobile. Cette liste indique où se trouve l'argent. Xen n'est plus d'abord une histoire d'hyperviseur de cloud public, et le travail qui y entre reflète un mélange d'embarqué, d'automobile et de sûreté critique, à côté du serveur traditionnel. Le travail sur le MPU Armv8-R et la mise à jour FF-A 1.2 de cette version relèvent exactement de cette catégorie, tout comme la poursuite de l'activation de RISC-V.
Faut-il mettre à jour tout de suite ?
Pas le jour de la sortie, sauf pour tester. Xen 4.22 supprime des interfaces obsolètes de longue date, et ce sont les suppressions qui cassent les installations. Lisez les notes de version pour tout ce que votre toolstack ou votre configuration d'invités touche encore, puis planifiez la montée de version comme n'importe quel changement d'hyperviseur. Si vous exploitez un hôte multi-locataires, le travail sur les quotas Xenstore est la raison de planifier la mise à jour plutôt que de la repousser indéfiniment. Si vous êtes sur XCP-ng ou un autre dérivé, attendez que ce projet intègre la 4.22, car c'est dans l'intégration aval que se concentre l'essentiel du risque.