Einleitung: Warum GPU Passthrough und dieses Setup?
Die Vision war klar: Ein leistungsstarker, kompakter Rechner, der die Vorteile eines **Linux**-Host-Systems mit der nativen Leistung einer **Windows-VM** für Spiele und spezialisierte Anwendungen verbindet. Kein Dual-Boot, kein Kompromiss. Genau das verspricht **GPU Passthrough**, und genau das war mein Ziel. Die Wahl fiel auf eine einzigartige Kombination: den **AMD Ryzen 7 5700G** Prozessor, bekannt für seine leistungsstarke integrierte Grafikeinheit (iGPU), und das kompakte **ITX Mainboard BIOSTAR B550T-Silver**.
Der Ryzen 5700G sollte die Host-Maschine (Linux) über seine iGPU versorgen, während eine dedizierte Grafikkarte (dGPU) exklusiv an eine virtuelle Windows-Maschine durchgereicht werden sollte. Dieses Setup ermöglicht einen reibungslosen Wechsel zwischen Entwicklungsumgebung, Produktivitäts-Apps unter Linux und grafikintensiven Anwendungen oder Spielen in der Windows-VM – alles auf einem einzigen Monitor und ohne einen Reboot. Die Herausforderung dabei war nicht nur das Prinzip des Passthrough selbst, sondern die Besonderheiten eines **ITX Mainboards**, das oft mit engen Platzverhältnissen und potenziell komplexeren IOMMU-Gruppen einhergeht.
Die Hauptakteure: Hardware und Software im Detail
Bevor das Abenteuer beginnen konnte, musste die Bühne bereitet werden. Hier ist ein genauerer Blick auf die Komponenten, die in diesem Projekt eine zentrale Rolle spielten:
Hardware-Setup:
- CPU: **AMD Ryzen 7 5700G** – Die Herzstück des Systems. Seine potente iGPU sollte den Host mit grafischer Leistung versorgen und gleichzeitig die dGPU für den Gast freihalten.
- Mainboard: **BIOSTAR B550T-Silver** – Ein kompaktes **ITX Mainboard** auf Basis des B550-Chipsatzes. Seine Größe war Fluch und Segen zugleich: Ideal für das kompakte Gehäuse, aber potenziell herausfordernd bei der Isolierung der PCIe-Geräte. Es verfügt über einen einzelnen PCIe 4.0 x16 Slot.
- Grafikkarte (dGPU für den Gast): AMD Radeon RX 6600 XT – Eine solide Mittelklasse-Karte, die genügend Leistung für die meisten modernen Spiele bietet und bekanntermaßen gute Kompatibilität mit **VFIO** und Passthrough aufweist.
- RAM: 32 GB DDR4-3600 CL16 – Ausreichend für Host und Gast, um jeweils genügend Arbeitsspeicher zugewiesen zu bekommen.
- Speicher: Eine schnelle NVMe SSD (1 TB) für das Host-System und eine weitere NVMe SSD (500 GB) exklusiv für die virtuelle Windows-Maschine, um maximale Performance zu gewährleisten.
- Netzteil: Ein SFX-Netzteil mit 750W, um alle Komponenten stabil mit Strom zu versorgen.
Software-Basis:
- Host-Betriebssystem: Arch Linux – Meine persönliche Präferenz für seine Aktualität und die tiefe Kontrolle über das System, was bei **GPU Passthrough** oft von Vorteil ist.
- Virtualisierung: **KVM/QEMU** und **Libvirt** – Die bewährte Kombination für leistungsstarke Hardware-Virtualisierung unter Linux.
- Verwaltung: `virt-manager` – Eine grafische Oberfläche, die die Konfiguration von VMs erheblich vereinfacht, aber bei Bedarf auch direkte XML-Bearbeitung zulässt.
- Gast-Betriebssystem: Windows 10 Pro – Für Gaming und spezifische Windows-Anwendungen.
Vorbereitung ist alles: BIOS-Einstellungen und Basis-Software
Der Erfolg von **GPU Passthrough** steht und fällt mit der sorgfältigen Vorbereitung. Der erste Schritt führte mich ins BIOS des **BIOSTAR B550T-Silver**.
BIOS-Einstellungen:
- Virtualisierung aktivieren: Unabdingbar ist die Aktivierung von `SVM Mode` (AMD-V) und `IOMMU` unter den „Advanced” oder „CPU Configuration” Einstellungen. Ohne diese Funktionen kann KVM keine Hardware-Virtualisierung nutzen.
- PCIe-Einstellungen: Ich stellte sicher, dass `Above 4G Decoding` aktiviert war, was für die Zuweisung größerer Speicherbereiche an die GPU wichtig sein kann. Auch `Resizable BAR` (Smart Access Memory) wurde aktiviert, um die maximale Leistung der Radeon RX 6600 XT zu gewährleisten, sowohl für den Host als auch potenziell für den Gast.
- Initial Graphics Output: Hier wählte ich die `IGPU` als primäre Grafikausgabe, um sicherzustellen, dass die dedizierte RX 6600 XT beim Bootvorgang des Hosts nicht initialisiert wird und somit für **VFIO** zur Verfügung steht.
Host-System Konfiguration (Arch Linux):
Nachdem das BIOS vorbereitet war, ging es an die Einrichtung des Host-Systems:
- System aktualisieren: `sudo pacman -Syu` – Immer der erste Schritt.
- Notwendige Pakete installieren: `sudo pacman -S qemu libvirt edk2-ovmf virt-manager bridge-utils dnsmasq` – Diese Pakete bilden die Grundlage für die Virtualisierung. `edk2-ovmf` ist für UEFI-Firmware in der VM notwendig, `bridge-utils` und `dnsmasq` für das Netzwerk.
- Libvirt starten und aktivieren: `sudo systemctl enable –now libvirtd` – Der Daemon muss laufen, um VMs zu verwalten. Ich fügte meinen Benutzer auch der `libvirt`-Gruppe hinzu: `sudo usermod -aG libvirt $USER`.
- Kernel-Module für VFIO laden: Die Module `vfio`, `vfio_iommu_type1` und `vfio_pci` müssen beim Systemstart geladen werden. Dies wird üblicherweise über eine Konfigurationsdatei in `/etc/modules-load.d/` oder durch direkte Angabe in der `/etc/mkinitcpio.conf` erreicht.
Die IOMMU-Herausforderung: Das BIOSTAR B550T-Silver im Fokus
Hier zeigte sich die wahre Natur eines **ITX Mainboards**. **IOMMU** (Input/Output Memory Management Unit) ist das Herzstück des Passthrough. Es ermöglicht, physischen Geräten exklusiven Zugriff auf den Arbeitsspeicher zu gewähren, ohne dass der Host-Kernel eingreifen muss. Die Geräte werden in „IOMMU-Gruppen” organisiert; idealerweise befindet sich jedes Gerät, das durchgereicht werden soll, in einer eigenen Gruppe oder zusammen mit anderen Geräten, die ebenfalls an den Gast übergeben werden können.
Ein `lspci -nnv` gefolgt von `for d in $(find /sys/kernel/iommu_groups/ -type l | sort -V); do echo „IOMMU Group $(basename „$d”):”; for s in $(ls -1 „$d”); do printf „t$(lspci -nns „$s”)n”; done; done` offenbarte die IOMMU-Gruppen meines **BIOSTAR B550T-Silver**. Und wie erwartet, waren die Gruppen nicht perfekt. Der PCIe x16 Slot, in dem die RX 6600 XT steckte, teilte sich eine IOMMU-Gruppe mit anderen nicht-pass-through-fähigen Geräten, wie z.B. dem SATA-Controller oder USB-Controllern, die ich nicht missen wollte.
Dies ist ein häufiges Problem bei ITX-Boards, wo aufgrund der begrenzten PCIe-Lanes und der physischen Verdrahtung Geräte oft in denselben IOMMU-Gruppen landen. Die Lösung hierfür ist oft der `pcie_acs_override`-Kernel-Parameter. Dieser Patch versucht, die IOMMU-Gruppen künstlich aufzuteilen, kann aber in seltenen Fällen zu Instabilität führen. Auf dem BIOSTAR B550T-Silver war der Parameter `pcie_acs_override=downstream,multifunction` notwendig, um die RX 6600 XT erfolgreich von anderen Geräten zu isolieren. Ohne ihn wäre ein Passthrough nicht möglich gewesen. Ich musste diesen Parameter sorgfältig in der GRUB-Konfiguration setzen.
Das Abenteuer beginnt: Konfiguration für VFIO
Nach der Überwindung der IOMMU-Hürde konnte die eigentliche **VFIO**-Konfiguration beginnen.
GRUB-Parameter:
In der `/etc/default/grub` habe ich die Zeile `GRUB_CMDLINE_LINUX_DEFAULT` wie folgt angepasst:
`GRUB_CMDLINE_LINUX_DEFAULT=”loglevel=3 quiet amd_iommu=on iommu=pt pcie_acs_override=downstream,multifunction”`
- `amd_iommu=on`: Aktiviert die IOMMU auf AMD-Systemen.
- `iommu=pt`: Aktiviert den Passthrough-Modus der IOMMU.
- `pcie_acs_override=downstream,multifunction`: Der bereits erwähnte Workaround für die IOMMU-Gruppen.
Danach `sudo grub-mkconfig -o /boot/grub/grub.cfg` ausführen und neu starten.
Grafikkarte vom Host abkoppeln (Blacklisting):
Um zu verhindern, dass der Host die RX 6600 XT initialisiert, muss der entsprechende Kernel-Treiber (in meinem Fall `amdgpu`) für die Passthrough-Karte geblacklistet werden. Dies geschieht in `/etc/modprobe.d/vfio.conf`:
`blacklist amdgpu`
`blacklist radeon`
`options vfio-pci ids=1002:73ef,1002:aab0` (wobei `1002:73ef` die Vendor/Device ID der GPU und `1002:aab0` die der Audio-Komponente der GPU ist – diese IDs findet man mit `lspci -nn | grep -i vga` und `lspci -nn | grep -i audio`).
Danach musste ich die Initial Ramdisk neu generieren: `sudo mkinitcpio -P`. Ein Neustart war hier erneut notwendig, um sicherzustellen, dass die **VFIO**-Treiber die dGPU beanspruchen.
Nach dem Neustart konnte ich mit `lspci -nnk` überprüfen, ob die RX 6600 XT nun unter dem `vfio-pci`-Treiber lief. Wenn ja, war die halbe Miete bereits bezahlt!
Die virtuelle Maschine gestalten: QEMU/KVM und Libvirt
Mit der Vorbereitung abgeschlossen, ging es an die Konfiguration der virtuellen Windows-Maschine über `virt-manager`.
VM-Erstellung über `virt-manager`:
Ich startete `virt-manager` und erstellte eine neue VM:
- OS-Typ: Windows 10/11.
- Firmware: UEFI x86_64 (OVMF). Dies ist entscheidend für moderne GPUs und Features wie Secure Boot oder Resizable BAR in der VM.
- CPU: Ich wies 6 Kerne und 12 Threads zu, um dem Gast genügend Leistung zu geben. Es ist wichtig, `Host-Passthrough` als CPU-Modell zu wählen, um die nativen CPU-Features freizuschalten. Für optimale Leistung habe ich auch CPU-Pinning konfiguriert, um bestimmte physische Kerne der VM zuzuweisen.
- RAM: 16 GB, was für Gaming ausreichend ist.
- Speicher: Ich wählte die dedizierte NVMe SSD als `VirtIO`-Disk, um maximale I/O-Performance zu erzielen.
Geräte-Passthrough:
Das Hinzufügen der dGPU war der spannendste Teil. Unter „Hardware hinzufügen” wählte ich „PCI Host Device” und fügte sowohl die Grafikkarte (Video) als auch die dazugehörige Audio-Komponente hinzu.
Weitere wichtige Geräte:
- USB-Controller Passthrough: Um Maus und Tastatur nativ an die VM durchzureichen, habe ich einen gesamten USB-Controller (oder einen dedizierten USB-Hub) durchgereicht. Das ist stabiler als einzelne USB-Geräte.
- VirtIO-Treiber: Nach der Windows-Installation ist es essenziell, die `VirtIO`-Treiber zu installieren (als ISO über `virt-manager` einbinden), um die volle Leistung der virtuellen Netzwerkkarte, des Speichers und anderer Komponenten zu nutzen.
- Hypervisor-Erkennung: In der XML-Konfiguration der VM (Zugriff über `virt-manager` -> „Ansicht” -> „Details” -> „XML”) habe ich folgende Zeilen im `
`-Abschnitt hinzugefügt, um zu verhindern, dass Windows erkennt, in einer VM zu laufen (manchmal notwendig, um Treiberprobleme zu vermeiden oder DRM-Mechanismen zu umgehen): <kvm> <hidden state='on'/> </kvm> <vendor_id state='on' value='whatever'/>Der `vendor_id` sollte etwas Beliebiges sein, aber nicht „KVM”.
- MSI-X aktivieren: Für moderne AMD-Karten ist MSI-X oft die bevorzugte Interrupt-Methode. Dies wird in der XML-Datei der VM unter dem `
`-Abschnitt der Grafikkarte hinzugefügt: <driver name='vfio'/> <msi model='msi-x'/>
Troubleshooting und Feinjustierung: Wenn der Bildschirm schwarz bleibt
Wie bei jedem komplexen IT-Projekt gab es auch hier Hürden. Der gefürchtete schwarze Bildschirm der VM beim Start, obwohl alles richtig konfiguriert schien, war einer davon.
Häufige Probleme und deren Lösungen:
- Schwarzer Bildschirm / Kein Signal:
- Überprüfung der IOMMU-Gruppen (mit `pcie_acs_override` oder ohne?).
- Sicherstellen, dass die dGPU vom Host nicht beansprucht wird (`lspci -nnk`).
- BIOS-Einstellungen (Initial Graphics Output, Above 4G Decoding).
- `vfio-pci` Treiber richtig an die GPU gebunden? (`echo „ids…” > new_id`).
- OVMF-Firmware korrekt in der VM konfiguriert?
- Monitor an der dGPU angeschlossen und richtiger Input ausgewählt?
- Für NVIDIA-Karten (obwohl ich hier AMD nutze): Error 43 in Geräte-Manager (beheben durch `kvm hidden=on` und `vendor_id` in der XML). Bei AMD-Karten seltener ein Problem.
- Performance-Probleme:
- `VirtIO`-Treiber in der VM installiert?
- CPU-Pinning für bessere CPU-Cache-Kohärenz.
- Hugepages für den Arbeitsspeicher aktivieren.
- Deaktivieren von `SATA-Controller` Emulation und stattdessen `VirtIO-SCSI` oder `VirtIO-Block` nutzen.
- Audio-Probleme:
- GPU-Audio-Passthrough korrekt konfiguriert?
- Virtuelle Audiogeräte in Windows aktiviert?
- Neustartprobleme der VM: Manchmal schlägt ein Neustart der VM fehl. Das kann daran liegen, dass die GPU nicht richtig zurückgesetzt wird. Dies kann oft durch das Hinzufügen von `options vfio_pci disable_vga=1` in `/etc/modprobe.d/vfio.conf` und das Verwenden eines speziellen `reset_prop` Skripts (aus dem Arch Wiki oder ähnlichen Quellen) in der Libvirt-XML behoben werden. Auf meinem BIOSTAR B550T-Silver und der RX 6600 XT war dies glücklicherweise nicht notwendig.
Das Studium der `dmesg`-Ausgabe und der `libvirtd.log` Dateien war oft der Schlüssel zur Fehlersuche. Schritt für Schritt wurden Probleme identifiziert und gelöst, bis die Windows-VM endlich mit voller Leistung auf der dedizierten Grafikkarte lief.
Fazit und Ausblick: Ein Triumph der Flexibilität
Die Reise zum voll funktionsfähigen **GPU Passthrough** mit dem **AMD Ryzen 7 5700G** auf dem **BIOSTAR B550T-Silver** war anspruchsvoll, aber die Mühe hat sich mehr als gelohnt. Das Ergebnis ist ein extrem flexibles System: Ein stabiles **Linux**-Arbeitsumfeld, das jederzeit die iGPU des 5700G nutzt, und bei Bedarf eine leistungsstarke **Gaming-VM**, die die dedizierte RX 6600 XT voll auslastet. Das Switchen zwischen Host und Gast ist nahtlos, ohne jegliche Performance-Einbußen, die man von herkömmlichen VMs erwarten würde. Die Spiele laufen mit nahezu nativer Leistung, und professionelle Anwendungen nutzen die volle Hardware-Power.
Dieses Projekt hat gezeigt, dass **GPU Passthrough** auch auf kompakten **ITX Mainboards** mit den richtigen Kernel-Parametern und sorgfältiger Konfiguration möglich ist. Die **IOMMU**-Gruppierung des **BIOSTAR B550T-Silver** stellte eine Herausforderung dar, die aber mit `pcie_acs_override` gemeistert werden konnte. Die Flexibilität, die ein solches Setup bietet, ist unübertroffen für Power-User, die das Beste aus beiden Welten – Linux und Windows – herausholen wollen, ohne Kompromisse bei der Leistung einzugehen.
Für die Zukunft sehe ich Potenzial in weiteren Optimierungen, wie der Nutzung von hugepages für noch bessere Speicherperformance oder dem Experimentieren mit verschiedenen CPU-Pinning-Strategien. Das Abenteuer **GPU Passthrough** ist eine fortlaufende Reise des Lernens und der Optimierung, die ich jedem enthusiastischen Bastler nur empfehlen kann.