Fedora PCI-Passthrough

Guten Morgen zusammen,

ich habe auf meinem Fedora 24 Laptop PCI-Passthough für KVM mit aktiviert.
Hierzu habe ich folgenden Eintrag in die Boot-Options hinzugefügt: intel_iommu=on

Zuerst das gute: Es funktioniert, ich kann z.B. den PCI WLAN Chip an eine VM weiterleiten.
Das Problem ist, das sich das System mit aktiviertem "intel_iommu=on" jedesmal in wenigen Minuten komplett aufhängt, unabhängig davon ob KVM genutzt wird.

Hat jemand einen Rat?

SysInfo:
Fedora 24, Gnome3, Kernel 4.7 latest, x64, vt-d wird unterstützt

"Fedora 24 Laptop"

sehr aussagekräftig

Kann man den Laptop irgendwo in dem Zustand von der Stange kaufen ?

Bitte nicht mit Hardware Infos sparen !

Laptop ist Laptop wo soll da der Unterschied sein? Es ist kein I-Mac sondern ein ganz normaler Laptop.

Sry, hast natürlich Recht, das waren etwas zu wenig Hardware Informationen.

Hier ein wenig genauere Informationen:
i5-5200U
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 61
model name : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping : 4
microcode : 0x24
cpu MHz : 2200.537
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 20
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt dtherm ida arat pln pts
bugs :
bogomips : 4400.06
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 61
model name : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping : 4
microcode : 0x24
cpu MHz : 2316.284
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 20
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt dtherm ida arat pln pts
bugs :
bogomips : 4404.21
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 61
model name : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping : 4
microcode : 0x24
cpu MHz : 2200.134
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 20
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt dtherm ida arat pln pts
bugs :
bogomips : 4406.27
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 61
model name : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping : 4
microcode : 0x24
cpu MHz : 2200.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 20
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt dtherm ida arat pln pts
bugs :
bogomips : 4404.44
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual

Mainboard:
product: ZORO_BH
vendor: Acer
physical id: 0
version: Type2 - A01 Board Version


PCI-Geräte
00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03)
00:16.0 Communication controller: Intel Corporation Wildcat Point-LP MEI Controller #1 (rev 03)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #1 (rev e3)
00:1c.2 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #3 (rev e3)
00:1c.3 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #4 (rev e3)
00:1d.0 USB controller: Intel Corporation Wildcat Point-LP USB EHCI Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation Wildcat Point-LP LPC Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation Wildcat Point-LP SATA Controller [AHCI Mode] (rev 03)
00:1f.3 SMBus: Intel Corporation Wildcat Point-LP SMBus Controller (rev 03)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
03:00.0 Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter (rev 30)

Muss nicht vt-d und vt-x. dabei mitspielen beim durch reichen? Und muss man nicht das Gerät sogar Blacklisten was man durch reicht? Ich meine da etwas im Kopf zu haben.

Meiner Erfahrung nach ist das Blacklisten nur beim Passthrough von Geräten wie einer Grafikkarte notwendig.

Beim Passthrough an den Gast wird das Gerät vom Host schlagartig getrennt. Nutzt dieser gerade die Grafikkarte stützt logischerweise alles ab. Deshalb wird die Grafikkarte geblacklistet damit der Host den Internen Grafikchip nutzt, dann kann die Graka problemlos weitergeleitet werden.

Bei PCI Geräten wie z.B. einer WLAN Karte ist das allerdings nicht notwendig. Außer dass der Host die WLAN Verbindung verliert passiert dann nicht viel.

Bei PCI Geräten wie z.B. einer WLAN Karte ist das allerdings nicht notwendig. Außer dass der Host die WLAN Verbindung verliert passiert dann nicht viel.

Zum Vergrößern anklicken....

Muss dafür nicht PCI Hotplug aktiv sein?
Mindestens der Kernel muss das hotplugging des PCI Gerätes unterstützen, sonst versucht früher oder später ein modul evtl. auf die nicht mehr vorhandene Hardware zuzugreifen und das wird dann zum Absturz führen.

Wenn der Absturz nicht sofort beim Durchreichen erfolgt, dann spricht vieles dafür, dass z.B. ein dhcpclient für die nicht mehr vorhandene hardware eine IP Adresse anfragen möchte etc.

Das Entfernen des PCI Gerätes wird dem Host nämlich nur richtig gemeldet, wenn PCI Hotplug aktiv ist.

Hey Fallaxia,

du hast vollkommen Recht, dafür gibt es ein extra Kernel Modul mit dem Namen "pciehp". Dieses wird allerdings komfortable von QEMU verwaltet, sodass man sich nicht besonders darum kümmern muss. Der PCI Hotplug funktioniert hervorragend, das Hostsystem erkennt , dass das jeweilige Gerät entfernt wurde und nach dem beenden der VM steht es dem Host direkt wieder zu Verfügung.

Das Problem mit dem Freeze tritt aber auch auf wenn KVM (PCI-Passthrough) gar nicht genutzt wird, teilweise schon auf dem Login Screen. Daher gehe ich stark davon aus, dass es irgendwie an der Kernel Option "intel_iommu=on" liegt.

unterstützt Dein Host denn IRQ Remapping vollständig?

teste es mal mit


Das Egebnis sollte etwa so aussehen:


Wichtig ist, dass der Teil hinter "ecap" am Ende eines der nachfolgenden Zeichen hat:

8, 9, a, b, c, d, e, f



Die Erklärung dazu findest Du hier:

https://pve.proxmox.com/wiki/Pci_passthrough

Damit kannst Du sicherstellen, dass der Remapping Support auch von Deiner Hardware vollständig unterstützt wird, was keinesfalls bei Notebooks die Regel sein dürfte, sondern eher Glückssache, da es nicht nur von der CPU abhängt.

Mmmh, danke ein sehr guter Hinweis. Ich bekomme allerdings folgende Ausgabe:

[ 0.041130] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap 1c0000c40660462 ecap 7e1ff0505e
[ 0.041135] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap d2008c20660462 ecap f010da


Auch das alternative Testscript zeigt keine Fehler an. Scheine also Glück gehabt und Remapping Support zu haben.
Trotzdem immer gut zu wissen.

Hat noch jemand eine Idee? Auf dem 4.8 Kernel dasselbe Problem :/

https://bbs.archlinux.org/viewtopic.php?pid=1270712#p1270712
Kaputte IVRS-,DMAR, ACPI-Tabellen?

Wenn das nach Minuten passiert, dann vielleicht die Meldungen über seriell auf anderen Rechner ausgeben?
Hatte ich bei Xen-Pci-Passthrough gemacht.