QEMU 11.1 étend l’émulation UFS 4.1 et RISC-V avec 3 200 commits de 285 contributeurs

11 août 2026. La version 11.1 de QEMU est publiée, avec plus de 3 200 commits issus de 285 contributeurs. La ligne de force : aucune fonctionnalité ne domine à elle seule, mais des progrès répartis sur le stockage, les architectures émergentes et l’émulation. Le contexte : QEMU reste la brique d’émulation sous-jacente de la virtualisation KVM, celle qui fait tourner la majorité des machines virtuelles Linux.

Pour un administrateur, une version de QEMU ne fait jamais la une. C’est pourtant le genre de sortie qu’il faut lire : les changements y préparent le terrain des matériels et des charges à venir.

UFS 4.1 : du stockage mobile, émulé pour les tests

Le lot le plus concret concerne UFS, la norme de stockage flash qui équipe smartphones et systèmes embarqués. QEMU 11.1 ajoute l’émulation du Write Booster, défini par la spécification UFS 4.1, ainsi que l’émulation de la défragmentation initiée par l’hôte (HID), issue de la même spécification.

Pourquoi cela intéresse-t-il autre chose que les fabricants de téléphones ? Parce que l’émulation permet de tester des piles logicielles de stockage sans matériel : systèmes de fichiers, contrôleurs, firmwares, dans une machine virtuelle reproductible. Une équipe qui développe pour de l’embarqué peut valider le comportement d’un contrôleur UFS 4.1 dans une CI, sans aligner des cartes physiques.

C’est le rôle historique de QEMU : être un banc d’essai pour des matériels qui n’existent pas encore dans le parc, ou qu’on ne veut pas manipuler physiquement.

RISC-V et Arm continuent leur montée

Côté architectures, RISC-V progresse sur deux fronts. QEMU 11.1 supporte l’extension Zvfbfa — des opérations vectorielles pour le format BF16, utile aux charges d’IA en virgule réduite — et ajoute le support big endian de RISC-V, un mode rare mais requis par certains écosystèmes embarqués.

Arm n’est pas en reste : la version apporte de nouvelles fonctionnalités architecturales de CPU, poursuivant l’alignement de QEMU sur les dernières extensions des cœurs Arm. Pour qui compile ou teste des logiciels sur ces architectures, QEMU reste le moyen le plus simple de disposer d’une cible reproductible sans matériel dédié.

Cette extension illustre une tendance de fond : les extensions vectorielles destinées à l’IA arrivent dans QEMU en même temps que dans les cœurs physiques, ce qui permet de développer et de tester des charges d’IA sur ces architectures avant même que le silicium ne soit largement disponible.

Le signal de fond est la diversification : QEMU ne suit plus seulement x86, il devient le plan de travail commun des architectures qui se partagent l’avenir du calcul — serveur, mobile et embarqué.

Le reste : interface et émulation user-mode

La version améliore aussi l’interface graphique de l’outil et livre de nombreuses améliorations de l’émulation user-mode — le mode qui exécute un binaire d’une autre architecture directement sur l’hôte, sans machine virtuelle complète. C’est le chemin qu’utilisent les développeurs pour tester un binaire Arm ou RISC-V sur une station x86.

Ces améliorations ne font pas la une, mais elles allègent le quotidien de ceux qui font du cross-compilation et du test multi-architectures. Chaque gain de fidélité en user-mode réduit l’écart entre « ça marche en émulation » et « ça marche sur la cible ».

Comment QEMU s’insère dans la pile

Pour mesurer ce qu’une version de QEMU change, il faut situer la brique. QEMU travaille à deux niveaux. En mode émulation complète (TCG), il traduit le code machine d’une architecture vers une autre — c’est ce qui permet de faire tourner un binaire Arm sur x86. En mode accéléré (KVM), il délègue la virtualisation du CPU au noyau et se concentre sur l’émulation des périphériques : disques, cartes réseau, contrôleurs.

