QEMU/KVM mit dedizierter Grafikkarte

[fireburner]

Hallo Zusammen,

da ich in den letzten Wochen viel mit QEMU/KVM und dedizierter Grafik experimentiert habe, wollte ich auch Andere an meinen Experimenten teilhaben lassen und habe daher einen Wiki Eintrag hierfür erstellt.

Vielleicht möchte dies ja der ein oder andere selbst ausprobieren und seine Erfahrungen mit einfließen lassen.
Ansonsten freue ich mich auf Ergänzungen und Verbesserungsvorschläge zum Artikel.

editiert 2021-02-19: Link zum Wiki Beitrag angepasst

[NAB]

Die Idee finde ich sehr gut!

Aber ... sorry ... das liest sich, als ob du irgendeinem veralteten Tutorial gefolgt bist.

Das fängt bei deiner Beschreibung von Vt-d an. Seit Skylake (2015) haben meineswissens alle Intel-Prozessoren Vt-d. Hier z.B. ein i7-6700K mit Vt-d:
https://ark.intel.com/products/88195/
Bei älteren Systemen hast du ein Flickwerk aus unterstützenden Prozessoren und unterstützenden Chipsätzen/Mainboards. Eins der Hauptprobleme der Anwender ist es herauszubekommen, ob Vt-d in ihrem System vorhanden ist, aktiviert ist und funktioniert.

Erwähnenswert: Notebook-Hybridgeschichten wie Nvidia-Optimus funktionieren nicht (vonwegen zwei Grafikkarten).

Erwähnenswert: Man braucht zwei Monitore oder einen Monitor mit zwei Eingängen (zwischen denen man umschalten muss).

Ob die VM einen UEFI- oder BIOS-Boot macht, hat erst mal nichts mit der Grafikkarte zu tun. Das ist derart vereinfacht dargestellt, dass es schon falsch ist. Auch ein UEFI-Boot bootet dir problemlos deine Grafikkarte im VGA-Modus. Da hast du nur bei Intel-Grafiken das Problem, dass der Intel-VGA-Treiber des Hostes nicht mit einer im VGA-Modus gebooteten Grafikkarte des Gastes klarkommt. Wohlgemerkt "gebootet". Es ist kein Problem, den Gast mit einer virtuellen Grafikkarte als primäre Karte im VGA-Modus zu booten und die echte Karte als sekundäre Karte durchzureichen - egal ob Seabios oder OVMF.

vfio als "optional" zu bezeichnen halte ich für gewagt. pci-stub ist "deprecated" und wird nicht mehr weiterentwickelt.

Das Problem der IOMMU-Groups streifst du gar nicht.

Dass es wichtig ist, die Grafikkarte zusammen mit der zugehörigen Soundkarte durchzureichen, könnte etwas mehr betont werden. Ebenso, dass es wichtig ist, dass generell kein Treiber (außer vfio-pci) die Grafikkarte anfasst. Und auch eine mit Treibern belegte Soundkarte kann Probleme machen, wenn der Treiber sich nicht mehr problemlos entfernen lässt.

Die Hinweise zur virtuellen Festplatte sind zwar schön und gut, gehören aber eigentlich nicht in den Artikel, oder? Da könnte man noch viel mehr zu sagen, inklusive der tollen Möglichkeit, mit qcow2 Snapshots und Backups anzufertigen. Und der Frage, wo man diese Dateien denn auf der Platte findet. Das wäre vielleicht einen eigenen Artikel wert.

Die Themen "Netzwerk" und "virsh" und die XML-Dateien streifst du gar nicht. Ebenso Suspend/Reboot von Host und Guest. Die wären vermutlich auch in einem eigenen Artikel "Windows mit Qemu virtualisieren" besser aufgehoben.

Alex Williamson rät weiterhin generell zum i440FX Chipsatz, auch bei UEFI/OVMF.

Das "Tolle" an UEFI/OVMF ist, dass du eben ohne zusätzliche virtuelle Grafikkarte auskommst. Die VM bootet gleich über die durchgereichte Grafikkarte und ein Benutzer, dem du Monitor, Maus und Tastatur hinstellst, merkt gar nicht mehr, dass er vor einem virtuellen Windows sitzt. Das ist für den Heim-Spieler zwar zweitrangig, aber sollte vielleicht erwähnt werden, um die Unterschiede zu erläutern. Und sämtliche Windows8-tauglichen Grafikkarten sollten eine UEFI-Firmware haben ... hat Microsoft so bestimmt.

Erwähnenswert: als "zusätzlicher Soundcontroller" ist eine billige USB-Karte am unkompliziertesten. Deren Lineout kann man an den Line-in des Hostes hängen.

Zum berüchtigten Code 43 Problem bei Nvidia-Grafikkarten schreibst du gar nichts:
http://vfio.blogspot.de/2014/08/vfiovga-faq.html
"Question 10"

In die Linksammlung würde ich die vfio-Mailingliste aufnehmen:
https://www.redhat.com/mailman/listinfo/vfio-users
und die Webseite des Entwicklers:
http://vfio.blogspot.de/

Ich will seit Monaten ausprobieren, die integrierte Intel-Grafik durchzureichen:
http://vfio.blogspot.de/2016/07/
und dazu ein Tutorial für Stretch schreiben ... aber ich komme nicht dazu. Gerade die zahlreichen Notebook-Besitzer dürfte das interessieren, die haben nämlich kaum ne Chance auf ne zweite GPU. Zumindest erwähnen sollte man diese Möglichkeit.

Sorry für's Durchkritsieren von oben nach unten, aber ich trag mich selber seit Jahren mit dem Gedanken, da eine allumfassende Anleitung auf Deutsch zu schreiben und bin bisher daran gescheitert, dass das Thema mit allen Wenn's und Aber's einfach zu komplex ist und sich zu schnell entwickelt hat. Ich würd mich freuen, wenn sich da etwas Brauchbares entwickelt

