I am running Fedora 39 workstation as a guest on XCP-NG (xo-server 5.80.0 + xo-web 5.84.0). I am trying to passthrough my Intel A750.
I followed the guide from xcp-ng on gpu passthrough. However, I am having issues with fedora still forcing software rendering and an X11 session. I can confirm that the A750 show up via lspci.
Did you reboot the VM after configuring the passthru?
Does the VM load the driver for the GPU?
It may be that the driver does not load because it was not included in the initramfs image when that VM was installed so it is not loaded during boot.
One possible fix is to manually recreate a new initramfs image using dracut and either add the specific driver needed for that GPU with the --add-drivers option or to create a generic initramfs image that contains all the drivers available using the --no-hostonly option. Use the man page for dracut to get more info on how that would be done.
Just tried running sudo dracut --no-hostonly --force to no avail.
I experienced this on a Ubuntu VM as well. So I’ll likely move the conversation over to XCP-NG’s forms. But I am open to hearing other suggestions here.
I’m sorry,
I neglected to mention that you might need to remove or rename the initramfs for the running kernel before running dracut.
We can actually see if dracut did anything with the output of ls -l /boot/initramfs* and look for the sizes of each of the the images shown. If they are all about the same size and do not have a current date then it was not overwritten. If the one for the current kernel has a current date and is more than twice the size of others then it probably worked.
Looks like the generated image is ~the same size as the recovery image. I guess it worked.
I have a feeling that this has to due with two VGA controllers being presented to the VM. The virtual one and the Arc A750. Digging around and it looks like wayland gets disabled if fedora detects its a guest on a VM with a virtual GPU and passthrough. See: /usr/lib/udev/rules.d/61-gdm.rules.
While wayland is not directly relevant, that leads me to think there is some other logic somewhere that looks for the first VGA controller and will use that regardless of any other GPU being connected. At least in the context of being a virtualized guest.
Interestingly I can see the GPU using oneAPI.jl (a julia based interface for oneAPI). Now testing the package throws some errors, but that may just be the library/toolbox itself.
So the GPU is definitely visible to the guest OS and usable. Which reinforces the belief that I need to kill that first VGA controller/virtual GPU.