PCIe Passthrough of Radeon iGPU fails

mgr42

So I have a Ryzen 9 7900 and a functioning XCP-ng 8.3 installation and I can hide the iGPU correctly, however, passing it through fails. A Github issue here: https://github.com/gangqizai/igd/issues/24 provides some interesting information. Iit seems that the OpROM for integrated graphics is stored and loaded in firmware rather than anything directly handleable by Xen. At the very least, is there any way to make the emulated graphics less choppy? I used virtual-machine-manager and I know not of if the graphics emulation was really good on CPU or if it used acceleration from the iGPU that I have, but it was able to run Windows 10 with good graphics

jorgenjanssonlee created this issue in gangqizai/igd

closed Invalid PCI ROM header signature: expecting 0xaa55, got 0x7f0d #24

poddingue

I'm not deep into GPU passthrough myself, but played a lot with it lately. especially iGPU!
From what I've read (and experienced) iGPU passthrough is one of the harder cases.
An integrated GPU keeps its option ROM in the motherboard firmware rather than on the card, which is roughly what that GitHub issue you linked describes. XCP-ng documents the general PCI and GPU passthrough path at https://docs.xcp-ng.org/compute#-gpu-passthrough, though I don't think it promises that integrated GPUs specifically will work.
On the choppy emulated graphics, the default virtual display isn't accelerated as far as I know, so that's expected rather than a regression.
This is really a hardware and compute-layer question, so it might be worth a mention to @Team-Hypervisor-Kernel to see whether anyone has managed to pass a Ryzen iGPU through at all.

mgr42

@poddingue Yeah, that does make sense. I understand that this wouldn't necessarily be an intended usecase. I'll probably just get a cheap consumer GPU. And apologies for if this question is painfully obvious, but how would I mention @Team-Hypervisor-Kernel?
But if I can hypothesize, firmware is usually accessible via sysfs, there's an Archlinux guide here: https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Determine_OpROM_signature for determining OpROM signatures, which includes getting it as a file, so maybe that could be loaded in someway, but I know not of the feasibility of that.

poddingue

You just did mention the team.
The mention itself is easy: just type @ and start typing Team-Hypervisor-Kernel, and the forum should autocomplete it into a real group mention.

On the OpROM idea, you might be onto something. That Arch guide does extract the option ROM to a file, and I know some passthrough setups feed a ROM file to the device, but I honestly don't know whether XCP-ng or Xen exposes a way to supply one for an iGPU. That's the kind of thing the hypervisor team would know, so it's worth asking them (and they've already been pinged twice or more times, so...). Getting a cheap discrete GPU is probably the path of least resistance though, for what it's worth.

yannsionneau

Hello @mgr42
I can confirm that indeed today AMD iGPU passthrough is not working on XCP-ng.
I am currently (slowly) working on it.

There are other references about this topic in the Forum and on GitHub FYI:

On the setup I am working on, the Expansion ROM is provided indeed by firmware via the VFCT ACPI table.
I dumped it to a file and provided it to qemu-dm xen-pci-passthrough device via the romfile= argument (via a modified XAPI build).

I can now indeed see a ROM bar in the guest but unfortunately its content is not the content of the file therefore nothing works (amdgpu driver is unable to get its ROM and fails).

So now I'm debugging qemu to try to understand the issue with the emulated/passed-through ROM BAR.

Regards,

Yann
Kernel & Hypervisor team

timemaster5 created this issue in xcp-ng/xcp

open Unable to set romfile for xen-pci-passthrough devices #806

0

freddy77 committed to xapi-project/xen-api

CA-418993: Enable PCI ROM BAR before attempting to give permissions to the VM

Currently the VM is not able to access the ROM as the host
ROM BAR is disabled and not set.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>