SR-IOV - Intel Arc Pro B50 - Hohe 3D Auslastung, aber stockender Desktop

D

Daniel [Karl_Pedross]

New Member
Sep 14, 2026
7
0
1
Hallo zusammen,

Seit kurzem haben wir Proxmox 9.2 auf einem DL385 Gen 10 Plus laufen.
Ziel dieses Servers ist unter anderem Terminalserver Windows 2022 mit GPU auszuführen.
Jetzt haben wir aber bemerkt, dass bereits ein einzelner Benutzer in der Lage ist mit etwas so trivialem wie scrollen in einer text-PDF die Grafikkartenauslastung auf 100% zu treiben. Die Performance ist dann entsprechend für alle Benutzer auf diesem Server entsprechend schlecht.

Dieser Server ist mit einer Intel Arc Pro B50 ausgestattet welche mittels SR-IOV an die VM durchgereicht wird.
Aktuell wird die GPU in zwei virtuelle Instanzen aufgeteilt, es wird jedoch nur eine Instanz genutzt.

Was ich bisher herausfinden konnte:
- Die Grafikkartenauslastung scheint rein vom Prozess WUDFHost zu kommen(screenshot unten).
- Die übermäßige Auslastung der 3D Engine bei gleichzeitiger 0% Nutzung der restlichen Grafikkartenmodule deutet auf ein Problem bei der Kommunikation zwischen VM und Grafikkarte hin.
- Es gab in den letzten zwei Wochen auch 2 Bluescreen "KERNEL SECURITY CHECK FAILURE" welche laut Journalctl mit einem reset der virtuellen Grafikkarte korrelieren
Die Fehlermeldungen im Log waren: kernel: vfio-pci 0000:05:00.2: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0054 address=0x182e0de82000 flags=0x>
und kernel: vfio-pci 0000:05:00.2: resetting


Hat jemand von euch eine Intel GPU mittels SR-IOV korrekt zum laufen bekommen?
Welche Schritte könnt Ihr mir empfehlen um das Problem zu lösen?

Vielen Dank für eure Hilfe

1789541285545.png
1789541308138.png
1789541595027.png
 
Ich hab hier so eine Karte liegen und auch schon ein paar rudimentäre Tests damit gemacht.
Wenn du aktuell nur die "halbe" Karte nutzt würde ich erst mal vorschlagen zum Test die Karte nicht aufzuteilen und als ganzes durch zu reichen.
Damit könnte man einfach mal testen ob es vielleicht ein Treiber Problem ist.
 
Das x-vga=1 an der VF würd ich als erstes rausnehmen. Das ist für klassisches Primär-Passthrough mit Legacy-VGA gedacht, eine SR-IOV-VF hat sowas gar nicht, und mit OVMF brauchst du es ohnehin nicht. Kann gut sein dass da ein Teil der Resets herkommt.

Die IO_PAGE_FAULTs und das resetting sind sowieso das eigentliche Thema, die 100% auf der 3D-Engine sind eher Folge als Ursache. Welcher Kernel läuft bei dir (uname -r) und wie legst du die VFs an, über sriov_numvfs am xe-Treiber oder per DKMS-Modul? Da hat sich neulich viel getan und B50-SR-IOV ist noch ziemlich frisch. Firmware/BIOS vom DL385 auch mal auf aktuellen Stand prüfen, IOMMU-Page-Faults auf EPYC kommen erstaunlich oft aus dem Firmware-Stand und nicht aus dem Gast.

Zum WUDFHost: das ist der Indirect-Display-Treiber von RDP, die Last kommt also aus dem Session-Composing/Encoding, nicht vom PDF-Viewer. Auffällig finde ich dass im Taskmanager gar keine Video-Encode-Engine auftaucht, nur Decode und Processing. Wenn die VF kein Encode rausreicht, läuft der komplette RDP-Pfad über 3D plus CPU, und dann reicht schon Scrollen aus. Spiel mal per GPO mit Use hardware graphics adapters for all Remote Desktop Services sessions und AVC444 (an/aus), das verschiebt die Last spürbar. Und wenn eh nur eine Instanz genutzt wird, würd ich die VF-Anzahl auf 1 stellen.
 
  • Like
Reactions: Sim0n
Bu66as said:
x-vga=1

Welcher Kernel läuft bei dir (uname -r) und wie legst du die VFs an. Firmware/BIOS vom DL385 auch mal auf aktuellen Stand prüfen, IOMMU-Page-Faults auf EPYC kommen erstaunlich oft aus dem Firmware-Stand und nicht aus dem Gast.