C’est ce second mode qui domine en production. Un datacenter qui virtualise avec KVM utilise QEMU pour fournir à chaque machine virtuelle ses périphériques — un disque virtio-blk, une carte virtio-net. La qualité de cette émulation détermine la latence et le débit que voient les invités. C’est pourquoi les améliorations de 11.1, même discrètes, finissent par se refléter dans les performances de milliers de machines.

Le choix du mode est une décision d’exploitation : de la virtualisation de production passe par KVM ; de l’émulation croisée ou du développement passe par TCG ou le user-mode. La plupart des équipes utilisent les deux sans y penser, et c’est précisément le rôle d’une version stable que de maintenir les deux chemins en bon état.

Monter de version, sans se brûler

Pour un hôte Debian ou Ubuntu, la montée de version passe par la distribution, pas par la compilation. Vérifier sa version et planifier la mise à jour tient en deux commandes :

qemu-system-x86_64 --version
# Sur Debian/Ubuntu, lister les paquets QEMU installés
dpkg --list 'qemu-*' 2>/dev/null | grep '^ii'

Attendre la livraison par la distribution garantit que 11.1 arrive avec les correctifs et les intégrations libvirt déjà testés. Pour les environnements qui testent du RISC-V ou de l’Arm en CI, un build plus récent — via les dépôts de la distribution ou un conteneur dédié — permet de profiter des nouvelles extensions Zvfbfa sans déstabiliser les hôtes de production.

Une brique discrète mais critique

QEMU est de ces composants qu’on ne remarque qu’en cas de panne. Sous KVM, il fournit l’émulation des périphériques — disques, réseau, contrôleurs — pendant que le noyau gère la virtualisation du CPU. Quand un datacenter fait tourner des milliers de machines virtuelles, une régression dans QEMU est une régression dans tout le parc.

Une sortie comme 11.1 se lit donc à deux niveaux. Pour l’administrateur, c’est une montée de version à planifier via sa distribution — Debian, Ubuntu, RHEL l’embarqueront dans leurs cycles respectifs. Pour le curieux, c’est une photographie de la direction du projet : davantage d’architectures, davantage d’émulation de stockage, et un user-mode toujours plus fidèle.

La version ne contient pas de correctif de sécurité majeur à déployer en urgence — elle s’inscrit dans le rythme régulier du projet, qui publie ses versions intermédiaires à cadence stable. C’est précisément cette régularité qui fait de QEMU une brique fiable.

Cette régularité cache une réalité que peu d’équipes mesurent : la quasi-totalité du cloud s’appuie sur cette brique. Les hyperviseurs des grands fournisseurs, les piles OpenStack, les orchestrateurs libvirt et les hôtes Proxmox reposent tous, directement ou indirectement, sur l’émulation de périphériques de QEMU. Une version comme 11.1 ne se contente pas d’améliorer un outil : elle améliore, de proche en proche, le socle sur lequel tourne une part considérable de l’infrastructure hébergée.

Verdict

Si vous gérez des hôtes de virtualisation KVM, attendez la livraison de QEMU 11.1 par votre distribution plutôt que de compiler : les gains sont réels mais progressifs, et la stabilité de votre chaîne de virtualisation vaut plus qu’une avance de quelques semaines.

Si vous testez du stockage embarqué ou des architectures RISC-V/Arm, la nouvelle émulation UFS 4.1 et les extensions Zvfbfa sont une raison concrète de monter de version dès qu’elle est disponible : elles étendent le périmètre de ce que vous pouvez valider sans matériel.

Le signal de fond : QEMU poursuit sa mue en banc d’essai universel des architectures et des stockages de demain. Ce n’est pas spectaculaire, mais c’est exactement ce qu’on attend d’une brique d’infrastructure — avancer sans bruit, version après version.

Références

• Phoronix — QEMU 11.1 Released With Numerous Improvements, 11 août 2026
• LWN.net — QEMU 11.1 released, 12 août 2026
• QEMU Wiki — ChangeLog/11.1, consulté le 17 août 2026