SR-IOV: mainlining? about linux-intel-lts HOT 70 OPEN

1. SRIOV upstream task is on-going, ETA Q4'23
2. Yes, we already test Windows VM and works well.

from linux-intel-lts.

1. SRIOV upstream task is on-going, ETA Q4'23
2. Yes, we already test Windows VM and works well.

Hi, I managed to create a DKMS module using the driver source here. But the GPU driver in my WIndows VM fails with Error 43. I wonder if you're using a modded driver?

My DKMS module: https://github.com/strongtz/i915-sriov-dkms
more information: https://www.reddit.com/r/VFIO/comments/xoeika/sriov_on_intel_uhd_graphics_770_xe_12th_gen

from linux-intel-lts.

@krispan-intel Any update on official SR-IOV for Kernel 6.5?

from linux-intel-lts.

@krispan-intel Does Arc A770 support SR-IOV?

I noticed that the Flex 170 might support SR-IOV , but no card to verify. It would be exciting if customer graphics cards(Arc A770, A750) could also support SR-IOV. Many enthusiasts will buy Intel graphics cards because of this.

2023.04.18 Update :

I tested Arc 770 under Ubuntu 22.04 Server. It is support GPU Passthrough, but need install Intel Indirect Display Driver to support stream work(ex Sunshine). Not support SR-IOV!

# lspci -nn | grep "VGA"
00:02.0 VGA compatible controller [0300]: Intel Corporation AlderLake-S GT1 [8086:4680] (rev 0c)
03:00.0 VGA compatible controller [0300]: Intel Corporation Device [8086:56a0] (rev 08)

# lspci -vs 03:00.0
03:00.0 VGA compatible controller: Intel Corporation Device 56a0 (rev 08) (prog-if 00 [VGA controller])
	Subsystem: Intel Corporation Device 1020
	Flags: bus master, fast devsel, latency 0, IRQ 154, IOMMU group 16
	Memory at 81000000 (64-bit, non-prefetchable) [size=16M]
	Memory at 6000000000 (64-bit, prefetchable) [size=16G]
	Expansion ROM at 82000000 [disabled] [size=2M]
	Capabilities: [40] Vendor Specific Information: Len=0c <?>
	Capabilities: [70] Express Endpoint, MSI 00
	Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable+ 64bit+
	Capabilities: [d0] Power Management version 3
	Capabilities: [100] Alternative Routing-ID Interpretation (ARI)
	Capabilities: [420] Physical Resizable BAR
	Capabilities: [400] Latency Tolerance Reporting
	Kernel driver in use: i915
	Kernel modules: i915

without Capabilities: [***] Single Root I/O Virtualization (SR-IOV)

2023.03.22 Update :

I tested Data Center GPU Flex 140 under Ubuntu 22.04 Server. Currently only available in passthrough mode. A single card has two addresses, so one flex 140 card support two vm. Relatively stable, no crashes during testing.

# lspci -nn | grep "Display"
d0:00.0 Display controller [0380]: Intel Corporation Device [8086:56c1] (rev 05)
d4:00.0 Display controller [0380]: Intel Corporation Device [8086:56c1] (rev 05)

SR-IOV driver not ready now.

from linux-intel-lts.

Is the test environment using alder Lake's iGPU or arc dGPU? Is it a test using a normal desktop PC instead of a server? How much does vGPU performance lose in VM environment?

from linux-intel-lts.

I'd say just lack of willingness to sell any card.

from linux-intel-lts.

If you're looking for mainline SRIOV, you can find it from this repo https://github.com/intel/mainline-tracking/tree/linux/v6.4. We will have v6.5 version soon as well.

from linux-intel-lts.

Did anybody manage to verify if Arc supports any kind of SR-IOV?

from linux-intel-lts.

SR-IOV is not supported according to https://www.intel.com/content/www/us/en/support/articles/000093216/graphics.html

That's a huge bummer. I was just about to get one in hopes that it would support SR-IOV in the future.

Could the drivers be patched to enable unofficial support? Or does this really require firmware support?

from linux-intel-lts.

How would I go about making a patch that will add sriov support to my fedora kernel?

I think you may be looking for this?

