Questions about intel SRV-IO / intel XE graphics

[solipsist01]

Hello,

I'm really interested in LibVF.IO. I have read all the documentation, and before i dive in, i have a few questions if you don't mind.

I'm running Debian Bookworm on a nuc 12th gen, with a 12t gen alder lake iris XE igpu.
this GPU is listed on https://open-iov.org/index.php/GPU_Support as being supported by LibVF.IO

when i read further in the docs i stumble upon this part:

Intel i915 Driver

Instructions on the installation of Intel's bleeding edge virtualization drivers can be found here for use with 6th to 9th generation silicon (GVT-g).

SR-IOV APIs on 11th & 12th generation Intel Xe graphics has not yet been documented in the i915 driver API making support more difficult. Source code for i915 SR-IOV is available here. If you would like to engage with Intel's GPU driver developers you can join the Intel-GFX mailing list here.

This makes me doubt. Is there anything i should take into consideration using LibVF.IO with a 12th gen iris XE?
or, would this mean that it's partially supported or something? :)

Also,

at this moment, i'm using gpu passthrough to docker containers for hardware transcoding.
for that, i passthrough /dev/dri:/dev/dri to a few containers.

Will this still work, would i be using LibVF.IO ? or do i lose this ability?

and one last question:

do i get 'real' virtual graphical cards?
Do i need to provide 'hacks' inside the guest VM's in order to make this operate?
i see i need to install a vm with arcd /path/to/yaml/ path/to/iso 100

can't i just pass a GPU through to a KVM VM ? or would that not work ?

[arthurrasmusson]

Hey @solipsist01,

Currently the Intel 12th gen embedded GPUs require a kernel module included in the Linux-Intel-LTS kernel - (The ADL-Linux-ER brach has worked best from my experience before I switched to some unreleased modules). There are also DKMS modules for i915 that include the vGPU driver but those are only for Intel's Flex GPU for now.

With Intel you don't need to provide any licensing hacks in the guest or in the host as it's free!

To get some feedback I'm curious about the following:

Are you willing to compile a kernel module to support your 12th Gen NUC? Alternatively would you prefer a DKMS module to support you?

[solipsist01]

Hello,

Allthough i never have done it, I'm willing to compile a kernel module, no problem. I always want to learn :)

Can i just compile it for my kernel i'm using?
Linux debian 6.1.0-7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-1 (2023-03-19) x86_64 GNU/Linux

And, how would this work when i apt update. Do i need to recompile then ?

With hacks i ment the following.

I have the feeling that one needs to 'inject' custom drivers into the target VM in order to make it accept the virtual GPU.
I'd like to understand how that works, and why this would be required.

I always had the belief that a virtual device, is a virtual device. the target VM, shouldn't notice the difference, right ?

Or, isn't this "real" gpu virtualization, and we passthrough api's, and therefor we need a 'hacked' driver which understands that we passthrough not a whole GPU, but only api's.

Just want to have a clear picture on what i'm doing :)

My goal is to have a windows VM with Steam Remote Play, to play retro arcade games with my 6 year old son,
Now i have to use my laptop for that, and i'd like to have a more 'on demand' approach ;)

[arthurrasmusson]

Hey @solipsist01. When you update with apt, you should be able to remain with your existing custom kernel though you may need to configure your package manager to leave the kernel and grub settings alone between updates.

As for if the guest knows it's a virtual machine or not (special guest software vs. standard software) some people think of that as paravirtual vs. non-paravirtual. Non-paravirtual drivers would be unmodified while paravirtual drivers are modified (or enlightened to virtualization occurring for various benefits like improving VM performance by cutting down on cycles spent on VM-exits).

In the case of Nvidia and Intel, it's a little column A and a little column B. Those drivers are a bit paravirtual, even though they have the same source tree as the bare metal driver.

From what I have seen so far, only AMD seems to mostly lack paravirtualization in their SR-IOV driver, which is both good and bad for various reasons.

If what you mean by hacks is a quick and dirty solution to a make something work (ie: hacky solution), then ya, there's a ton used all over the place (firmware, kernel, userspace). Some of those come from us, some from the GPU vendors themselves, some from KVM/Xen, and some from third-party tools like Looking Glass. Having said that, though, there are a lot of great devs working on GPU virt, and one man's hacky fix is another man's hotfix.

For playing games with your son ya, this should work great! :)