i440fx et Q35, qu’est-ce que c’est ?
Toute machine virtuelle QEMU a un chipset virtuel. Il définit toute la carte mère virtuelle — la topologie du bus PCI/PCIe, le southbridge, le contrôleur d’interruptions, ce que le système invité voit quand il énumère le matériel au démarrage.
QEMU offre deux choix : i440fx et Q35.
i440fx émule l’Intel 440FX — nom de code Natoma, sorti en 1996 comme chipset du Pentium Pro puis, plus tard, du Pentium II. Il présente un bus PCI plat sans prise en charge native du PCIe. C’était le type de machine QEMU d’origine et il est resté longtemps le défaut. Belle carrière pour un chipset conçu pour le Pentium Pro.
Q35 émule l’Intel Q35 Express, sorti en juin 2007 pour la génération Core 2, associé au southbridge ICH9. Il donne à l’invité un vrai root complex PCIe et un contrôleur d’interruptions moderne. Les équipements passés en passthrough apparaissent comme de vrais équipements PCIe, avec la bonne topologie.
Les deux sont virtuels. Ni l’un ni l’autre n’affecte le matériel réel qu’utilise l’hôte. La différence, c’est ce que voit le système invité.
Pourquoi Q35 compte pour le passthrough
Les équipements passés à une VM i440fx apparaissent comme des équipements PCI hérités, quels qu’ils soient réellement. L’invité les voit comme des « équipements PCI très rapides » plutôt que comme des équipements PCIe. Certains pilotes s’en accommodent très bien. D’autres attendent du PCIe et se comportent mal, ou refusent de se charger quand ils n’en trouvent pas.
Le root complex PCIe de Q35 change le tableau de plusieurs façons.
MSI-X
MSI-X (Message Signalled Interrupts — Extended) exige du PCIe. Sous i440fx, MSI-X se rabat sur les interruptions INTx héritées ou ne fonctionne pas du tout.
Ça compte énormément pour le NVMe. Les contrôleurs NVMe s’appuient sur MSI-X pour leur architecture multi-files. Chaque paire de files d’E/S obtient son propre vecteur d’interruption. Sans MSI-X, tous les achèvements d’E/S passent par une seule interruption, ce qui crée un goulot d’étranglement à fort IOPS.
Ça compte aussi pour les cartes réseau et les GPU modernes. Tout équipement qui utilise plusieurs vecteurs d’interruption pour répartir la charge sur les cœurs CPU a besoin de MSI-X.
AER (Advanced Error Reporting)
L’AER PCIe permet à l’invité de détecter et de traiter correctement les erreurs d’équipement plutôt que d’échouer en silence. Sous i440fx, l’invité n’a aucune visibilité sur les erreurs de niveau PCIe.
Pour une charge de production avec un équipement en passthrough, avaler les erreurs en silence est un problème. L’AER donne au pilote invité la capacité de journaliser, de signaler et parfois de récupérer d’erreurs matérielles qui passeraient autrement inaperçues jusqu’à ce que des données soient corrompues.
ACS (Access Control Services)
L’ACS contrôle le DMA pair-à-pair entre équipements du même bus. Il fait partie du modèle d’isolation de l’IOMMU. Il empêche un équipement de faire du DMA dans l’espace mémoire d’un autre sans passer par l’IOMMU.
Sous i440fx, la topologie de bus virtuelle ne prend pas du tout en charge l’ACS. Ça ne casse pas le passthrough de base, mais ça affaiblit l’isolation que l’IOMMU est censée vous donner.
Présentation des groupes IOMMU
La hiérarchie PCIe de Q35 fait que chaque connecteur virtuel peut siéger dans son propre groupe IOMMU au sein de l’invité. i440fx entasse tout sur un bus partagé, ce qui rend la configuration IOMMU côté invité problématique.
C’est pertinent pour la virtualisation imbriquée, où l’invité a lui-même besoin de groupes IOMMU propres. C’est pertinent aussi pour la vIOMMU, qui n’est disponible que sur Q35.
vIOMMU
Si vous avez besoin que l’invité dispose lui-même d’une capacité IOMMU — pour du passthrough imbriqué, pour DPDK ou pour certaines configurations de sécurité — cela exige le type de machine Q35.
L’émulation vIOMMU permet à l’invité de faire tourner sa propre IOMMU, ce qui est utile pour :
- le passthrough en VM imbriquée (une VM dans une VM avec accès aux équipements)
- le réseau en espace utilisateur DPDK, où l’application a besoin de la protection IOMMU
- les configurations de sécurité qui exigent une isolation DMA à l’intérieur de l’invité
Pourquoi Q35 compte au-delà du passthrough
Même si vous ne faites pas de passthrough, Q35 est le meilleur choix pour les charges modernes.
Micrologiciel OVMF (UEFI)
La combinaison Q35 et OVMF donne à l’invité un environnement de démarrage UEFI moderne avec prise en charge du Secure Boot. i440fx peut utiliser OVMF, mais la combinaison est moins bien testée et certaines fonctions ne marchent pas correctement.
Windows 11 exige l’UEFI avec Secure Boot. Les prérequis matériels de Microsoft l’imposent. Windows Server 2025 fonctionne au mieux avec l’UEFI. Q35 avec OVMF est le chemin pris en charge pour les deux.
Si vous faites tourner une VM Windows 11 ou Server 2025 sur i440fx avec SeaBIOS, vous ramez à contre-courant. Ça marche peut-être aujourd’hui. Ce n’est pas là que va l’écosystème.
AHCI
Q35 inclut une émulation AHCI (Advanced Host Controller Interface) native via le southbridge ICH9. i440fx utilise l’émulation IDE ou LSI SCSI, plus ancienne, pour les disques de démarrage.
Pour du stockage VirtIO, ça ne change rien. VirtIO contourne entièrement le contrôleur de stockage du chipset. Mais si vous utilisez l’émulation SATA pour un système invité qui n’a pas les pilotes VirtIO au moment de l’installation, l’AHCI de Q35 est bien plus rapide que l’IDE d’i440fx.
La surcharge qu’i440fx porte et que Q35 n’a pas
L’écart AHCI ne tient pas seulement à ce qu’un contrôleur soit plus récent. C’est qu’i440fx fait payer l’hyperviseur à l’invité à presque chaque interaction, et que Q35 ne le fait pas, pour l’essentiel.
Accès registre piégés. L’IDE se programme via les ports d’E/S x86 hérités. L’invité écrit le nombre de secteurs, puis les registres LBA, puis le registre de commande. Chaque écriture touche un port distinct. Chacun de ces accès est piégé et émulé par l’hôte, et chaque piège est une sortie de VM qui coûte quelques microsecondes. Émettre une seule commande IDE coûte donc plusieurs sorties avant qu’une seule donnée ne bouge.
L’AHCI fonctionne à l’envers. L’invité construit une table de commandes dans sa propre RAM — aucun piège, puisqu’il ne fait qu’écrire en mémoire — puis fait une seule écriture MMIO dans un registre de sonnette pour dire au contrôleur d’aller la chercher. Une commande coûte à peu près une sortie au lieu de cinq ou six.
Pas de file de commandes. L’IDE émet une commande et attend qu’elle finisse. L’AHCI prend en charge le NCQ, donc jusqu’à 32 commandes peuvent être en cours, et le disque est libre de les terminer dans le désordre pour réduire les déplacements de tête. Ainsi, le coût par commande qui reste se répartit sur une file au lieu d’être payé une par une.
Le chemin d’interruption hérité. Le contrôleur IDE PIIX3 signale l’achèvement sur les IRQ héritées fixes 14 et 15, livrées en INTx déclenché par niveau. Une interruption par niveau doit être acquittée puis démasquée, et comme les lignes INTx sont partagées, l’invité doit en plus trouver quel équipement l’a levée. Chacune de ces étapes est un piège de plus. MSI-X, qui exige Q35, est une simple écriture en mémoire, sans ligne partagée à identifier ni aller-retour d’acquittement. Sur du matériel à interruptions postées, elle peut atteindre l’invité sans aucune sortie.
Une surface d’équipements hérités plus large. i440fx présente toujours ses équipements de plateforme hérités, contrôleur IDE compris, que la VM s’en serve ou non. Ils occupent des connecteurs PCI, ils sont énumérés et sondés à chaque démarrage, et des pilotes invités peuvent les interroger en boucle. Q35 présente un jeu plus réduit et plus moderne. Moins à porter pour l’hôte, moins à parcourir pour l’invité.
Rien de tout cela n’apparaît dans une VM adossée à VirtIO, et c’est pour ça que la différence est facile à manquer. Ça compte pendant l’installation, sur les images d’appliance sans pilotes VirtIO, et sur tout invité qui utilise encore du SATA ou de l’IDE émulé pour son disque de démarrage.
Moins d’équipements virtuels, une topologie plus propre
i440fx arrive avec du matériel virtuel hérité que Q35 laisse tomber. Une carte son factice. Un contrôleur IDE hérité. Ni l’un ni l’autre ne sert à rien, mais tous deux brûlent des connecteurs PCI virtuels et peuvent perturber des logiciels invités qui essaient de s’en servir.
Q35 présente un jeu de matériel virtuel plus propre, qui ressemble davantage à ce qu’exposerait un serveur physique moderne.
Le sens de l’histoire
RHEL 10 a déprécié i440fx
Red Hat a formellement déprécié le type de machine i440fx dans RHEL 10. Ça indique le sens de l’histoire pour tout l’écosystème KVM. Quand Red Hat déprécie quelque chose, cela veut dire qu’ils ont cessé de le tester comme un chemin de premier plan et qu’ils ne corrigeront pas les bogues qui s’y rattachent.
Le projet QEMU en amont discute de la dépréciation d’i440fx depuis des années. Le consensus est que maintenir deux chemins de chipset est un fardeau. Q35 est celui qui correspond au matériel moderne.
Proxmox n’a pas suivi
Proxmox VE crée toujours les nouvelles VM en i440fx. Le type de machine dans l’assistant de création affiche « Default (i440fx) », et il le reste tant que vous n’y touchez pas. Q35 est à une liste déroulante de là, mais c’est un choix que vous devez faire délibérément, sur chaque VM que vous construisez.
C’est toute la raison d’être de cet article. Le défaut est le chipset de 1996, et rien dans l’assistant ne vous dit que le choix compte.
Basculer une VM existante
Si vous avez une VM existante en i440fx, vous pouvez passer à Q35 dans les paramètres matériels ou directement dans la configuration :
machine: q35
C’est en pratique un changement de carte mère virtuelle. Du matériel différent au prochain démarrage.
Linux gère ça en général sans souci.
Le noyau ré-énumère les équipements et charge les bons pilotes.
Les noms d’interface changeront parce que la carte réseau virtuelle passe d’un bus PCI à un bus PCIe.
Si votre configuration réseau les nomme (par exemple eth0, ens18), mettez-la à jour avant de redémarrer, sinon vous perdez l’accès réseau.
Windows est moins indulgent. Le changement de chipset implique des identifiants matériels virtuels différents pour le contrôleur de stockage, la carte réseau et d’autres équipements de plateforme. Windows peut avoir besoin d’une réinstallation de pilotes. Dans certains cas, une installation neuve est le chemin le plus propre. Les Windows anciens sont les fautifs habituels.
FreeBSD et ses dérivés (OPNsense, pfSense) encaissent en général le changement, mais testez d’abord.
Dans tous les cas, testez sur une VM hors production avant de basculer quoi que ce soit qui compte.
Quand i440fx est encore nécessaire
Une poignée de cas exigent encore i440fx.
Les systèmes invités hérités antérieurs à l’UEFI — Windows XP, Windows 2000 et de ce millésime — peuvent ne pas démarrer sous Q35. Ces systèmes attendent la topologie PCI héritée et le SeaBIOS que fournit i440fx.
Certaines images d’appliance sont construites et testées exclusivement contre i440fx. Si l’éditeur ne prend en charge qu’i440fx, c’est ce que vous utilisez jusqu’à ce qu’il mette à jour.
Pour tout le reste — nouvelles VM Linux, Windows modernes, toute charge avec passthrough — utilisez Q35. Il n’y a rien à gagner à s’accrocher par habitude à un chipset de 1996.
Références
- Wiki Proxmox VE — passthrough PCI(e) — la documentation officielle de Proxmox, qui indique Q35 comme type de machine recommandé pour le passthrough
- Spécification du chipset QEMU Q35 (PDF) — le document de conception QEMU d’origine pour Q35
- Forum Proxmox — discussion Q35 contre i440fx — la discussion communautaire sur les différences pratiques