[fireburner]

...
Das fängt bei deiner Beschreibung von Vt-d an. Seit Skylake (2015) haben meineswissens alle Intel-Prozessoren Vt-d. Hier z.B. ein i7-6700K mit Vt-d:
https://ark.intel.com/products/88195/
Bei älteren Systemen hast du ein Flickwerk aus unterstützenden Prozessoren und unterstützenden Chipsätzen/Mainboards. Eins der Hauptprobleme der Anwender ist es herauszubekommen, ob Vt-d in ihrem System vorhanden ist, aktiviert ist und funktioniert.

Ah okay. Mir war nicht bewusst, dass neuere Intel k Prozessoren auch Vt-d unterstützen. Da ich selbst eien Ivy Bridge CPU habe, habe ich mich hauptsächlich über diese und die Haswell Prozessoren erkundigt. Das mit den Chipsätzen/MB werde ich zusammen mit dem Rest des Abschnittes versuchen noch etwas ausführlicher zu gestalten.

Erwähnenswert: Notebook-Hybridgeschichten wie Nvidia-Optimus funktionieren nicht (vonwegen zwei Grafikkarten).
Erwähnenswert: Man braucht zwei Monitore oder einen Monitor mit zwei Eingängen (zwischen denen man umschalten muss).

Guter Punkt. Werde ich ergänzen.

Ob die VM einen UEFI- oder BIOS-Boot macht, hat erst mal nichts mit der Grafikkarte zu tun. Das ist derart vereinfacht dargestellt, dass es schon falsch ist. Auch ein UEFI-Boot bootet dir problemlos deine Grafikkarte im VGA-Modus. Da hast du nur bei Intel-Grafiken das Problem, dass der Intel-VGA-Treiber des Hostes nicht mit einer im VGA-Modus gebooteten Grafikkarte des Gastes klarkommt. Wohlgemerkt "gebootet". Es ist kein Problem, den Gast mit einer virtuellen Grafikkarte als primäre Karte im VGA-Modus zu booten und die echte Karte als sekundäre Karte durchzureichen - egal ob Seabios oder OVMF.

Da meine Grafikkarte kein UEFI unterstützt und in einer Anleitung Stand, das würde nicht gehen mit UEFI Boot in der VM, habe ich dies gar nicht versucht.
Du sagst also ich kann UEFO nutzen und durch die primäre QXL Grafikkarte auch booten, wenn die eigentlich kein UEFI kann? Oder ist nicht einmal die QXL nötig?
Sobald ich das komplett verstanden habe, werde ich auch den Abschnitt anpassen.

vfio als "optional" zu bezeichnen halte ich für gewagt. pci-stub ist "deprecated" und wird nicht mehr weiterentwickelt.

Das Problem der IOMMU-Groups streifst du gar nicht.

Bei mir hat es ohne vfio Zuweisung problemlos funktioniert. Für VFIO ist ja UEFO Boot nötig, oder habe ich das missverstanden?
Daher kann ich leider zu den vfio Gruppen wenig sagen.
Welches Problem meinst du?

Dass es wichtig ist, die Grafikkarte zusammen mit der zugehörigen Soundkarte durch zu reichen, könnte etwas mehr betont werden. Ebenso, dass es wichtig ist, dass generell kein Treiber (außer vfio-pci) die Grafikkarte anfasst. Und auch eine mit Treibern belegte Soundkarte kann Probleme machen, wenn der Treiber sich nicht mehr problemlos entfernen lässt.

Ist es wirklich zwingend nötig den Soundchip durch zu reichen, auch wenn dieser nicht genutzt wird in der VM?

Das es wichtig ist, dass die Grafikkarte nicht am Host genutzt wird, habe ich ja durch ein blacklisten des Grafiktreibers erreicht.
Bei Anderen Geräten, soll dies ja weniger dramatisch sein.

Die Hinweise zur virtuellen Festplatte sind zwar schön und gut, gehören aber eigentlich nicht in den Artikel, oder? Da könnte man noch viel mehr zu sagen, inklusive der tollen Möglichkeit, mit qcow2 Snapshots und Backups anzufertigen. Und der Frage, wo man diese Dateien denn auf der Platte findet. Das wäre vielleicht einen eigenen Artikel wert.

Okay gute Idee, mal sehen ob man das erst mal integriert und eventuell später mal in einen separaten Artikel auslagert.
Bei er im Detail erläuterten Variante können ja per LVM auch Snapshots erzeugt werden.
Diese Variante habe detaillierter Beschreiben, da dies laut Benchmarks die beste IO Performance liefert (besser als ein Image File), was ja bei einer Gaming VM von Bedeutung sein könnte.
Der Fokus liegt hier natürlich generell auf Gaming, weswegen vermutlich auch die allermeisten eine Grafikkarte an ihre VM durchreichen möchten.

Die Themen "Netzwerk" und "virsh" und die XML-Dateien streifst du gar nicht. Ebenso Suspend/Reboot von Host und Guest. Die wären vermutlich auch in einem eigenen Artikel "Windows mit Qemu virtualisieren" besser aufgehoben.

Wie man ein Bridged Network erstellt könnte man sicher noch anfügen. Genauso eine Anleitung, wie man die VM per vrish und XML Datei aufsetzt.
(das habe ich mir allerdings noch nicht angesehen. Virsh und die XML Konfiguration wollte ich mir an meinem Server genauer ansehen, wenn ich mal genug Zeit habe den endlich mal Einzurichten.) Wenn du hier also deine Erfahrung beisteuern möchtest, immer gerne.

Alex Williamson rät weiterhin generell zum i440FX Chipsatz, auch bei UEFI/OVMF.

Werde ich so umformulieren.