Spiel mal per GPO mit Use hardware graphics adapters for all Remote Desktop Services sessions und AVC444 (an/aus), das verschiebt die Last spürbar. Und wenn eh nur eine Instanz genutzt wird, würd ich die VF-Anzahl auf 1 stellen.
Click to expand...

x-vga ist jetzt deaktiviert, am Verhalten ändert dies jedoch nichts.
Kernel ist 7.0.14-12-pve.

Die VFs habe ich über sriov_numvfs angelegt

Firmware vom Server müsste recht aktuell sein: System ROM: A42 v3.92 (11/27/2025). Gerade lädt die HP Seite nicht ich würde später nochmal checken ob es etwas aktuelleres gibt.

Bezüglich der GPOs:
Use hardware graphics auf "disabled" bewirkt, dass der WUDFHost Prozess keine Grafikleistung verbraucht, wahrscheinlich weil die Benutzersitzung die Grafikkarte überhaupt nicht nutzt. Bei allen weiteren Tests war diese GPO deswegen auf "ein"
AVC 444 an/aus scheint nichts zu verändern
H.264/AVC hardware encoding an/aus scheint auch nichts zu bewirken

Das Rückstellen der sriov_numvfs = 1 kann ich leider erst am Abend testen.

Eine durchreichen der kompletten GPU per PCI ist daran gescheitert, dass bei einem Neustart der VM der komplette Server mit der Fehlermeldung "Uncorrectable Machine Check Exception" abstürzt neu bootet.
Rein konzeptionell hätte ich auch dahingehend geplant, dass sich zwei RDS Server eine GPU teilen.
 
Die Virtualization Options auf dem Screenshot passen so, würde ich nichts dran drehen. Interessanter ist das Above-4G-Decoding bzw. Resizable BAR bei der PCIe Device Configuration für den Slot. Arc-Karten mögen es gar nicht wenn sie nur den kleinen BAR-Bereich kriegen, und mit SR-IOV muss der Adressraum für alle VFs reichen. Schau mal mit lspci -vvs 05:00.2 wie groß die BARs an der VF tatsächlich sind. Den MCE beim kompletten Durchreichen würde ich nicht als Hardware-Defekt sehen, sowas kommt beim Passthrough fast immer vom Bus-Reset oder der BAR-Zuweisung, nicht von kaputtem RAM.

Beim fehlenden Encode: check mal im Host-dmesg nach GuC/HuC (dmesg | grep -iE 'guc|huc'). Wenn die HuC nicht geladen ist, gibt's kein Hardware-Encode, dann läuft genau das was du siehst – alles über 3D plus CPU. Das erklärt auch warum die GPO-Schalterei nichts bewirkt.

Zieh mal den Kernel hoch, 7.0.14-12 ist nicht mehr der neueste, hier läuft 7.0.14-15. Am xe-SR-IOV wird aktuell viel gefixt, das kann durchaus den Unterschied machen. Welchen Arc-Treiber hast du im Gast drin?
 
Intel listet die Arc Pro B50 bzw. den aktuellen Arc-Pro-Windows-Treiber offiziell nur für Windows 10/11, nicht für Windows Server 2022. RDSH 2022 kann GPU/H.264 grundsätzlich, aber die konkrete B50-Treiberkombination ist damit offenbar außerhalb der von Intel gelisteten OS-Unterstützung.

Ich würde deshalb als nächsten Test exakt dieselbe VF einmal an eine Windows-11-VM hängen. Wenn dort PDF-Scrolling/D3D/QSV sauber läuft und keine AMD-Vi-Faults entstehen, würde ich nicht mehr bei Proxmox suchen, sondern bei Server 2022 + Intel-Treiber/RDP.

Zusätzlich bitte einmal die genaue Intel-Treiberversion/Firmware und lspci -vv -s 05:00.2 posten. Intel spezifiziert für den aktuellen B50-SR-IOV-Stack zwei VFs mit jeweils 8 GB Local-Memory-BAR. Interessant wäre, ob die VF den BAR auf dem DL385 tatsächlich sauber zugewiesen bekommt.
 
ReBAR beim DL385 Gen10 plus würde mich auch sehr interessieren da mein Testsystem auf einem DL380 Gen10 läuft und bei dem funktioniert ReBAR definitiv noch nicht...

Zum EFI: Das "Workload Profile" unter "BIOS/Platform Configuration Options" soll auf jeden fall auf "Virtualization" stehen, HP Stellt da im Hintergrund einiges um, je nach Profil.

Was mir ins Auge springt ist die PCI-Option "PCIe Error Control" ich denke die sollte wohl auf OS Control stehen, weil ja Geräte durchaus Fehler produzieren wenn eine Gast-VM mit aus geht und das gerät wieder am Host verfügbar wird.
Das ist aber nur ein verdacht meinerseits, vielleicht weis da jemand genaueres darüber.
 
