ARC PRO B70 Passthrough Hell on PVE: Resizable BAR Problems

[Ryzen-5900XT]

Hi everyone.

I have been setting up a brand new AMD AM4 platform, combining a Ryzen 9 5900XT with an Intel ARC PRO B70 32G GPU this weekend, to run local AI workloads on a Proxmox VE host. My goal was to leverage the cards 32GB full VRAM via LXC containers and KVM virtual machines. Instead, I ran straight into a brick wall of low level deadlocks, spanning from PCIe signaling issues to OS driver conflicts.

After wrestling with the code and configuration for dozens of hours over the weekend, I am still stuck on the final mile. This card clearly has 32GB VRAM, so why is the ReBAR physical aperture only showing 16GB? Is this ultimately a severe low level compatibility issue? I am reaching out to the low level virtualization and kernel experts here for some guidance.

PVE Virtualization Battlemage GPU Passthrough Hell 32G GPU ReBAR Aperture Only 16G, PCD Timeout, and Win11 Guest Driver Triggers Host Hard Lockup

My Hardware Specifications

CPU: AMD Ryzen 9 5900XT 16C 32T

MB: MSI B550M MORTAR B550

Chipset GPU: Intel ARC PRO B70. Physical 32GB VRAM but Resizable BAR physical aperture only gives 16GB.

Host OS: Proxmox VE Latest Version, Windows 11, Ubuntu 24 and 26.

Phase 1: PCIe Signaling Hell. 32G GPU but Only 16G ReBAR Aperture and PCD Timeout

To maximize virtualization performance, I enabled Resizable BAR and Above 4G Decoding in the motherboard BIOS. However, what is bizarre is that even though this is a large 32GB VRAM card, the PCIe BAR physical aperture allocated by the system is cut in half and only recognizes 16GB.

Worse, even under this halved 16GB aperture, the PVE host kernel immediately chokes upon booting. The kernel logs go into an infinite loop, flooding the console with PCIe errors.

Fatal Symptom 1: PCIe PGD PCD Timeout With ReBAR enabled, the underlying xe or i915 driver hits a physical memory mapping timeout during the Battlemage GPU probe phase. This causes the entire system initialization to hang or experience severe latency due to severe MMIO allocation conflicts.

Temporary Mitigation: Disabling ReBAR in the BIOS allows the PVE host to boot normally, and the device shows up fine under dev dri card0. However, as we all know, running large model matrix operations without ReBAR restricts the PCIe bandwidth to a tiny 256MB window. This prevents the 32GB massive VRAM from working at full speed and cuts AI compute performance in half.

Phase 2: Windows 11 VM Passthrough. Driver Triggers Host Hard Lockup

To cross verify the compute capabilities of this card in a mature environment, I spun up a Windows 11 KVM virtual machine and attempted to pass this GPU through via PCIe Passthrough.

Fatal Symptom 2: Official Driver Installation Freezes the Host Without any drivers installed, Win11 boots fine and utilizes the card as a standard display adapter, showing as Microsoft Basic Display Adapter.

The moment I install the latest official Intel Windows driver and the progress bar hits roughly 50 percent, the entire PVE host suffers a catastrophic Hard Lockup. This is a complete physical crash where SSH drops and the host keyboard LEDs become unresponsive, forcing a cold hard reset via the power button.

Host kernel logs suggest an unrecoverable kernel panic occurs exactly when the guest VM driver attempts to initialize the GPU hardware acceleration control unit.

Phase 3: Falling Back to Ubuntu 26.04 Container and llama.cpp Deadlock

After the Win11 passthrough resulted in hard host crashes, I fell back to a safer Ubuntu 26.04 LXC container, exposing the physical device path with 666 permissions, and tried to manually build a static binary of llama.cpp with the SYCL backend using Intel oneAPI 2026.0.

Through sheer source code modification bypassing find_package and explicit C++ ABI symbol injection to stub out the missing entry point, I successfully resolved the linking errors and generated a static llama-cli binary. However, running the list devices command yields a completely blank list under Available devices.

Probing with clinfo reveals that the OpenCL layer can only detect the AMD Ryzen 9 5900XT CPU compute node. The Intel GPU is completely invisible in terms of general purpose computing. This confirms that in this restricted PVE environment, while the card can handle basic display outputs, its AI matrix multiplication Compute Context is completely failing to mount inside the Linux container.

Questions for the Kernel and Virtualization Experts

First Since this is a 32GB ARC PRO B70, why does the physical aperture only show as 16GB after enabling ReBAR on the MSI B550M motherboard? Does this imply a serious compatibility flaw in the hardware or VBIOS? Could this halved memory allocation be the root cause triggering the PVE kernel PCIe PGD PCD Timeout hang? Are there any specific kernel boot parameters such as pci=realloc that can force correct this large capacity MMIO mapping timeout issue?

Second Why does installing the driver inside the Windows 11 guest trigger a physical Hard Lockup on the PVE Host? Does this indicate a native flaw in this new chips VBIOS regarding MSI-X interrupts or power state transitions under KVM virtualization?

Third Without installing system wide Level Zero packages on a headless stripped container setup, how can I force the Linux kernel to properly mount the new cards Compute Node instead of treating it merely as a basic display adapter?

My brains are fried after pulling an all nighter on this. If anyone running similar hardware or dealing with advanced PCIe memory mapped virtualization has found a way out, I would immensely appreciate your insights.

[Chawan_Intel]

Hello Ryzen-5900XT,

Thank you for posting your query on the community.