Das "Tolle" an UEFI/OVMF ist, dass du eben ohne zusätzliche virtuelle Grafikkarte auskommst. Die VM bootet gleich über die durchgereichte Grafikkarte und ein Benutzer, dem du Monitor, Maus und Tastatur hinstellst, merkt gar nicht mehr, dass er vor einem virtuellen Windows sitzt. Das ist für den Heim-Spieler zwar zweitrangig, aber sollte vielleicht erwähnt werden, um die Unterschiede zu erläutern...

Inwiefern ist das im Bios Boot jetzt anders?

Erwähnenswert: als "zusätzlicher Soundcontroller" ist eine billige USB-Karte am unkompliziertesten. Deren Lineout kann man an den Line-in des Hostes hängen.

Genau das wollte ich als nächstes bei der VM ändern Werde ich auch anfügen.

Zum berüchtigten Code 43 Problem bei Nvidia-Grafikkarten schreibst du gar nichts:
http://vfio.blogspot.de/2014/08/vfiovga-faq.html
"Question 10"

Guter Punkt. Hier bin ich sei froh, das AMD (noch) nicht auf solche Ideen kommt. Vielleicht sollte man eher generell von Nvidia abraten? (das findet ja auch Linus)

In die Linksammlung würde ich die vfio-Mailingliste aufnehmen:
https://www.redhat.com/mailman/listinfo/vfio-users
und die Webseite des Entwicklers:
http://vfio.blogspot.de/

Danke, werde ich anfügen.

Ich will seit Monaten ausprobieren, die integrierte Intel-Grafik durchzureichen:
http://vfio.blogspot.de/2016/07/
und dazu ein Tutorial für Stretch schreiben ... aber ich komme nicht dazu. Gerade die zahlreichen Notebook-Besitzer dürfte das interessieren, die haben nämlich kaum ne Chance auf ne zweite GPU. Zumindest erwähnen sollte man diese Möglichkeit.

Sorry für's Durchkritsieren von oben nach unten, aber ich trag mich selber seit Jahren mit dem Gedanken, da eine allumfassende Anleitung auf Deutsch zu schreiben und bin bisher daran gescheitert, dass das Thema mit allen Wenn's und Aber's einfach zu komplex ist und sich zu schnell entwickelt hat. Ich würd mich freuen, wenn sich da etwas Brauchbares entwickelt

Hat es einen Grund, warum du genau die integrierte Intel Grafik durch reichen möchtest?

Wie oben schon erwähnt, darfst du dich liebend gerne in den Artikel einbringen und dein geplantes Tutorial hier einfließen lassen.
Wie schon gesagt müsste man dann sehen, wenn der Artikel zu umfangreich wird, was Sinn machen würde in einen separaten Artikel ausgelagert zu werden.

[NAB]

Ah okay. Mir war nicht bewusst, dass neuere Intel k Prozessoren auch Vt-d unterstützen. Da ich selbst eien Ivy Bridge CPU habe, habe ich mich hauptsächlich über diese und die Haswell Prozessoren erkundigt. Das mit den Chipsätzen/MB werde ich zusammen mit dem Rest des Abschnittes versuchen noch etwas ausführlicher zu gestalten.

Der Haswell 4790k kann auch vt-d:
https://ark.intel.com/de/products/80807 ... o-4_40-GHz
Ich würd's möglichst kurz zu halten versuchen, sonst redest du dir den Mund fusselig. Der hilfreichste Link dürfte dieser hier sein:
https://ark.intel.com/de/Search/Feature ... s&VTD=true
Das sind alle Intel-Prozessoren mit VT-d unterstützung. Für Chipsätze gibt's so eine Liste leider nicht. Und bei AMD fehlt mir der Durchblick, aber der Mainboardhersteller hat immer ein Wörtchen mitzureden.

Da meine Grafikkarte kein UEFI unterstützt und in einer Anleitung Stand, das würde nicht gehen mit UEFI Boot in der VM, habe ich dies gar nicht versucht.
Du sagst also ich kann UEFO nutzen und durch die primäre QXL Grafikkarte auch booten, wenn die eigentlich kein UEFI kann? Oder ist nicht einmal die QXL nötig?
Sobald ich das komplett verstanden habe, werde ich auch den Abschnitt anpassen.

Was nicht geht ist:
1) Eine Intel Onboard-Grafik haben und
2) Eine VM im BIOS-Modus mit der durchgereichten Grafikkarte als primärer Grafikkarte booten.
Alles andere geht. Also ja - du brauchst QXL, egal ob du Seabios oder OVMF benutzt.

Solange du eine QXL-Karte als primäre Karte benutzt, geht also "alles", egal in welche Kombination. Das hat die Entwickler von vfio aber massiv gestört. Die wollten die Maschinen im professionellen Umfeld einsetzen und da kannste nicht noch nen Linux-Schirm mit nem Fenster präsentieren. Und natürlich wollten sie Intel-Maschinen benutzen. Alex Williamson hat es dann mit dem VGA Arbiter Patch versucht:
http://vfio.blogspot.de/2014/08/whats-d ... ation.html
aber der wurde wegen Zuständigkeitsgerangel nicht in den Kernel aufgenommen.
Die einzige Lösung, um mit einer Intel-Grafik eine Grafikkarte als primäre Grafikkarte durchzureichen ist also OVMF. Und dazu braucht die Grafikkarte eine UEFI-Firmware. Darum liest man oft, dass das "die einzige Lösung" sei.

Bei mir hat es ohne vfio Zuweisung problemlos funktioniert.

In Wirklichkeit bindet virt-manager deine (treiberlose) Grafikkarte an den vfio-pci Treiber und reicht sie dann an die VM weiter. Das kriegst du nur nicht mit;)

Für VFIO ist ja UEFO Boot nötig, oder habe ich das missverstanden?

