Problem bei PCI(e) Passthrough nach Upgrade mit Microsemi HBA 1100

[VMTester]

Hallo zusammen,

Nach einem Upgrade auf den aktuellen Kernel funktioniert der PCI(e) Passthrough meiner Microsemi HBA 1100 nicht mehr.

Unter Kernel pve-kernel-5.3.18-2-pve kommt folgendes:
lsmod | grep vfio

vfio_pci               49152  2
vfio_virqfd            16384  1 vfio_pci
irqbypass              16384  42 vfio_pci,kvm
vfio_iommu_type1       28672  2
vfio                   32768  8 vfio_iommu_type1,vfio_pci

dmesg |grep -e DMAR -e IOMMU

[    0.015682] ACPI: DMAR 0x0000000079B02098 000148 (v01 ALASKA A M I    00000001 INTL 20091013)
[    0.904279] DMAR: IOMMU enabled
[    1.761542] DMAR: Host address width 46
[    1.761544] DMAR: DRHD base: 0x000000fbffc000 flags: 0x0
[    1.761550] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap 8d2078c106f0466 ecap f020de
[    1.761551] DMAR: DRHD base: 0x000000c7ffc000 flags: 0x1
[    1.761555] DMAR: dmar1: reg_base_addr c7ffc000 ver 1:0 cap 8d2078c106f0466 ecap f020de
[    1.761557] DMAR: RMRR base: 0x0000007bc18000 end: 0x0000007bc27fff
[    1.761558] DMAR: ATSR flags: 0x0
[    1.761559] DMAR: RHSA base: 0x000000c7ffc000 proximity domain: 0x0
[    1.761560] DMAR: RHSA base: 0x000000fbffc000 proximity domain: 0x1
[    1.761562] DMAR-IR: IOAPIC id 3 under DRHD base  0xfbffc000 IOMMU 0
[    1.761563] DMAR-IR: IOAPIC id 1 under DRHD base  0xc7ffc000 IOMMU 1
[    1.761564] DMAR-IR: IOAPIC id 2 under DRHD base  0xc7ffc000 IOMMU 1
[    1.761565] DMAR-IR: HPET id 0 under DRHD base 0xc7ffc000
[    1.761566] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out bit.
[    1.761567] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the BIOS setting.
[    1.762293] DMAR-IR: Enabled IRQ remapping in xapic mode
[    3.245304] DMAR: dmar0: Using Queued invalidation
[    3.245317] DMAR: dmar1: Using Queued invalidation
[    3.293887] DMAR: Intel(R) Virtualization Technology for Directed I/O

Ich schätze mal dass die Microsemi-controller nicht die erste Wahl für so ein Konzept sind...

Wer hat eine funktionierende Lösung parat?

 

[gmed]

Gibt es einen speziellen Grund, den aktuellen Kernel zu nutzen?
Falls nicht, bleib beim funktionierenden?!

Ist denn der Controller weiterhin in der Blacklist?
Evtl. bringt der neue Kernel ein anderes Modul für den Controller mit und der Host will den deswegen nicht freigeben?

Was sagt lsmod und lspci?

 

[VMTester]

Hallo gmed,

erstmal Danke für deine Antwort!

Es gibt für mich mehrere Gründe nicht bei einem alten Kernel zu verbleiben.
Z.B. Module, die in neuerem Kernel integriert werden, Systemstabilität bei stark verltetem Kernel,...
Für mich persönlich wichtig:
Ich möchte bei Updates kein dauerndes rumgefrickel.

Allgemein:
Das ist nicht das einzige Problem das mit dem Controller aufgetreten ist:
Massive Fehlermeldungen unter BSD, ZFS, SMART, ... - Die Liste ist lang und die dauernden Bastelarbeiten zum korrigieren derselben ist nervig.

Ich habe heute meinen Broadcom-HBA-Controller erhalten und siehe da:
Alle bisherigen Probleme sind auf einen Schlag weg!
Nebenbei ist der Energiebedarf gesunken und der Bootvorgang um ca. 2 Minuten kürzer.

Falls jemand vor dem Kauf eines Controllers steht:
https://www.freebsd.org/releases/12.0R/hardware/
Bei mir war es aus der Liste:
Broadcom Ltd./Avago Tech (LSI) SAS
Broadcom HBA 9400 - Reihe

Nach allem was ich in den letzten Wochen gelesen habe gibt es mit den LSI/Avago/Broadcom - Controllern am wenigsten Probleme.
Und was unter FreeBSD läuft, das whoppt Linux höchstwahrscheinlich auch, da umfangreicherer Hardware-Support.