Thank you for the detailed explanation and for sharing all the troubleshooting steps you have already performed. I completely understand how frustrating this situation must be after spending significant time debugging the virtualization and passthrough behavior.

To help us investigate this further, could you kindly help share the below details:

• Current Proxmox VE kernel version
• Whether xe or legacy i915 driver is being used
• Whether you are currently using the Intel Arc Pro drivers
• Current kernel boot parameters configured on the host
• Whether ReBAR behavior changes when forcing PCIe Gen3/Gen4 manually
• Full dmesg logs and lspci -vv output
• clinfo output
• Intel® SSU report Intel® System Support Utility for Windows*(with Graphics and PCI Devices selected)

As per Intel guidance for virtualization environments, only Intel Arc Pro drivers are officially recommended for virtualization workloads. Kindly refer to the below article and driver package:

Intel Arc Pro Virtualization Guidance: Graphics Virtualization Technologies Support for Each Intel® Graphics...

Intel Arc Pro Graphics Driver: Intel® Arc™ Pro Graphics - Windows*

While generating the SSU log, kindly make sure that the “Network Adapter” option is unticked.

Additionally, have you tested whether the issue reproduces on a bare-metal Linux installation outside virtualization?

Once we receive the requested information, we will continue reviewing the behavior further and assist you with the next troubleshooting steps accordingly.

We truly appreciate your patience and cooperation throughout the investigation.

Best regards,

Chawan

Intel Customer Support Technician

[Ryzen-5900XT]

Hello Intel Support Team,

Regarding your request, here are the technical logs and system diagnostic data from my AMD platform (Ryzen 9800X3D, AM5).

1. PCIe BAR Assignment Failure (dmesg excerpt): The following error confirms that the device fails to negotiate its 16GB ReBAR resource request within the available MMIO window of the AM5 Root Complex:

Plaintext

[Sat May 23 21:58:15 2026] pci 0000:2d:00.0: VF BAR 2 [mem size 0xe00000000 64bit pref]: can't assign; no space
[Sat May 23 21:58:15 2026] pci 0000:2d:00.0: VF BAR 2 [mem size 0xe00000000 64bit pref]: failed to assign

2. PCIe Tree Configuration (lspci -vv): This output shows the current resource allocation request for the Arc Pro B70 at 2d:00.0:

Plaintext

2d:00.0 VGA compatible controller [0300]: Intel Corporation Battlemage G31 [Arc Pro B70] [8086:e223]
	Subsystem: ASRock Incorporation Device [1849:6025]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >T1Abort- <T1Abort- SERR- <PERR- INTx-
	Capabilities: [70] Express Endpoint, MSI 00
	Capabilities: [ac] MSI-X: Enable+ Count=16 Masked-
	Capabilities: [d0] Vital Product Data
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [150] #26
	Capabilities: [1b0] #19
	Capabilities: [200] #27
	Kernel modules: xe

3. System Environment:

• Kernel: 6.19.10+deb13-amd64

• BIOS Settings: Above 4G Decoding [Enabled], Re-Size BAR [Enabled], ASPM [Disabled], PCIe Speed [Forced Gen3].

• Observation: The Windows 11 driver installation consistently triggers a hard system lockup during the "Installing other features" phase. The Linux can't assign; no space error is persistent regardless of IOMMU/SVM state.

This data demonstrates a critical incompatibility between the Battlemage G31's memory allocation requirements and the current AM5 Root Complex memory mapping. Please escalate this to your engineering team to determine if there are specific firmware flags or PCIe stability patches for the Arc Pro B70 series to handle restricted MMIO environments.

I am prepared to perform further testing if requested.

[Ryzen-5900XT]

Note on Windows Stability: The system experiences a "boot-loop freeze" after a failed driver installation. Upon reboot, the system hard-locks during the kernel loading phase (Windows logo screen), preventing any OS-level log exports or SSU report generation. This confirms that the Intel driver initialization sequence directly triggers a critical PCIe bus lockup on the AM5 platform before the Windows Event Viewer can record any logs.

[Chawan_Intel]

Hello Ryzen-5900XT,

Greetings from Intel Customer Support.

Thank you for sharing the requested details. We appreciate your effort in providing the information and observations regarding the issue.

We would like to inform you that we are currently reviewing the details you shared, including the logs and your findings related to the behavior observed on your system.

Kindly allow us 24 to 48 business hours to analyze the information thoroughly. We will get back to you with an update as soon as possible.

We appreciate your patience and cooperation while we continue investigating this matter further.

Thank you for choosing Intel products and services.

Best regards,

Chawan

Intel Customer Support Technician

[Chawan_Intel]

Hello Ryzen-5900XT,

Thank you for sharing the detailed behavior you are observing on the system.

I understand that the system is experiencing a “boot-loop freeze” following the driver installation attempt, where the system hard-locks during the Windows kernel loading phase before the operating system fully initializes. I also understand that this behavior is preventing OS-level log collection and Event Viewer entries from being generated due to the apparent PCIe bus lockup occurring during the Intel driver initialization sequence.

To help us investigate the issue further, kindly help share the Intel® System Support Utility (SSU) logs for the affected environment.

For the Linux environment, please generate and share the SSU logs using the Intel® System Support Utility for Linux.Intel® System Support Utility for the Linux* Operating System

Additionally, as you also mentioned Windows usage previously, kindly help generate and share the SSU logs from the Windows environment as well, if accessible.

Once we receive the requested logs, we will continue reviewing the issue further and assist you with the next troubleshooting steps accordingly.

We truly appreciate your patience, cooperation, and detailed technical observations throughout the process.

Best regards,

Chawan

Intel Customer Support Technician