Bu66as said:
lspci -vvs 05:00.2
Click to expand...

Das VVS Objekt scheint kein BAR zu besitzen:

05:00.2
IOMMU group: 80
Region 0: Memory at 67701000000 (64-bit, prefetchable) [disabled] [size=16M]
Region 2: Memory at 67200000000 (64-bit, prefetchable) [virtual] [size=8G]

Schaue ich auf das Physische gerät sehe ich BAR Konfigurationen
05:00.0

Region 0: Memory at 67707000000 (64-bit, prefetchable) [size=16M]
Region 2: Memory at 66c00000000 (64-bit, prefetchable) [size=16G]

Capabilities: [420 v1] Physical Resizable BAR
BAR 2: current size: 16GB, supported: 256MB 512MB 1GB 2GB 4GB 8GB 16GB
Capabilities: [220 v1] Virtual Resizable BAR
BAR 2: current size: 8GB, supported: 256MB 512MB 1GB 2GB 4GB 8GB 16GB
Capabilities: [320 v1] Single Root I/O Virtualization (SR-IOV)
Kernel driver in use: xe
Kernel modules: xe



Was mir noch komisch vorkommt ist, dass beide Objekte melden über ein x1 Interface angebunden zu sein obwohl die Grafikkarte an einem 16x PCIe hängt:
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
Bu66as said:
(dmesg | grep -iE 'guc|huc').
Click to expand...
Ausgabe ist:
[ 5.440239] xe 0000:05:00.0: [drm] Tile0: GT0: Using GuC firmware from xe/bmg_guc_70.bin version 70.72.1
[ 5.754783] xe 0000:05:00.0: [drm] Tile0: GT1: Using GuC firmware from xe/bmg_guc_70.bin version 70.72.1
[ 5.766019] xe 0000:05:00.0: [drm] Tile0: GT1: Using HuC firmware from xe/bmg_huc.bin version 8.2.10
[ 6.883947] xe 0000:05:00.0: [drm] PF: Tile0: GT0: VF1..VF2 provisioned with 16384 GuC context IDs
[ 6.884432] xe 0000:05:00.0: [drm] PF: Tile0: GT0: VF1..VF2 provisioned with 64 GuC doorbell IDs
[ 6.885026] xe 0000:05:00.0: [drm] PF: Tile0: GT1: VF1..VF2 provisioned with 16384 GuC context IDs
[ 6.885602] xe 0000:05:00.0: [drm] PF: Tile0: GT1: VF1..VF2 provisioned with 64 GuC doorbell IDs
[ 44.536025] xe_guc_relay: 3 callbacks suppressed
[ 44.536836] xe_guc_relay: 3 callbacks suppressed


Bu66as said:
Zieh mal den Kernel hoch, 7.0.14-12 ist nicht mehr der neueste, hier läuft 7.0.14-15. Am xe-SR-IOV wird aktuell viel gefixt, das kann durchaus den Unterschied machen. Welchen Arc-Treiber hast du im Gast drin?
Click to expand...
Kernel habe ich auf die aktuellste Version gebracht (7.0.14-17).
Dies hat auch etwas gebracht, jetzt scheint die Decode Engine minimal mitzuarbeiten.
Jedoch ist das Problem, dass beim scrollen in einer PDF der WUDFHost >25% der 3D Engine verbraucht immer noch präsent.
Der ARC Treiber ist 32.0.101.8805
1789639577464.png
 
cwt said:
Intel listet die Arc Pro B50 bzw. den aktuellen Arc-Pro-Windows-Treiber offiziell nur für Windows 10/11, nicht für Windows Server 2022. RDSH 2022 kann GPU/H.264 grundsätzlich, aber die konkrete B50-Treiberkombination ist damit offenbar außerhalb der von Intel gelisteten OS-Unterstützung.

Ich würde deshalb als nächsten Test exakt dieselbe VF einmal an eine Windows-11-VM hängen. Wenn dort PDF-Scrolling/D3D/QSV sauber läuft und keine AMD-Vi-Faults entstehen, würde ich nicht mehr bei Proxmox suchen, sondern bei Server 2022 + Intel-Treiber/RDP.

Zusätzlich bitte einmal die genaue Intel-Treiberversion/Firmware und lspci -vv -s 05:00.2 posten. Intel spezifiziert für den aktuellen B50-SR-IOV-Stack zwei VFs mit jeweils 8 GB Local-Memory-BAR. Interessant wäre, ob die VF den BAR auf dem DL385 tatsächlich sauber zugewiesen bekommt.
Click to expand...