Ja, das hast du missverstanden. Das eine hat mit dem anderen überhaupt nichts zu tun. Du benutzt vfio so oder so (außer du nimmst ausdrücklich den veralteten pci-stub Treiber).

Daher kann ich leider zu den vfio Gruppen wenig sagen.
Welches Problem meinst du?

Ich kann das kaum noch besser ausdrücken als das Arch-Wiki:
https://wiki.archlinux.org/index.php/PC ... _are_valid
PCI-Geräte sind in Gruppen aufgeteilt. Du kannst nur eine Gruppe am Stück durchreichen. Oder du musst den ACS Override Patch installieren und gefährdest deine Systemsicherheit (was man auf einem Heim-Zocker-System durchaus riskieren könnte).

Ist es wirklich zwingend nötig den Soundchip durch zu reichen, auch wenn dieser nicht genutzt wird in der VM?

Definiere "zwingend nötig". Bei mir ist es so, dass beim Booten sämtliche Soundkarten mit einem Treiber belegt werden (intel-hda). Und wenn der KDE voll hochgefahren ist, sind diese Treiber derartig belegt, dass ich sie mit modprobe -r nicht mehr entfernen kann. Wenn ich dann die Grafikkarte alleine ohne Soundkarte durchreiche, ging das mal. Solange nicht der Treiber (also der KDE) auf dieser Soundkarte irgendwas abspielen wollte ... dann ist mir die Kiste abgeschmiert. Gut, das kann man in den Griff kriegen, aber "sicher" ist das nicht. Also hab ich den intel-hda geblacklistet, die HDMI-Soundkarte an vfio-pci gebunden und dann erst intel-hda geladen. Durchgereicht habe ich trotzdem nur die Grafikkarte - aus Faulheit - so musste ich mich nicht mit den nervigen Monitor-Lautsprechern herumärgern. Bis dann der Windows-Radeon-Treiber irgendwann nicht mehr die neuste Version installieren wollte. Der lief nur noch, wenn er auch die Soundkarte gefunden hat.

Also ... nein, "zwingend notwendig" ist es nicht. Man kann auch ohne sein Glück versuchen. Aber wenn du gerne keine unberechenbaren komischen Fehler haben möchtet, musst du alle Geräte einer Gruppe durchreichen.

(Ich frage mich hier mal wieder "Wie formuliert man das?". Erklärt man alles Wenns und Abers oder bricht man es auf das technisch korrekte "Reiche alle Geräte einer Gruppe durch!" runter?)

Bei er im Detail erläuterten Variante können ja per LVM auch Snapshots erzeugt werden.

Stimmt, kann LVM ja auch! Das sollte man vielleicht in einem Halbsatz erwähnen. Wobei man dann auch schlau genug sein muss, nicht das ganze LVM für Windows zu verbraten, sonst ist ja kein Platzt mehr für snapshots. Und der Vorteil eines Image-Files auf einer SSD ist halt, dass ich mit cp --sparse=always herrlich leicht ein Backup auf die große langsame HDD machen kann. Bei einem LVM ist das Umständlicher.

Diese Variante habe detaillierter Beschreiben, da dies laut Benchmarks die beste IO Performance liefert (besser als ein Image File), was ja bei einer Gaming VM von Bedeutung sein könnte.

Was waren das für Benchmarks? Ich habe Zweifel, dass ein LVM schneller ist als eine nackte durchgereichte Platte. Die nackte Platte hat auch den Vorteil, dass du dir das kpartx sparen kannst. Und die "beste Performance" hast du mit einem durchgereichten Sata-Controller.

Der Fokus liegt hier natürlich generell auf Gaming, weswegen vermutlich auch die allermeisten eine Grafikkarte an ihre VM durchreichen möchten.

Schwer zu sagen, was die "allermeisten" möchten. Mein Ansatz wäre jetzt wieder, alle denkbaren Einsatzmöglichkeiten abzudecken, und dann wird's wieder so lang dass jeder die Augen verdreht ...

(Klasse finde ich übrigens die Bildschirmfotos ... das hat so was von "Schaut mal, es geht wirklich!")

Wie man ein Bridged Network erstellt könnte man sicher noch anfügen.

Ich vermute, den Heimanwender interessiert, wie er Dateien zwischen Linux und Windows austauscht. Das ginge dann in Richtung Samba/Dateifreigabe. Das sollte man zumindest mal erwähnen im Sinne von "Entdecke die Möglichkeiten!". Ebenso den "Shared Folder".

Genauso eine Anleitung, wie man die VM per vrish und XML Datei aufsetzt.
(das habe ich mir allerdings noch nicht angesehen. Virsh und die XML Konfiguration wollte ich mir an meinem Server genauer ansehen, wenn ich mal genug Zeit habe den endlich mal Einzurichten.) Wenn du hier also deine Erfahrung beisteuern möchtest, immer gerne.

Tja ... da sagste was. Wie weit erklärt man das? Eine komplette VM-Definition per Hand aufzusetzen geht meiner Meinung nach viel zu weit. Aber so eine grobe Grundahnung, dass es virsh überhaupt gibt, dass man mit virsh edit manuell in die VM-Definition eingreifen kann und wie der Kram mit libvirt, Qemu und kvm zusammenhängt, kann nicht schaden. Ich benutze ja gerne virst net-start/stop, aber ich lese gerade, das geht mittlerweile auch über den virt-manager ^^

Inwiefern ist das im Bios Boot jetzt anders?

Reicht meine Erklärung oben?

Guter Punkt. Hier bin ich sei froh, das AMD (noch) nicht auf solche Ideen kommt. Vielleicht sollte man eher generell von Nvidia abraten? (das findet ja auch Linus)

