PCI[e]-Passthrough: On-Board-NIC und PCIe-NIC in derselben IOMMU-Gruppe - was tun?

[clavis]

Hallo,

ich habe mir ein Mainboard mit einem Celeron-SoC besorgt (Asrock J3355M) und wollte damit eigentlich Opnsense auf einer VM betreiben. Hierzu plante ich, eine PCIe-Netzwerkkarte direkt an diese VM durchzureichen. Bedauerlicherweise befinden sich sowohl die On-Board-Netzwerkkarte als auch die PCIe-Netzwerkkarte in derselben IOMMU-Group, so dass beim Start der VM die Netzwerkverbindung abbricht.

PCIe-Slots wechseln führt leider nicht zum Erfolg, die PCIe-NIC kommt immer wieder in dieselbe Gruppe. Auch das Hinzufügen von "pcie_acs_override=downstream" oder "pcie_acs_override=downstream,multifunction" in /etc/default/grub hat absolut gar nichts bewirkt. Ich fürchte, softwareseitig komme ich hier nicht weiter.

Könnte es helfen, eine Netzwerkkarte eines anderen Herstellers zu besorgen oder würde jede Netzwerkkarte in derselben Gruppe landen wie die bisherigen zwei? Wenn auch das nicht hilft, gibt es andere Möglichkeiten die zum Erfolg führen könnten? Oder kann man doch softwareseitig noch etwas tun? Ich habe mir dieses Setup extra besorgt um neben der Opnsense noch weitere kleine Dienste mit PVE zu betreiben, es wäre wirklich sehr bedauerlich, wenn es jetzt an sowas scheitern würde.

Details:
Mainboard: Asrock J3355M (SoC Celeron J3355, unterstützt sowohl Vt-x als auch Vt-d)
Onboard-NIC: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
PCIe-NIC: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) -->(TP-Link TG-3468)
Proxmox 7.0-11

 

[fluxX04]

Hi,

du könntest ein BIOS update versuchen, wenn eins verfügbar ist.
Die Aufteilung der IOMMU-Gruppen werden vom Mainboard und dem BIOS bestimmt, daher wird wohl auch keine andere Netzwerkkarte helfen.

Greetz

 

[Falk R.]

Ich habe bei mir mal geschaut, alles was vom Chipsatz gleich ist, wird automatisch gruppiert. Wenn du eine andere Netzwerkkarte zum probieren hast, dann tausch mal.

 

[clavis]

Die Aufteilung der IOMMU-Gruppen werden vom Mainboard und dem BIOS bestimmt, daher wird wohl auch keine andere Netzwerkkarte helfen.

Da ist denke ich die Frage interessant, nach welchem Schema dies passiert. Ordnet das Board Geräte nach ihrer allgemeinen Funktion zu (Netzwerkkarten immer in Gruppe X), oder nach Interface (alles auf den PCIe-Slots 1-3 geht in Gruppe X) oder geschieht das, wie es SkyDivers Beitrag vermuten lässt, eher nach Chipsatz (RTL-Chipsatz immer in Gruppe X) des Erweiterungsgerätes? Hat da jemand mal Erfahrungen gesammelt?

Erster und zweiter Fall wären schlecht, der dritte Fall ließe allerdings noch Hoffnung aufkommen. Leider habe ich gerade keine andere Karte da, aber ich werde mal sehen, ob ich eine zB mit Intel-Chipsatz besorgen kann.

 

[Falk R.]

Ich habe onboard 2,5 GBit und 1 GBit, die sind nicht gruppiert, aber meine 10GBit sind es.
Realtek/Intel und 10GBit alle Broadcom.

 

[clavis]

Ich habe es gestern mit einer Intel-Karte probiert, die landet leider auch in derselben Gruppe. Außerdem habe ich eine alte PCIe-Radeon gefunden um mal nachzuschauen, in welcher Gruppe diese zugeordnet wird. Spoiler: auch in diese Gruppe. Weiterhin habe ich auch testweise mal den nicht benötgiten Soundchip im BIOS deaktiviert - jetzt sind alle PCIe-Geräte in IOMMU-Gruppe 4 statt 5. Auch ein paar Kombinationen mit den beteiligten Realtek, Intel und der Graka haben keine neuen Erkenntnisse gebracht.

Ziemlich ernüchternd. Ich habe leider keine weitere Hardware zum Verifizieren, aber es scheint so zu sein, dass "Fall 2" eintritt und einfach alle per PCIe angeschlossenen Geräte in derselben Gruppe landen. Wobei ich mich dann schon frage, was die vt-d Funktion der CPU wert ist, wenn die Technik so gestaltet ist, dass sie nicht nutzbar ist.

Heißt für mich wohl, dass ich meine Planungen in die Tonne treten kann und eine Menge Geld umsonst ausgegeben habe.

BTW @fluxX04 : Das BIOS ist leider bereits auf dem aktuellsten Stand.

 

[Falk R.]

Hi, wenn das bei deinem Board wirklich so ist, dann ist das ja echt unbrauchbar. Das muss dann aber an der CPU/Chipsatz liegen. Bei meinem AMD habe ich zum probieren auch schon einige verschiedene Komponenten durchgereicht. Daher glaube ich nicht, dass es ein Softwarefehler ist.
Nutzt du eigentlich EFI oder BIOS Boot?

 

[clavis]

Das vermute ich halt auch, deswegen bin ich auch eher pessimistisch was eine eine Lösung betrifft. Ich werde mir jetzt etwas komplett neues überlegen müssen. Ich könnte das ganze Procedere höchstens noch mit einem USB-LAN-Adapter probieren - aber dann halt mit Bauchschmerzen.

Umtauschen möchte ich das Board auch nicht, erstens sind solche Dinger derzeit extrem schwer zu bekommen, und woher soll ich zweitens wissen, dass ein anderes Board in dieser Klasse nicht genau dieselben Probleme bereitet? Die alleinige Unterstützung von Vt-d ist ja offensichtlich wertlos. Die anderen Projekte, die ich damit umsetzen wollte, funktionieren ja auch. OPNsense wäre halt nur der wichtigste dieser Dienste. OPNsense aber nativ zu installieren wäre für meine Zwecke ziemlicher Overkill. Dann müsste ich mir auch noch ein zweites solches Board für die restlichen Dienste besorgen, und da eine meiner obersten Prioritäten Stromersparnis ist (deswegen auch das SoC-Board) ist das egentlich ziemlich ausgeschlossen.

Ich nutzte BIOS-Boot. Spielt das eine Rolle? Ich habe mal EFI getestet und festgestellt, dass die Latenzen auf einmal extrem hoch waren, bis zu 700ms im internen (!) Netz. Keine Ahnung wieso, mit BIOS war auch wieder alles im normalen Bereich <1ms. Ansonsten habe ich allerdings keinen Unterschied festgestellt.

 

[Falk R.]

Hi, ich nutze nur noch UEFI. Wenn du so hohe Latenzen hattest, klingt das ja eher nach Firmware/Treiber Probleme wenn sonst alles funktioniert. Wenn du noch am Testen bist, kannst du noch mal mit UEFI installieren und gucken ob das durchreichen dann geht? Die Latenzen bekommen wir dann auch schon weg.