I had the arc b50 working a few days ago split between 2 virtual machines, I was testing the rebardxe bios mod before I ordered some more parts for the server.
fast forward to last night I had rebooted the server and I lost my vfgpus(i didnt save the set up via sysfutils).. and now i cant seem to get the gpu to sriov im getting dmseg error “not enough memory” (-ENOMEM)
im not at home so I cant spin the server back up, ive tried the usual pci=realloc in grub but that doesnt seem to fix it either.
anyone have ideas on where to start?
I do have another 7502 for the 2nd socket that should be here by friday, there is a 2nd riser that uses cpu1 instead of cpu0 hoping that might solve my problem
I think I figured it out, after an update the bar size goes to 16GB when the XE driver is loaded. looking at the other posts theres a way to manually set the VF size and the bar size of the physical card. I can unbind the the card from the xe driver and set it to 2gb but when the driver is loaded it goes back to 16gb. I am sort of new to this but this is as far as I’ve gotten with trying to get sr-iov to work
Yup, using the method mal7hael found in Proxmox with kernel 7.0 to allocate different VRAM amounts to 2x VF’s assigned to VMs and leave around 2.5GB for the root card for Plex transcoding, on my B50 on the latest firmware (ie max 2 VF’s).
However, there is a limitation: when VF is created, the maximum amount of VRAM that each VF can use is already limited. Even if a larger amount of VRAM is allocated, the guest cannot use it.
In other words, this method can only make the PF have more available VRAM by reducing the VF’s VRAM.
A side note: CoiaPrant found a fix for the Code 43 error on the latest drivers.
You have to disable all options related to hiding virtualization; for example, you need to remove parameters like kvm=off and -hypervisor, and turn off the ‘Primary GPU’ option.
I gave it a shot, and driver 8517 doesn’t report Code 43 anymore. But the trade-off is that some games with anti-cheat won’t run now…
VMs that need to hide virtualization can only use the 8314 driver.
Great news concerning the Code 43 driver issue, will go ahead and apply the settings as I’m not using the B50 for gaming. I wonder if it will have any effect on the issues I’ve had with GPU acceleration over RDP with a VF in Windows 11.. Will test that out as well.
And just a note on the maximum VRAM limitation on a VF (ie the max VRAM for a VF that a guest will recognize is the total VRAM of the GPU divided by the # of VF’s), if you create only 1 VF and reserve VRAM for the host / root card that will give you the ability to have a VF assigned to a VM with more than 8GB of VRAM on the B50 while still allowing you to utilize the card in the host OS and any containers hosted by it. Obviously only something to consider if you really need the maximum amount of VRAM in a guest VM while also needing host / container GPU acceleration.
Was going to try the Code 43 fix and realized I already had KVM on + I’m using the host CPU option and had Primary GPU off already, still code 43 with latest driver.
Can you share the output of your KVM configuration file for the Windows VM?
As I understand it, with Intel SR-IOV, unused compute resources can be shared dynamically between VFs, but VRAM is statically partitioned.
For example, if you create 4 VFs and the GPU has 24 GB of VRAM, each VF gets 6 GB. That allocation is fixed. Even if only one VF is active, it still only has access to its assigned 6 GB—the remaining VRAM allocated to the other VFs isn’t available to it.
However, other GPU resources—such as compute, scheduling time, and execution units can be more flexibly utilized. If other VFs are idle, the active VF can effectively take advantage of those unused resources.
So in practice:
VRAM: statically divided, not shared
Compute/throughput: more dynamically utilized across active VFs
No luck here sadly, task manager reports Virtual machine: yes and I also tried turning off nested virtualization on the CPU (was default on).. Still Code 43 on the latest driver, works on 8314.
Will try a few other things such as a different virtio driver version.
That’s good, hopefully they figure it out and the fix also applies to Proxmox guest VMs. Not the end of the world being on driver 8314 but also wondering if the fix + the updated driver will resolve some of the other issues I’m having with the B50 SR-IOV in Windows guests (Ubuntu 26.04 has been rock solid stable).
and your card is using both newest firmware and driver (i.e. you have more than 2VF with both new driver and firmware? Or is it new driver in the guest, old firmware on the host??)
I started getting Code 43 at some point in the past few weeks, presumably after updating to kernel 7.0 or PVE 9.2. Switching Processor type from “x86-64-v3” to “Host” resolved the issue for me. Unfortunately this has other performance implications for Windows VMs.
ETA: Trying with flags +amd-no-ssb,+md-clear for now…
I’m trying to find out whether it’s possible to enable or configure Resizable BAR (ReBAR) on a Fujitsu Celsius R970B Power workstation with the D3488-A2 motherboard running the latest available BIOS version.
The system officially supports “Above 4G Decoding,” but there is no official mention of ReBAR support anywhere in the BIOS documentation or firmware notes.
I have already gone through every BIOS setting available on this motherboard, and there is no option related to ReBAR or Resizable BAR at all. The only relevant setting I can find is “Above 4G Decoding,” which is already enabled.
What makes this confusing is that with the first firmware and driver release that enabled SR-IOV for the Intel Arc Pro B50, I was actually able to partition the GPU into 12 virtual functions successfully. After updating to newer drivers, this functionality stopped working completely.
Because of this, I suspect that ReBAR support may either be partially implemented, hidden, or unsupported by the BIOS despite 4G Decoding being available.
Has anyone managed to get ReBAR working on this platform, or knows whether it can be enabled through hidden BIOS settings, EFI shell tools, or BIOS modding?
If BIOS modification is required, I would also really appreciate guidance toward the right tools, documentation, or communities/forums where people work on modding BIOS firmware to add unsupported features like ReBAR.
I already contacted Fujitsu support, but unfortunately they refused to provide any technical information.