Das weiß ich nicht. Als ich das damals gelesen habe, habe ich mir vor Schreck prompt eine AMD-Karte gekauft, weil ich es kommen sah, dass Nvidia weitere Schikanen einbaut um eine Nutzung per PCI-Passthrough zu verhindern. Das ist aber bisher nicht passiert. Als Alex Williamson dazu befragt wurde, meinte er, dass er keinen Grund sieht, Nvidia zu meiden - die Karten würden gut funktionieren, die Macken seien gut bekannt und umgehbar und er klang recht zuversichtlich, dass man auch für zukünftige Tricks von Nvidia ein Gegenmittel finden würde. Auf der anderen Seite haben einige AMD-Karten Macken beim Reboot des Gastes und AMD ist überhaupt nicht hilfsbereit dabei, diese Macken zu lösen.

Hat es einen Grund, warum du genau die integrierte Intel Grafik durch reichen möchtest?

Ich will die einzige Grafik im Rechner durchreichen ... und das ist bei den meisten PCs eine Intel-Grafik. Ich will einfach wissen, ob's geht. Und wie gut es geht. Immerhin muss dabei Linux die Grafik entrissen werden und an Windows übergeben werden. Vielleicht finde ich irgendeinen schmutzigen Trick, um mit einem virtuellen X-Server die User-Session zu retten, dann könnte man VirtualBox-artig Windows starten, hätte native 3D-Unterstützung und kann danach gleich in Linux weiterarbeiten.

Und gerade Laptop-User dürften sich darüber freuen ...

Wie oben schon erwähnt, darfst du dich liebend gerne in den Artikel einbringen und dein geplantes Tutorial hier einfließen lassen.
Wie schon gesagt müsste man dann sehen, wenn der Artikel zu umfangreich wird, was Sinn machen würde in einen separaten Artikel ausgelagert zu werden.

Ich hab ein Tutorial für Wheezy und eins für Jessie geschrieben:
viewtopic.php?t=140895
viewtopic.php?t=155672
Kannst ja mal durchstöbern, ob du verwertbare Informationsbrocken findest. Aber wie du siehst ... es ist halt zu lang und zu ausführlich für einen Wiki-Eintrag. Und es veraltet zu schnell für diesen Umfang.
Inzwischen geht das meiste per virt-manager "Out of the box" und den Rest deckt das Arch-Wiki sehr gut ab. Ich hatte mir dann überlegt, einfach das Arch-Wiki zu übersetzen ... das war mir dann aber auch zu blöd ...

[fireburner]

Der Haswell 4790k kann auch vt-d:
https://ark.intel.com/de/products/80807 ... o-4_40-GHz
Ich würd's möglichst kurz zu halten versuchen, sonst redest du dir den Mund fusselig. Der hilfreichste Link dürfte dieser hier sein:
https://ark.intel.com/de/Search/Feature ... s&VTD=true
Das sind alle Intel-Prozessoren mit VT-d unterstützung. Für Chipsätze gibt's so eine Liste leider nicht. Und bei AMD fehlt mir der Durchblick, aber der Mainboardhersteller hat immer ein Wörtchen mitzureden.

Den Abschnitt habe ich mal komplett überarbeitet

Was nicht geht ist:
1) Eine Intel Onboard-Grafik haben und
2) Eine VM im BIOS-Modus mit der durchgereichten Grafikkarte als primärer Grafikkarte booten.
Alles andere geht. Also ja - du brauchst QXL, egal ob du Seabios oder OVMF benutzt.

Solange du eine QXL-Karte als primäre Karte benutzt, geht also "alles", egal in welche Kombination. Das hat die Entwickler von vfio aber massiv gestört. Die wollten die Maschinen im professionellen Umfeld einsetzen und da kannste nicht noch nen Linux-Schirm mit nem Fenster präsentieren. Und natürlich wollten sie Intel-Maschinen benutzen. Alex Williamson hat es dann mit dem VGA Arbiter Patch versucht:
http://vfio.blogspot.de/2014/08/whats-d ... ation.html
aber der wurde wegen Zuständigkeitsgerangel nicht in den Kernel aufgenommen.
Die einzige Lösung, um mit einer Intel-Grafik eine Grafikkarte als primäre Grafikkarte durchzureichen ist also OVMF. Und dazu braucht die Grafikkarte eine UEFI-Firmware. Darum liest man oft, dass das "die einzige Lösung" sei.

Ich hab den UEFI BIOS Teil komplett neu geschrieben. Ich hoffe, das ist nun inhaltlich soweit richtig.

Ja, das hast du missverstanden. Das eine hat mit dem anderen überhaupt nichts zu tun. Du benutzt vfio so oder so (außer du nimmst ausdrücklich den veralteten pci-stub Treiber).
Ich kann das kaum noch besser ausdrücken als das Arch-Wiki:
https://wiki.archlinux.org/index.php/PC ... _are_valid
PCI-Geräte sind in Gruppen aufgeteilt. Du kannst nur eine Gruppe am Stück durchreichen. Oder du musst den ACS Override Patch installieren und gefährdest deine Systemsicherheit (was man auf einem Heim-Zocker-System durchaus riskieren könnte).

Ich habe VFIO auch nochmals dahingehend überarbeitet und die optional flag enfernt.

Definiere "zwingend nötig". Bei mir ist es so, dass beim Booten sämtliche Soundkarten mit einem Treiber belegt werden (intel-hda). Und wenn der KDE voll hochgefahren ist, sind diese Treiber derartig belegt, dass ich sie mit modprobe -r nicht mehr entfernen kann. Wenn ich dann die Grafikkarte alleine ohne Soundkarte durchreiche, ging das mal. Solange nicht der Treiber (also der KDE) auf dieser Soundkarte irgendwas abspielen wollte ... dann ist mir die Kiste abgeschmiert. Gut, das kann man in den Griff kriegen, aber "sicher" ist das nicht. Also hab ich den intel-hda geblacklistet, die HDMI-Soundkarte an vfio-pci gebunden und dann erst intel-hda geladen. Durchgereicht habe ich trotzdem nur die Grafikkarte - aus Faulheit - so musste ich mich nicht mit den nervigen Monitor-Lautsprechern herumärgern. Bis dann der Windows-Radeon-Treiber irgendwann nicht mehr die neuste Version installieren wollte. Der lief nur noch, wenn er auch die Soundkarte gefunden hat.