Ja das mit dem Treiber ist so eine sache.
Ich habe jetzt die VF an eine Windows 11 VM gehängt. Jedoch bekomme ich da den Fehler 43 und die GPU bleibt deaktiviert.

Die Intel Version ist 32.0.101.8805

BAR scheint nur an Physischen GPU erkannt zu werden (siehe vorheriger Post)

Hier der komplette Output vom VF objekt

05:00.1 VGA compatible controller: Intel Corporation Battlemage G21 [Intel Graphics] (prog-if 00 [VGA controller])
Subsystem: Sparkle Computer Co., Ltd. Device 0209
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin ? routed to IRQ 497
NUMA node: 0
IOMMU group: 79
Region 0: Memory at 67700000000 (64-bit, prefetchable) [disabled] [size=16M]
Region 2: Memory at 67000000000 (64-bit, prefetchable) [virtual] [size=16G]
Capabilities: [70] Express (v2) Endpoint, IntMsgNum 0
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0W TEE-IO-
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown (downgraded), Width x0 (downgraded)
TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range B, TimeoutDis+ NROPrPrP- LTR+
10BitTagComp+ 10BitTagReq+ OBFF Not Supported, ExtFmt+ EETLPPrefix-
EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
FRS- TPHComp- ExtTPHComp-
AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
AtomicOpsCtl: ReqEn-
IDOReq- IDOCompl- LTR- EmergencyPowerReductionReq-
10BitTagReq- OBFF Disabled, EETLPPrefixBlk-
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1-
EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
Retimer- 2Retimers- CrosslinkRes: unsupported
Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit+
Address: 00000000fee00000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [100 v1] Alternative Routing-ID Interpretation (ARI)
ARICap: MFVC- ACS-, Next Function: 2
ARICtl: MFVC- ACS-, Function Group: 0
Capabilities: [200 v1] Address Translation Service (ATS)
ATSCap: Invalidate Queue Depth: 00
ATSCtl: Enable+, Smallest Translation Unit: 00
Kernel driver in use: vfio-pci
Kernel modules: xe
 
Sim0n said:
Zum EFI: Das "Workload Profile" unter "BIOS/Platform Configuration Options" soll auf jeden fall auf "Virtualization" stehen, HP Stellt da im Hintergrund einiges um, je nach Profil.
Click to expand...
Das Workload Profile ist bei mir "Virtualization - Max Performance"

Sim0n said:
Was mir ins Auge springt ist die PCI-Option "PCIe Error Control" ich denke die sollte wohl auf OS Control stehen, weil ja Geräte durchaus Fehler produzieren wenn eine Gast-VM mit aus geht und das gerät wieder am Host verfügbar wird.
Das ist aber nur ein verdacht meinerseits, vielleicht weis da jemand genaueres darüber.
Click to expand...
Leider scheint es bei mir den Menüpunkt PCIe Error Control nicht zu geben...laut HP giude sollte das im Pfad >System Configuration > BIOS/Platform Configuration (RBSU) > PCIe Device Configuration Options sein....
1789645823815.png
 
Die 8,0 GB dedizierter GPU-Speicher aus dem Taskmanager würde ich für die BAR-Frage nicht heranziehen, den Wert meldet Windows aus den Treiberangaben, unabhängig davon wie die BARs tatsächlich gemappt sind. Die Treiberversion steht immerhin drin, 32.0.101.8805 vom 07.07.2026. Dein lspci zeigt die Antwort aber schon: Region 2 der VF steht mit 8G als [virtual] da, das ist der erwartete VF-Anteil, den der Host aus dem 16G-BAR der PF zuteilt, und er wird nicht klassisch vom BIOS gemappt sondern vom Treiber über die Virtual Resizable BAR Capability vergeben. Das [disabled] an Region 0 heißt nur, dass der Memory-Decode der VF zu dem Zeitpunkt aus war, also die VM das Gerät gerade nicht in Betrieb hatte. Zu kleine BARs sind damit vom Tisch, das ReBAR-Thema kannst du für die VF abhaken.

Der Win11-Gegentest von @cwt ist ne gute Idee. Schau dabei, obs sich im Gast flüssiger anfühlt, und lass parallel dmesg -w auf dem Host mitlaufen. Kommen die AMD-Vi-Faults und das resetting auch unter Win11, liegt der Fehler am Host- bzw. VF-Stack. Dann kannst du dir Treiber-Gefrickel im Gast komplett sparen und musst an Kernel/Firmware ran.
 
You must log in or register to reply here.
Top Bottom
Back