from linux-intel-lts.

Tangentially related: anyone know if there are there any interim software based solutions for partitioning 13th/14th gen Intel iGPUs until this lands? I just want to be able to pass the hardware encoding capabilities to more than one VM 😅

from linux-intel-lts.

Works on win10 guest, with some code modification personally. while it is better to wait for official stable release.

from linux-intel-lts.

Too bad, it looks like nobody will buy Intel Arc after all :(

from linux-intel-lts.

Too bad, it looks like nobody will buy Intel Arc after all :(

Indeed, there is no advantage in performance compared to competing products. The SR-IOV support in the promotion can be said to be the only bright spot. Now even this advantage does not exist. I really can’t think of anyone who would buy such a meaningless product.

from linux-intel-lts.

SR-IOV is not supported according to https://www.intel.com/content/www/us/en/support/articles/000093216/graphics.html

That's a huge bummer. I was just about to get one in hopes that it would support SR-IOV in the future.

from linux-intel-lts.

SR-IOV is not supported according to https://www.intel.com/content/www/us/en/support/articles/000093216/graphics.html

That's a huge bummer. I was just about to get one in hopes that it would support SR-IOV in the future.

Could the drivers be patched to enable unofficial support? Or does this really require firmware support?

I would assume that it was missing there on a physical level altogether or was fused off.

from linux-intel-lts.

@darkbasic This issue should not be about flaming intel or their business strategy. I am also disappointed, because I can not use sr-iov atm. It was a buyers argument for my current cpu, but I am sure intel devs are just smart devs who do their work and have no influence on business strategy.

from linux-intel-lts.

If you're looking for mainline SRIOV, you can find it from this repo https://github.com/intel/mainline-tracking/tree/linux/v6.4. We will have v6.5 version soon as well.

Does this means it's included in v6.2 kernel?

Presumably not. That appears to be upstream of the official linux source code. I assume "mainline tracking" just means they try to keep up with changes to the kernel until they're ready to submit their changes. So they probably stopped porting 6.2 as soon as 6.3 came out, and so on.

If you're using a "normal" linux distro, you have to wait for intel's changes to get added to linus's "official" version of linux, and then you have to wait for your distro to add linus's changes to your distro's kernel. This process can take a few months.

from linux-intel-lts.

@darkbasic #33 (comment) <- right here in this thread someone got it to work fine on windows so I'd assume that Intel's drivers support it?

from linux-intel-lts.

@darkbasic #33 (comment) <- right here in this thread someone got it to work fine on windows so I'd assume that Intel's drivers support it?

Not a chance. macOS might soon drop Intel support altogether and there's not a single Mac with Intel Xe graphics. Unless the community makes the drivers somehow, we'll never have it. Even nVidia GPUs aren't supported since High Sierra.

But the Windows side works fine. With this specific kernel.

from linux-intel-lts.

Tangentially related: anyone know if there are there any interim software based solutions for partitioning 13th/14th gen Intel iGPUs until this lands? I just want to be able to pass the hardware encoding capabilities to more than one VM 😅

Kernel 6.1 or whatever older that is known/confirmed working in this thread or similar...

I am testing the Intel Xe driver from kernel 6.8 RC5, even got mesa-git and all that, and it can't even show a desktop without drawing GPU rainbow art all over it. But I bet I am doing something wrong as Phoronix already ran tests on it. But nothing was announced, it is experimental, so I had no expectations.

Still, until the Xe driver matures, they should've at least got i915 working reliably (ie no suspend issues) in mainline. I wish I could sell my laptop at this point and buy something older that at least has gvt-g working. They removed a feature for which they don't have a replacement 2 years later. Basically these GPUs have sriov support, but it was never made properly functional in any software. Hyper-V has it partially working, but it's apparent it was more focused on Windows Sandbox and WSL-g.

from linux-intel-lts.

It's interesting. Has anyone tested whether the vgpu driver is available on windows?

from linux-intel-lts.

Is the test environment using alder Lake's iGPU or arc dGPU? Is it a test using a normal desktop PC instead of a server? How much does vGPU performance lose in VM environment?

Is there any update on whether SR-IOV will be "only" possible on iGPUs or also on Arc dGPUs too?
Is it correct that this feature will be available both on desktop machines and notebooks?

from linux-intel-lts.

with some code modification personally

What does this mean? Your XML seems different, do you mean you edited the XML?

Mine (as generated by virt-manager) - getting Code43 in the guest:

Yours:

from linux-intel-lts.

Unlike PCI passthrough, which bound the entire hardware resource to one specific VM, this fancy function enables you to share one GPU with multiple VMs, then you can see the GPU address shows 00:02.x, which is called VF(virtual function), rather than 00:02.0, the physical hardware on host. And it requires support from both the motherboard chip(i915 in my case) and GPU. Your SRIOV function is not powered up, so neither your hardware nor software driver does not compatible.

from linux-intel-lts.

@strongtz , question for you, does that modified driver only work on 6.0.2, as mentioned from your latest commit message, or would that work on 6.0.9?

Been trying to get it working for days but no luck.

Basically get to the point where you echo to the sys device, but no matter what it returns permission denied
I'm on Fedora though, if that's the issue.

Otherwise dkms status shows the sriov-dkms driver from your repo, and I know it is loaded as it throws me an error in dmesg, which isn't there with the in-tree i915 module.

[ 66.468702] snd_hda_codec_hdmi hdaudioC0D2: No i915 binding for Intel HDMI/DP codec [ 66.468883] hdaudio hdaudioC0D2: Unable to configure, disabling

Thanks in advance!

from linux-intel-lts.

@truvatech 6.0.9 works well on Arch Linux here, both in host and VM. VA-API video acceleration in VM works.
If you're using my modified dkms driver, you will see debug prints in dmesg like
i915 0000:0b:00.0: i915_virtualization_probe: entry

from linux-intel-lts.

Did anybody manage to verify if Arc supports any kind of SR-IOV?

SR-IOV is not supported according to https://www.intel.com/content/www/us/en/support/articles/000093216/graphics.html

:(

from linux-intel-lts.

I really can’t think of anyone who would buy such a meaningless product.

There is one very small use case left: av1 decoding/encoding on a budget. The lowest end Arc GPUs could make sense if all you need is a decoding/encoding accelerator, at least until RDNA3 budget cards get released.

from linux-intel-lts.

There is one very small use case left: av1 decoding/encoding on a budget. The lowest end Arc GPUs could make sense if all you need is a decoding/encoding accelerator, at least until RDNA3 budget cards get released.

This is usually one of the few selling points in their commercial propaganda. The disadvantages are obvious, poor drivers, poor performance, and poor prices. It can be said that there are almost no advantages, but if SR-IOV is supported, then these disadvantages can be tolerated.

Even limiting the number of VFs in SR-IOV to one is much better than the current state.

The Arc dGPU is a better description of the fact of wasting sand than the i7-11700K.

I learned that the transistor size is the same for all Arc dGPU multimedia codecs, which makes Arc dGPU only valuable as the lowest-end A370.

from linux-intel-lts.

That's quite sad.

from linux-intel-lts.

Could it be that it would only work for integrated graphics because of connections?

from linux-intel-lts.

I'd say just lack of willingness to sell any card.

Nailed it.

from linux-intel-lts.

1. SRIOV upstream task is on-going, ETA Q4'23
2. Yes, we already test Windows VM and works well.

Is this still the case?

from linux-intel-lts.

I hope so

from linux-intel-lts.

I hope so

I wouldn't be so sure, their lack of transparency in that regard lost me as a customer on iGPUs as well. I was planning to buy a 12th Gen Intel laptop but I'm moving towards a Ryzen 7000 series instead: what's the point of buying the worse APU if none of them supports SR-IOV?

from linux-intel-lts.

I wouldn't be so sure, their lack of transparency in that regard lost me as a customer on iGPUs as well. I was planning to buy a 12th Gen Intel laptop but I'm moving towards a Ryzen 7000 series instead: what's the point of buying the worse APU if none of them supports SR-IOV?

Well, I don't trust AMD's software quality, plus Intel is still much better when it comes to video decoding, and MTL might be epic.

from linux-intel-lts.

@krispan-intel thanks. Do you know if Intel still cares about GVT-g? I've never managed to get it working on my Broadwell APU: intel/gvt-linux#222

from linux-intel-lts.

If you're looking for mainline SRIOV, you can find it from this repo https://github.com/intel/mainline-tracking/tree/linux/v6.4. We will have v6.5 version soon as well.

Does this mean it's included in v6.2 kernel?

from linux-intel-lts.

How would I go about making a patch that will add sriov support to my fedora kernel?

from linux-intel-lts.

maybe, although I build my own custom kernel using the fedora one anyway, so unsure if that's the best option compared to patching something I build anyway. and unsure what happens with the original module in this setup.

from linux-intel-lts.

If you're looking for mainline SRIOV, you can find it from this repo https://github.com/intel/mainline-tracking/tree/linux/v6.4. We will have v6.5 version soon as well.

Have patches been submitted for merging into mainline Linux at this point?

from linux-intel-lts.

Have patches been submitted for merging into mainline Linux at this point?

I don't think so.

from linux-intel-lts.

Hi, has Intel's SRIOV been merged into the mainline? If not, is there a schedule?

from linux-intel-lts.

Same question here, when will this to be merged into mainline.

To be honest, this is the main cause why I bought an Intel CPU this year.

from linux-intel-lts.

How would I go about making a patch that will add sriov support to my fedora kernel?

I created a kmod that supports Fedora. https://github.com/sihawken/i915-sriov-kmod. It uses the DKMS repository as its src, so its effectively the same thing but packaged differently.

YMMV depending on the specific kernel version Fedora ships. I am having difficulties with the latest (6.5.7-200.fc38.x86_64) kernel.

from linux-intel-lts.

How would I go about making a patch that will add sriov support to my fedora kernel?

I created a kmod that supports Fedora. https://github.com/sihawken/i915-sriov-kmod. It uses the DKMS repository as its src, so its effectively the same thing but packaged differently.

YMMV depending on the specific kernel version Fedora ships. I am having difficulties with the latest (6.5.7-200.fc38.x86_64) kernel.

I think maybe it's easier to upgrade you Fedora kernel with linux-intel-lts:

1. download linux-intel-lts
2. build it into rpm package for installation
3. install it on Fedora
4. reboot Fedora
5. ‘uname -ra’ to cat your kernel version

from linux-intel-lts.

How would I go about making a patch that will add sriov support to my fedora kernel?

I created a kmod that supports Fedora. https://github.com/sihawken/i915-sriov-kmod. It uses the DKMS repository as its src, so its effectively the same thing but packaged differently.
YMMV depending on the specific kernel version Fedora ships. I am having difficulties with the latest (6.5.7-200.fc38.x86_64) kernel.

I think maybe it's easier to upgrade you Fedora kernel with linux-intel-lts:

1. download linux-intel-lts
2. build it into rpm package for installation
3. install it on Fedora
4. reboot Fedora
5. ‘uname -ra’ to cat your kernel version

To be honest, If there were a patch, I would be very excited, because it's very much easy for me to build kernel.org source code for supporting SR-IOV function.

from linux-intel-lts.

If you're looking for mainline SRIOV, you can find it from this repo https://github.com/intel/mainline-tracking/tree/linux/v6.4. We will have v6.5 version soon as well.

Have patches been submitted for merging into mainline Linux at this point?

No, sorry. Postpone due to DRM interface rework.

from linux-intel-lts.

As an aside, even the latest Intel iGPU doesn't perform well, does it? Only mobile iGPU performance will be slightly better, but this is not enough for deep computing or gaming performance? Especially when the GPU is partitioned with SR-IOV.
Moreover, due to the poor driver, the performance of the hardware itself is also quite limited.

from linux-intel-lts.

As an aside, even the latest Intel iGPU doesn't perform well, does it? Only mobile iGPU performance will be slightly better, but this is not enough for deep computing or gaming performance? Especially when the GPU is partitioned with SR-IOV. Moreover, due to the poor driver, the performance of the hardware itself is also quite limited.

Uh works fine for me with TF2 and stuff on 2256x1504 resolution last time I test. Maybe not new games like CS2. It's better than skylake graphics which could barely drive a 1080p monitor at 60fps, so I expect it to be less useless than GVT-g. If you can change the dimensions of the virtual monitor, it could be pretty useful for productivity cause QXL is really slow and I don't feel like rebooting into windows sometimes.

from linux-intel-lts.

As an aside, even the latest Intel iGPU doesn't perform well, does it? Only mobile iGPU performance will be slightly better, but this is not enough for deep computing or gaming performance? Especially when the GPU is partitioned with SR-IOV. Moreover, due to the poor driver, the performance of the hardware itself is also quite limited.

Uh works fine for me with TF2 and stuff on 2256x1504 resolution last time I test. Maybe not new games like CS2. It's better than skylake graphics which could barely drive a 1080p monitor at 60fps, so I expect it to be less useless than GVT-g. If you can change the dimensions of the virtual monitor, it could be pretty useful for productivity cause QXL is really slow and I don't feel like rebooting into windows sometimes.

That's really good performance. It'll be only better with the new intel SOC coming out soon.

from linux-intel-lts.

If you're looking for mainline SRIOV, you can find it from this repo https://github.com/intel/mainline-tracking/tree/linux/v6.4. We will have v6.5 version soon as well.

Have patches been submitted for merging into mainline Linux at this point?

No, sorry. Postpone due to DRM interface rework.

I ran into this problem when making a kmod with the new version of the i915 module, and discovered that the DRM module lacked the required symbols to run properly.

I then tried to build a new version of the DRM module, but couldnt get past "symbols exported twice errors" and gave up. I am back to using strongz DKMS version.

from linux-intel-lts.

any news?

from linux-intel-lts.

Most of you probably already know this but before getting too excited about mainline SR-IOV I would read this post by an AMD developer.

SR-IOV virtual functions (VFs) are not the same as physical functions (PFs). You need explicit support for the VF in the KMDs for every OS you want to run in a VM. You can't just use the regular bare metal drivers.

He is basically suggesting that AMD's Windows drivers don't support SR-IOV, thus making the whole thing pointless for most of us. If the same stands true for the Intel Windows drivers you might not have an use case case for a mainline SR-IOV kernel.

from linux-intel-lts.

Most of you probably already know this but before getting too excited about mainline SR-IOV I would read this post by an AMD developer.

SR-IOV virtual functions (VFs) are not the same as physical functions (PFs). You need explicit support for the VF in the KMDs for every OS you want to run in a VM. You can't just use the regular bare metal drivers.

He is basically suggesting that AMD's Windows drivers don't support SR-IOV, thus making the whole thing pointless for most of us. If the same stands true for the Intel Windows drivers you might not have an use case case for a mainline SR-IOV kernel.

Who cares about using this with windows

from linux-intel-lts.

Who cares about using this with windows

I would love to use it to virtualize OSX when I need to target such platform but apparently this is not an option.

from linux-intel-lts.

@darkbasic #33 (comment) <- right here in this thread someone got it to work fine on windows so I'd assume that Intel's drivers support it?

Not a chance. macOS might soon drop Intel support altogether and there's not a single Mac with Intel Xe graphics. Unless the community makes the drivers somehow, we'll never have it. Even nVidia GPUs aren't supported since High Sierra.

But the Windows side works fine. With this specific kernel.

i mean, yeah windows drivers DO support it, and that's what most people care about I assume. Shucks about macOS, but it'd be dumb to expect macOS to support this properly

from linux-intel-lts.

ping, any progress?

from linux-intel-lts.

yeah, wasnt this supposed to land in q4 2023? This is a pretty nice feature that friends I have would love to use, but... not yet mainstreamed.

from linux-intel-lts.

ya what happened?

from linux-intel-lts.

i mean, there was a comment above saying it's postponed due to drm interface changes. However no one said for how long. and until this year I hoped it will not be that long :)

from linux-intel-lts.

I read somewhere that the kernel 6.8 will have this, but seems like that's not happening?

If this gets merged (or if it already is?) there seems to be something regarding VF ... https://gitlab.freedesktop.org/drm/xe/kernel/-/commits/drm-xe-next

from linux-intel-lts.