Also ... nein, "zwingend notwendig" ist es nicht. Man kann auch ohne sein Glück versuchen. Aber wenn du gerne keine unberechenbaren komischen Fehler haben möchtet, musst du alle Geräte einer Gruppe durchreichen.

(Ich frage mich hier mal wieder "Wie formuliert man das?". Erklärt man alles Wenns und Abers oder bricht man es auf das technisch korrekte "Reiche alle Geräte einer Gruppe durch!" runter?)

Ich habe versucht unter https://wiki.debianforum.de/QEMU/KVM_mi ... er_reichen darauf einzugehen, dass alle Geräte einer vfio Gruppe zugewiesen werden sollten.

Stimmt, kann LVM ja auch! Das sollte man vielleicht in einem Halbsatz erwähnen. Wobei man dann auch schlau genug sein muss, nicht das ganze LVM für Windows zu verbraten, sonst ist ja kein Platzt mehr für snapshots. Und der Vorteil eines Image-Files auf einer SSD ist halt, dass ich mit cp --sparse=always herrlich leicht ein Backup auf die große langsame HDD machen kann. Bei einem LVM ist das Umständlicher.
Was waren das für Benchmarks? Ich habe Zweifel, dass ein LVM schneller ist als eine nackte durchgereichte Platte. Die nackte Platte hat auch den Vorteil, dass du dir das kpartx sparen kannst. Und die "beste Performance" hast du mit einem durchgereichten Sata-Controller.

Ich habe qcow2 und dedizierte direkte Festplatte extra aufgeführt. Auch habe ich Snapshots erwähnt.
Details gehen vermutlich über den Zweck dieser Wiki Seite hinaus.
Laut https://www.linux-kvm.org/page/Tuning_KVM sind LVM und direkte Festplatte performanter als qcow2.

