@MajorP93 said:
@pandusen Are you using "Intel Xe" driver?
I am using that particular Linux in-tree driver (shipped with Ubuntu's linux 7.0 generic flavor) and can confirm that this particular driver works via PCIe passthrough and does not require any sort of audio device.
//EDIT: also did you check "dmesg" output on the affected guests? real error messages are more interesting than speculation in this case
@MajorP93 You are completely spot on regarding the PCIe link status reporting anomaly—x1 info in the guest is often just a hypervisor topology quirk and not a real lane bottleneck.
However, just because the base Intel Xe driver successfully loads on a headless system doesn't mean everything is functioning correctly under the hood. A lack of virtualised ReBAR can absolutely cause functional visibility and stability issues the moment you actual try to put a workload on the card.
Getting this working properly requires a complete end-to-end chain of support—not just at the hypervisor and XAPI layer, but crucially within the VM itself. The virtualised EFI BIOS inside the guest must actively support and enable both "Above 4G Decoding" and ReBAR support to handle the extended memory mapping.
Without that full stack alignment, here is what actually happens:
The 256 MB Bottleneck: Without native virtualised ReBAR support at the hypervisor layer and matching EFI BIOS flags inside the VM, the guest OS is forced to interact with a massive VRAM pool (e.g., 16 GB on an Arc card) through a rigid, un-resizable 256 MB MMIO window.
API/Tool-Stack Visibility Failures: The low-level kernel driver might successfully recognize the hardware ID and sit there quietly while idle. However, the moment user-space compute stacks or management tools attempt to initialize a real workload, they aggressively choke on this memory limitation, triggering an immediate driver reset or crash.
Functional Invisibility: To the high-level application, AI framework, or orchestration tool, the GPU effectively becomes invisible or non-functional because the compute API communication layer breaks down entirely.
Since you mentioned you are running this setup successfully on a headless Ubuntu guest, did you run actual heavy compute/inference workloads and look at the performance data or dmesg output?
If you've managed to bypass the 256 MB bar limitation without virtualised EFI/ReBAR support at the hypervisor layer, sharing your dmesg | grep -i BAR or baseline benchmark data would be incredibly helpful to see how your guest is actually mapping that VRAM. Otherwise, the driver simply loading at idle can be highly misleading.
