Intel Arc SR-IOV "hack"?

Definitely interested in this myself. Mostly replying to setup reply alerts to watch for anything that happens here.

I hadn’t thought about it for QubesOS but yea SR-IOV (or the old GVT-g) would be very useful there. It might still have security implications between applications due to driver/hardware bugs but it would allow for running stuff without performance or support compromises at least.

I’m wondering if the cross-flash needs some hackery to get the software to actually allow it, (change PCIe IDs through a VM to make it think it’s a non-working flex-170?).

@wendell please enlighten us peasants :pray:

2 Likes

does anybody has an actual firmware or bios file?

That should be achievable through e.g. OpenCore. However if it’s as simple as a client-side validation in the update tool, it might be simpler to just patch the firmware update tool not to do the validation.

Any more news? Really hoping this doesn’t die here!

Damn, I got my ARC750 yesterday, I should have done better due diligence, thought even if sr-iov didn’t work it would at least be usable for normal PCI passthrough, what a waste of sand…

2 Likes

In case anyone else is skimming this thread, it doesn’t hurt to have a second warning in case they missed the first one. :joy:

2 Likes

PCIe reset worked fine in all of my Arc GPUs (A380, A750, A770). My fix is to not passthrough the HDMI Audio PCIe Device (which was caused the host lockup). There were some issues related to HDMI/DisplayPort earlier on, but I have not seen it since.

I’ve also seen people who have fixed the host crash by clearing /sys/bus/pci/devices/.../reset_method prior to VM start (on Proxmox).

It’s far from a waste of sand, and a lot easier than getting the RX 7000 series to work.

PCIe reset worked fine in all of my Arc GPUs (A380, A750, A770). My fix is to not passthrough the HDMI Audio PCIe Device (which was caused the host lockup). There were some issues related to HDMI/DisplayPort earlier on, but I have not seen it since…

damn. if i had known that.
happy rabbit i would be.

It’s far from a waste of sand, and a lot easier than getting the RX 7000 series to work.

Whats the problem there? reset as well? i hoped later generations were free of the issue.

Same old stuff; FLR/reset issue. Happens in both of my Sapphire RX 7600 and Sapphire RX 7900 XTX.

Oddly enough, my 7900 XTX also has issues with W790 (Xeon w9-3495X) and Z790 (i9-13900K) systems where EFI firmware taking a veeeery long time to load, which only gone after I explicitly disabled loading EFI firmware for 7900 XTX slot. I want to like the RX 7000 series, but right now, it’s giving me a lot more headache than the A770.

(FWIW, there had been many successful cases in Radeon 7000 Edition thread. I just don’t have enough energy to persue the exact combination to make it work in my case at this point.)

Apart from some initial hiccups, I’ve been very happy with Arc GPUs so far. SR-IOV support is just a bonus for me at this point (would be very happy if we got more details).

1 Like

I have zero issues with my 7900XTX, it needs a VBIOS copy, that’s the only difference to the 6800XT which I had before

it’s even official, I haven’t seen that from AMD and NVIDIA yet

"This document will walk you through the steps to configure a client system containing both an Intel integrated and discrete GPU (for example the Intel® Arc™ A-Series Graphics)

The integrated graphics adapter will be configured to act as your display adapter by following this document. The discrete GPU will be configured not to be bound by the host operating system and will be passed to a virtual machine containing a full operating system for doing “local remote” debugging."

https://dgpu-docs.intel.com/driver/client/virtualized.html

2 Likes

I mean, Intel has supported VFIO in the past alongside GVT-g so this isn’t surprising. But it seems like this is more or less a successor to those efforts in a way after GVT-g was discontinued and past 10th gen iGPUs architecture with Comet Lake. It is interesting they point to this setup for development purposes and they use a laptop for the example they are walking through with this tutorial. Alas, SR-IOV support it is not, but still neat, thanks for sharing.

but is this a new development?
Discrete adapters are not yet stable with full pass-through. Is this a newer larger policy?

What? I have an A770 16G that works perfectly with VFIO, bind and unbind, Looking Glass to my 6650XT, everything works brilliantly, better than AMDGPU bind/unbind. Definitely wouldn’t describe it as “not yet stable” — and I’m on 6.1-LTS so it’s been solid for a while.

I tested on both a X99/2011v4 and a newer C621/LGA-3647 with both hosts freeze after VM shutdown. The same “appearence” was reported by others when I looked it up. So my conclusion: It seemed not intended, nor cared for, by Intel. So the above: Change of communication would mean “different plan forward” from Intel (?). Ergo happiness inbound. Cheers

You too? Also have the VM shutdown host freeze.

Just read that the VM shutdown issue only happens if you attach the audio device to the VM.

Contemplating acquiring an intel arc GPU for VFIO and using qemu native support for jack to handle audio on the host.

Can you try w/o the audio to see if this solves the issue?

on which platform?

Correct

1 Like