Was i440fx und Q35 sind
Jede virtuelle Maschine unter QEMU hat einen virtuellen Chipsatz. Er legt das ganze virtuelle Mainboard fest — die PCI-/PCIe-Bus-Topologie, die Southbridge, den Interrupt-Controller, das, was das Gast-Betriebssystem sieht, wenn es beim Start die Hardware aufzählt.
QEMU bietet zwei Möglichkeiten: i440fx und Q35.
i440fx emuliert den Intel 440FX — Codename Natoma, 1996 als Chipsatz für den Pentium Pro und später den Pentium II erschienen. Er zeigt einen flachen PCI-Bus ohne eigene PCIe-Unterstützung. Er war der erste QEMU-Maschinentyp und ist lange die Voreinstellung gewesen. Eine anständige Laufzeit für einen Chipsatz, der für den Pentium Pro entworfen wurde.
Q35 emuliert den Intel Q35 Express, im Juni 2007 für die Core-2-Generation erschienen, gepaart mit der Southbridge ICH9. Er gibt dem Gast einen richtigen PCIe-Root-Complex und einen modernen Interrupt-Controller. Durchgereichte Geräte erscheinen als echte PCIe-Geräte mit der richtigen Topologie.
Beide sind virtuell. Keiner wirkt sich auf die tatsächliche Hardware aus, die der Host nutzt. Der Unterschied liegt darin, was das Gast-Betriebssystem sieht.
Warum Q35 für Passthrough zählt
Geräte, die an eine i440fx-VM durchgereicht werden, erscheinen als alte PCI-Geräte, egal was sie tatsächlich sind. Der Gast sieht sie als „richtig schnelle PCI-Geräte“ statt als PCIe-Geräte. Manche Treiber kommen damit gut zurecht. Andere erwarten PCIe und verhalten sich falsch oder laden gar nicht, wenn sie es nicht finden.
Der PCIe-Root-Complex von Q35 ändert das Bild in mehrerer Hinsicht.
MSI-X
MSI-X (Message Signalled Interrupts — Extended) setzt PCIe voraus. Unter i440fx fällt MSI-X entweder auf alte INTx-Interrupts zurück oder funktioniert überhaupt nicht.
Für NVMe zählt das sehr. NVMe-Controller sind für ihre Architektur mit mehreren Queues auf MSI-X angewiesen. Jedes IO-Queue-Paar bekommt seinen eigenen Interrupt-Vektor. Ohne MSI-X laufen alle IO-Fertigmeldungen durch einen einzigen Interrupt, und das erzeugt bei hohen IOPS einen Engpass.
Es zählt auch für moderne Netzwerkkarten und GPUs. Jedes Gerät, das mehrere Interrupt-Vektoren nutzt, um die Last über CPU-Kerne zu verteilen, braucht MSI-X.
AER (Advanced Error Reporting)
PCIe-AER lässt den Gast Gerätefehler richtig erkennen und behandeln, statt stillschweigend zu scheitern. Unter i440fx sieht der Gast Fehler auf PCIe-Ebene überhaupt nicht.
Bei produktiver Arbeit mit einem durchgereichten Gerät ist stilles Verschlucken von Fehlern ein Problem. AER gibt dem Treiber im Gast die Möglichkeit, Hardwarefehler zu protokollieren, zu melden und teilweise auszubügeln, die sonst unbemerkt blieben, bis Daten verdorben sind.
ACS (Access Control Services)
ACS steuert DMA von Gerät zu Gerät auf demselben Bus. Es ist Teil des Isolationsmodells der IOMMU. Es verhindert, dass ein Gerät per DMA in den Speicherbereich eines anderen schreibt, ohne über die IOMMU zu gehen.
Unter i440fx unterstützt die virtuelle Bus-Topologie ACS überhaupt nicht. Das zerbricht einfaches Passthrough nicht, aber es schwächt die Isolation, die die IOMMU dir geben soll.
Wie IOMMU-Gruppen gezeigt werden
Die PCIe-Hierarchie von Q35 heißt, dass jeder virtuelle Slot im Gast in seiner eigenen IOMMU-Gruppe sitzen kann. i440fx wirft alles auf einen gemeinsamen Bus, was die IOMMU-Konfiguration auf der Gast-Seite schwierig macht.
Das ist wichtig für geschachtelte Virtualisierung, wo der Gast selbst saubere IOMMU-Gruppen braucht. Und es ist wichtig für vIOMMU, das es nur auf Q35 gibt.
vIOMMU
Wenn du willst, dass der Gast selbst IOMMU-Fähigkeit hat — für geschachteltes Passthrough, für DPDK oder für bestimmte Sicherheitsaufbauten —, braucht das den Maschinentyp Q35.
Die vIOMMU-Emulation lässt den Gast seine eigene IOMMU betreiben, und das ist nützlich für:
- geschachteltes VM-Passthrough (eine VM in einer VM mit Gerätezugriff)
- DPDK-Netzwerkbetrieb im Userspace, wo die Anwendung IOMMU-Schutz braucht
- Sicherheitsaufbauten, die DMA-Isolation im Gast verlangen
Warum Q35 auch abseits von Passthrough zählt
Selbst wenn du kein Passthrough machst, ist Q35 für moderne Arbeit die bessere Wahl.
OVMF-Firmware (UEFI)
Die Kombination aus Q35 und OVMF gibt dem Gast eine moderne UEFI-Startumgebung samt Secure Boot. i440fx kann OVMF nutzen, aber die Kombination ist schlechter getestet, und manche Funktionen arbeiten nicht richtig.
Windows 11 verlangt UEFI mit Secure Boot. Microsofts Hardwareanforderungen schreiben es vor. Windows Server 2025 läuft mit UEFI am besten. Q35 mit OVMF ist für beide der unterstützte Weg.
Betreibst du eine VM mit Windows 11 oder Server 2025 auf i440fx mit SeaBIOS, kämpfst du gegen die Strömung. Es geht vielleicht heute. Dort läuft das Umfeld aber nicht hin.
AHCI
Q35 bringt über die Southbridge ICH9 eine eigene AHCI-Emulation mit (Advanced Host Controller Interface). i440fx nutzt für Startlaufwerke die ältere IDE- oder LSI-SCSI-Emulation.
Für VirtIO-Speicher zählt das nicht. VirtIO umgeht den Speichercontroller des Chipsatzes komplett. Nutzt du aber SATA-Emulation für ein Gast-System, dem zur Installationszeit VirtIO-Treiber fehlen, ist AHCI auf Q35 viel schneller als IDE auf i440fx.
Der Overhead, den i440fx trägt und Q35 nicht
Der Abstand bei AHCI liegt nicht bloß daran, dass ein Controller neuer ist. Er liegt daran, dass i440fx den Gast bei fast jeder Interaktion den Hypervisor bezahlen lässt, und Q35 überwiegend nicht.
Abgefangene Registerzugriffe. IDE wird über alte x86-I/O-Ports programmiert. Der Gast schreibt die Sektorenzahl, dann die LBA-Register, dann das Befehlsregister. Jeder Schreibvorgang trifft einen eigenen Port. Jeder dieser Zugriffe wird vom Host abgefangen und emuliert, und jedes Abfangen ist ein VM-Exit für ein paar Mikrosekunden. Einen IDE-Befehl abzuschicken kostet daher mehrere Exits, bevor überhaupt Daten fließen.
AHCI läuft umgekehrt. Der Gast baut eine Befehlstabelle in seinem eigenen RAM — kein Abfangen, denn er schreibt bloß in Speicher — und macht dann einen MMIO-Schreibvorgang auf ein Türklingel-Register, damit der Controller sie holt. Ein Befehl kostet etwa einen Exit statt fünf oder sechs.
Kein Befehls-Queueing. IDE schickt einen Befehl ab und wartet, bis er fertig ist. AHCI unterstützt NCQ, also können bis zu 32 Befehle offen sein, und das Laufwerk darf sie außer der Reihe fertigstellen, um Sucharbeit zu sparen. Damit verteilen sich die restlichen Kosten pro Befehl über eine Queue statt einzeln anzufallen.
Der alte Interrupt-Weg. Der IDE-Controller im PIIX3 meldet die Fertigstellung auf den festen alten IRQs 14 und 15, zugestellt als pegelgesteuertes INTx. Ein pegelgesteuerter Interrupt muss bestätigt und wieder freigegeben werden, und weil INTx-Leitungen geteilt werden, muss der Gast außerdem herausfinden, welches Gerät ihn ausgelöst hat. Jeder dieser Schritte ist wieder ein Abfangen. MSI-X, das Q35 braucht, ist ein einfacher Speicherschreibvorgang ohne geteilte Leitung, die zu bestimmen wäre, und ohne Bestätigungslauf. Auf Hardware mit Posted Interrupts kann es den Gast ganz ohne Exit erreichen.
Eine größere Fläche alter Geräte. i440fx zeigt seine alten Plattformgeräte immer, den IDE-Controller eingeschlossen, ob die VM sie nutzt oder nicht. Sie belegen PCI-Slots, sie werden bei jedem Start aufgezählt und angetastet, und Treiber im Gast können sie abfragen. Q35 zeigt einen kleineren, moderneren Satz. Weniger, was der Host vorhalten muss, weniger, was der Gast ablaufen muss.
Nichts davon zeigt sich in einer VM mit VirtIO, und deshalb ist der Unterschied leicht zu übersehen. Er zählt während der Installation, bei Appliance-Abbildern ohne VirtIO-Treiber und bei jedem Gast, der für sein Startlaufwerk noch emuliertes SATA oder IDE nutzt.
Weniger virtuelle Geräte, sauberere Topologie
i440fx kommt mit alter virtueller Hardware, die Q35 weglässt. Eine Attrappe von einer Soundkarte. Ein alter IDE-Controller. Keines von beiden tut etwas Nützliches, aber beide verbrennen virtuelle PCI-Slots und können Software im Gast verwirren, die sie zu nutzen versucht.
Q35 zeigt einen saubereren Satz virtueller Hardware, der näher an dem liegt, was ein moderner physischer Server hergeben würde.
Die Richtung, in die es geht
RHEL 10 hat i440fx für überholt erklärt
Red Hat hat den Maschinentyp i440fx in RHEL 10 formell für überholt erklärt. Das zeigt die Richtung für das ganze KVM-Umfeld. Wenn Red Hat etwas für überholt erklärt, heißt das, sie testen es nicht mehr als erstklassigen Weg und werden Fehler, die daran hängen, nicht beheben.
Das QEMU-Projekt selbst diskutiert die Abkündigung von i440fx seit Jahren. Der Tenor ist, dass zwei Chipsatz-Wege eine Last sind. Q35 ist derjenige, der auf moderne Hardware passt.
Proxmox ist nicht mitgegangen
Proxmox VE legt neue VMs weiterhin als i440fx an. Der Maschinentyp im Anlegen-Assistenten liest sich als „Default (i440fx)“, und dabei bleibt es, solange du es nicht änderst. Q35 ist ein Auswahlfeld weiter, aber es ist eine Wahl, die du bei jeder VM, die du baust, bewusst treffen musst.
Genau deshalb gibt es diesen Beitrag. Die Voreinstellung ist der Chipsatz von 1996, und nichts im Assistenten sagt dir, dass die Wahl etwas ausmacht.
Eine bestehende VM umstellen
Hast du eine bestehende VM auf i440fx, kannst du in den Hardware-Einstellungen oder direkt in der Konfiguration auf Q35 umstellen:
machine: q35
Das ist im Grunde ein Tausch des virtuellen Mainboards. Beim nächsten Start andere Hardware.
Linux kommt damit meist ohne Weiteres zurecht.
Der Kernel zählt die Geräte neu auf und lädt die richtigen Treiber.
Schnittstellennamen werden sich ändern, weil die virtuelle NIC von einem PCI-Bus auf einen PCIe-Bus wandert.
Nennt deine Netzkonfiguration sie beim Namen (etwa eth0, ens18), passe sie vor dem Neustart an, sonst verlierst du den Netzzugang.
Windows ist weniger nachsichtig. Der Chipsatzwechsel heißt andere virtuelle Hardware-IDs für den Speichercontroller, den Netzwerkadapter und andere Plattformgeräte. Windows braucht möglicherweise eine Neuinstallation der Treiber. In manchen Fällen ist eine Neuinstallation der sauberste Weg. Älteres Windows ist der üblichste Fall.
FreeBSD und Abkömmlinge (OPNsense, pfSense) kommen mit dem Wechsel meist zurecht, aber teste es vorher.
Teste in allen Fällen an einer VM ohne Produktivlast, bevor du etwas umstellst, worauf es ankommt.
Wann i440fx noch gebraucht wird
Eine Handvoll Fälle braucht i440fx noch.
Alte Gast-Betriebssysteme, die älter sind als UEFI — Windows XP, Windows 2000 und Ähnliches dieses Jahrgangs —, starten unter Q35 möglicherweise nicht. Diese Systeme erwarten die alte PCI-Topologie und das SeaBIOS, die i440fx bietet.
Bestimmte Appliance-Abbilder sind ausschließlich gegen i440fx gebaut und getestet. Unterstützt der Anbieter nur i440fx, nimmst du das, bis er nachzieht.
Für alles andere — neue Linux-VMs, modernes Windows, jede Arbeit mit Passthrough — nimm Q35. Es ist nichts zu gewinnen, wenn man aus Gewohnheit an einem Chipsatz von 1996 festhält.
Quellen
- Proxmox-VE-Wiki — PCI(e) Passthrough — die offizielle Proxmox-Dokumentation, die Q35 als empfohlenen Maschinentyp für Passthrough nennt
- QEMU Q35 Chipset Specification (PDF) — das ursprüngliche QEMU-Entwurfsdokument zu Q35
- Proxmox-Forum — Diskussion Q35 gegen i440fx — Diskussion aus der Gemeinschaft über die praktischen Unterschiede