Auch Trim (https://blog.zencoffee.org/2016/05/trim ... -machines/) sollte man noch anfügen. Allerdings versuche ich immer noch herauszufinden, wie ich virsh edit mit mit Virt-Manager erstellten VMs nutzen kann.

Ich vermute, den Heimanwender interessiert, wie er Dateien zwischen Linux und Windows austauscht. Das ginge dann in Richtung Samba/Dateifreigabe. Das sollte man zumindest mal erwähnen im Sinne von "Entdecke die Möglichkeiten!". Ebenso den "Shared Folder".

Samba zu erwähnen, müsste dann aber reichen, da sonst der Artikel gesprengt wird.
Welche Funktionalität meinst du mit Shared Folder genau? "File System" unter Virt-Manager?

Tja ... da sagste was. Wie weit erklärt man das? Eine komplette VM-Definition per Hand aufzusetzen geht meiner Meinung nach viel zu weit. Aber so eine grobe Grundahnung, dass es virsh überhaupt gibt, dass man mit virsh edit manuell in die VM-Definition eingreifen kann und wie der Kram mit libvirt, Qemu und kvm zusammenhängt, kann nicht schaden. Ich benutze ja gerne virst net-start/stop, aber ich lese gerade, das geht mittlerweile auch über den virt-manager ^^

Hier habe ich erstmal den Platzhalter eingefügt.

Das weiß ich nicht. Als ich das damals gelesen habe, habe ich mir vor Schreck prompt eine AMD-Karte gekauft, weil ich es kommen sah, dass Nvidia weitere Schikanen einbaut um eine Nutzung per PCI-Passthrough zu verhindern. Das ist aber bisher nicht passiert. Als Alex Williamson dazu befragt wurde, meinte er, dass er keinen Grund sieht, Nvidia zu meiden - die Karten würden gut funktionieren, die Macken seien gut bekannt und umgehbar und er klang recht zuversichtlich, dass man auch für zukünftige Tricks von Nvidia ein Gegenmittel finden würde. Auf der anderen Seite haben einige AMD-Karten Macken beim Reboot des Gastes und AMD ist überhaupt nicht hilfsbereit dabei, diese Macken zu lösen.

Code 43 ist angefügt. Allerdings fehlt auch hier der Verweis auf virsh edit.

Ich will die einzige Grafik im Rechner durchreichen ... und das ist bei den meisten PCs eine Intel-Grafik. Ich will einfach wissen, ob's geht. Und wie gut es geht. Immerhin muss dabei Linux die Grafik entrissen werden und an Windows übergeben werden. Vielleicht finde ich irgendeinen schmutzigen Trick, um mit einem virtuellen X-Server die User-Session zu retten, dann könnte man VirtualBox-artig Windows starten, hätte native 3D-Unterstützung und kann danach gleich in Linux weiterarbeiten.

Und gerade Laptop-User dürften sich darüber freuen ...

Das wäre allerdings sehr interessant, wenn das klappen würde.

Ich hab ein Tutorial für Wheezy und eins für Jessie geschrieben:
viewtopic.php?t=140895
viewtopic.php?t=155672
Kannst ja mal durchstöbern, ob du verwertbare Informationsbrocken findest. Aber wie du siehst ... es ist halt zu lang und zu ausführlich für einen Wiki-Eintrag. Und es veraltet zu schnell für diesen Umfang.
Inzwischen geht das meiste per virt-manager "Out of the box" und den Rest deckt das Arch-Wiki sehr gut ab. Ich hatte mir dann überlegt, einfach das Arch-Wiki zu übersetzen ... das war mir dann aber auch zu blöd ...

Bin leider noch nicht zum Lesen gekommen.

[NAB]

Ich bin den Artikel noch mal durchgegangen:

Typo: Minitor

Peripherie
Wenn nur die weitergereichte Grafikkarte innerhalb der VM genutzt wird, wird ein zweites Set an Tastatur und Maus benötigt.

Das stimmt nicht so ganz. Die aktuelle Methode, um Maus und Tastatur mit nur einer echten Grafikkarte durchzureichen, nennt sich "evdev passthrough":
https://www.reddit.com/r/VFIO/comments/ ... _to_share/
und reagiert wohl auf das Drücken beider Strg-Tasten zum Umschalten:
https://forum.level1techs.com/t/solved- ... est/122014
Ich kenne die Methode allerdings auch nur theoretisch, weil meine Grafikkarte keine UEFI-Firmware hat und ich daher eine zusätzliche QXL-Grafik nutze - damit klappt das Durchreichen der Tastatur mit Alt+Strg prima, nur die Maus hakt und verabschiedet sich manchmal. "evdev passthrough" scheint für Tastaturen aber auch prima zu funktionieren, nur bei Mäusen gibt es wieder Probleme. Somit halte ich eine eigene Maus für die VM für eine sehr gute Idee (wenn auch nicht zwingend) aber die zweite Tastatur kann man sich wohl in jedem Fall sparen. Wobei ... wirklich in jedem Fall? Ich weiß nicht, wie es mit Jessie steht ...

Hier:
https://medium.com/@dubistkomisch/gamin ... c395dde5c2
reißt er übrigens noch eine zusätzliche unheimlich umständliche Methode per ssh an.
(Auch sonst ein interessantes Tutorial)

Linux Kernel

Meinst du, der Hinweis auf CONFIG_VFIO_PCI_VGA ist noch zeitgemäß? Seit Jessie ist er hinfällig und wer mit Wheezy noch VGA-Passthrough machen will, den würde ich eh für etwas schrullig halten.

für eine AMD Karte: blacklist radeon oder blacklist amdgpu

Warum "oder"? Kann man nicht einfach beide Blacklisten? Sollte man das nicht sogar tun? Die Zuständigkeitsbereiche der beiden Treiber überschneiden sich teilweise ... ich vermute, wenn man amdgpu blacklistet, dann springt in solchen Fällen radeon ein.

Wenn man zwei AMD oder Nvida Karten hat und nur eine davon an die VM weitergeben möchte, während man die andere am Host nutzen möchte, kann das Blacklisting nicht über den Grafikkarten Treiber erfolgen.

Eh ... "kann" man schon. Dann wird die erste Karte im VESA-Modus gebootet, man könnte die zweite an den vfio-Treiber binden und dann den richtigen Treiber für die erste Karte laden. Fragt sich nur, ob man das erwähnt oder nicht lieber dezent verschweigt. Auf der anderen Seite ... was du hier:
https://wiki.debian.org/VGAPassthrough# ... ssociation
verlinkt hast, ist irgendwie was anderes. Der Text beschreibt zwar das richtige Problem, schließt aber mit einem merkwürdigen "(not describe here)". Im Folgenden wird dann eine HDMI-Soundkarte von ihrem vorhandenen Treiber befreit (was nicht immer klappt) und an den vfio-Treiber gebunden.
Und dein zweiter Link ins Arch-Wiki:
https://wiki.archlinux.org/index.php/PC ... _host_GPUs
ist sehr Arch-spezifisch, das lässt sich so nicht auf Debian übertragen. Ich verstehe das Script zwar nicht komplett, aber das sieht mir so aus, als ob sie sämtliche Grafiktreiber entfernen, was einem Blacklisten gleichkäme, die richtige Grafikkarte an den vfio-Treiber binden ... und was mit der anderen Grafikkarte passiert, wird offengelassen. Das sieht mir nach einer eleganteren Methode aus, wie von mir beschrieben alle Grafiktreiber zu blacklisten, die "richtige" Karte an den vfio-Treiber zu binden und dann den Treiber für die andere Karte zu laden. Aber ich bin hier auch nur am theoretisieren - praktische Erfahrung mit zwei identischen Karten habe ich keine.

Um das erweiterte Power Management der Grafikkarte nutzen zu können, muss VFIO genutzt werden.

Ich weiß, das steht so im Arch-Wiki, ist aber irgendwie sinnlose Information. Der vfio-Treiber wurde damals entwickelt, weil der pci-stub Treiber einfach gar nichts konnte außer die Karte zu belegen - er war nur ein Dummy. Der vfio-Treiber hat dann ein paar PCI-spezifische Sachen gelernt, insbesondere die Karten zu resetten, was einem einen Reboot gespart hat. Gut, das könnte man auch als "Power Management" bezeichnen, aber unter dem Strich läuft es darauf hinaus, dass der pci-stub Treiber einfach tot ist und in vfio sämtliche Entwicklungs- und Testarbeit hineinfließt.

Hinweis: Wenn der Grafiktreiber geblacklistet wird, kann dies entfallen.

Das klingt für den Leser nun etwas wirr ... was soll er denn nun machen? Den Treiber blacklisten oder /etc/modprobe.d/vfio.conf erstellen? Nein, ich habe darauf auch keine perfekte Antwort. Aus meiner Sicht ist das Ziel der Übung, dafür zu sorgen, dass keins der durchzureichenden Geräte von einem anderen Treiber angefasst wird und möglichst früh an den vfio-Treiber gebunden wird, damit nicht noch irgendein blöder Automatismus dazwischenschießt und das Gerät doch noch mit einem Treiber belegt. Wenn kein Automatismus greift, dann reicht natürlich auch nur einfaches Blacklisten. Und wenn man Glück hat, dann klappt auch ein unbind und man kann einen vorhandenen Treiber wieder entfernen und durch den vfio-Treiber ersetzen. Wenn man richtig viel Glück hat und eine kooperative Grafikkarte und einen kooperativen Treiber, dann muss man also gar nichts machen und der virt-manager entsorgt einen vorhandenen Treiber und reicht das Ding an die VM durch. Wenn dabei aber was schief geht, dann geht die Fehlersuche los ...

Öhm ... wie fasst man das nun möglichst knackig ohne viele wenns und abers zusammen?

Um eine separate SSD mit der besten Performance zu nutzen muss man diese als LVM konfigurieren:

Ich glaube, das hast du hier:
https://www.linux-kvm.org/page/Tuning_KVM
etwas falsch betont gelesen. Die Betonung liegt auf "raw partition" bzw. "raw volumes" - damit erreichst du die höchste Performance (logisch). Der Autor denkt sich nur, dass ein LVM eine unheimlich praktische Sache ist, um mehrere "raw partitions" zu verwalten. LVM ist hier als Vorteil in der Verwaltung gedacht, nicht als Vorteil in der Geschwindigkeit. LVM dürfte genau so schnell sein wie eine "raw partition". Nun bin ich nicht so der LVM-Fan, darum sieht's für mich so aus, als ob du LVM wie sauer Bier anpreist, vor allen anderen Alternativen

Code: Alles auswählen

 Festplatten Einstellungen
Bei den Einstellungen der Festplatte sollte man für die beste Performance bei allen drei Varianten SCSI wählen.

Stimmt zwar ... aber damit hatte ich bei einem der berüchtigten Win-10-Versionsupgrades üblen Ärger. Seitdem läuft die Systemplatte bei mir wieder als "sata". Fragt sich, ob man sowas erwähnt, oder das leidgeplagte Windows-Opfer selber drauf kommen lässt.

Allerdings versuche ich immer noch herauszufinden, wie ich virsh edit mit mit Virt-Manager erstellten VMs nutzen kann.

Sorry, ich editiere die VMs immer als root, da hatte ich völlig vergessen, dass man als normaler User ein qemu:///system angeben muss. Zum Glück hast du es ja inzwischen selber herausbekommen

Ebenso den "Shared Folder".

Welche Funktionalität meinst du mit Shared Folder genau? "File System" unter Virt-Manager?

Schon gut, vergiss es. Ich hatte vor Jahren (?) gelesen, dass ein Windows-Treiber in Arbeit ist. Ich hab grad gefunden, was daraus geworden ist:
https://github.com/virtio-win/kvm-guest ... issues/126
gar nix.

Mir ist grad noch eingefallen, was meiner Meinung nach noch fehlt: der kvm-Parameter "ignore_msrs=1".
Diese MSRs sind spezielle CPU-Register (Model Specific Registers), die eigentlich allesamt von Qemu abgefangen und emuliert werden sollten. Allerdings tut Qemu das nicht für alle MSRs und bittet stattdessen darum, dass man einen Bug-Report aufmacht, wenn ein Programm wirklich noch einen nicht-emulierten MSR benutzt. Wenn ein Programm einen nicht-emulierten MSR benutzt, gibt Qemu einen Fehler zurück und das Programm verabschiedet sich nicht selten. Als ich damals mit dem VGA-Passthrough angefangen habe, ist das noch derartig häufig passiert, dass es quasi Pflicht war, den Parameter "ignore_msrs=1" zu benutzen - dann lügt Qemu und gibt beim Zugriff auf den MSR einfach "Null" zurück statt einer Fehlermeldung. In letzter Zeit höre ich davon aber immer seltener. Hier:
https://heiko-sieger.info/running-windo ... assthrough
erwähnt aber jemand recht aktuell, dass er "ignore_msrs=1" noch braucht, für Passmark.
(übrigens auch ein feines und erschlagendes Tutorial)
Du bist über das MSR-Problem bisher noch gar nicht gestolpert? Und - würdest du es merken? Dir schmiert nämlich erst mal einfach unter Windows irgendein Programm ab, und du müsstest dann auf dem Host im dmesg nachgucken und da eine Meldung über "MSR" finden.

Und bevor ich wieder so klinge als ob ich nur nörgele: Vielen Dank für deine Mühe!

[fireburner]

Ich habe mir endlich mal wieder die Zeit genommen den Artikel etwas zu überarbeiten und deine Kritik mit einzubeziehen, @NAB

Ich habe den Abschnitt mit CONFIG_VFIO_PCI_VGA komplett entfernt. Dafür habe ich neue Abschnitte zu msrs, nested virtualization und dem Wechsel von BIOS zu UEFI hinzugefügt, sowie Kleinigkeiten angepasst.

Den Abschnitt zu den virtuellen Festplatten habe ich auch neu strukturiert und die Version mit LVM an die dritte Stelle verbannt.

Was jetzt noch fehlt wäre die Erstellung einer Network Bridge per GUI. Da ich aktuell immer den NAT Netzwerktyp genutzt hatte, muss ich mir das erst mal selbst ansehen.
Hast du das eventuell schon umgesetzt?

Das mit evdev hör sich spannend an. das werde ich mir wohl auch mal ansehen müssen.

Stimmt zwar ... aber damit hatte ich bei einem der berüchtigten Win-10-Versionsupgrades üblen Ärger. Seitdem läuft die Systemplatte bei mir wieder als "sata". Fragt sich, ob man sowas erwähnt, oder das leidgeplagte Windows-Opfer selber drauf kommen lässt.

Dies konnte ich beim Update von 1803 auf 1809 nicht beobachten. Scheint MS also gefixt zu haben.

[fireburner]

Hallo zusammen,

ich hab mal wieder einiges überarbeitet/angepasst. Der Einrichtungsabschnitt sollte nun etwas deutlicher sein und zudem habe ich das neue Kernel Modul zur mitigation des AMD Reset Bugs getestet und erwähnt.

Wenn jemand Fehler findet oder Verbesserungsvorschläge hat, bitte einfach hier melden.
Danke.