Issues with IOMMU groups for VM passtrough.

Lucas VT

Cadet
Joined
Oct 22, 2021
Messages
3
Hello, this is my first time using TrueNAS.

I'm currently using the version TrueNAS-SCALE-21.08-BETA.2 (latest version at the moment.) kernel 5.10.42+truenas

My setup consists of a MSI mag B550m mortar wifi with a r7 3700x.

The motherboard has 1 PCIx16 (gen4/gen3) configured as x4x4x4x4 with a nvme x4 adapter, those 4 nvmes are set up in a pool. It also has a PCI x8 gen3 where I have a GTX 690 and two PCIx1 gen3, one of them occupied by a Quadro p2000 (I've tried both PCIx1 ports).

What I would like to do is to use the Quadro for the host so the different containers have access to it and passtrough the GTX to a VM.

Now the issue:

On the advanced menu, in the isolation section, the GPUs are correctly listed.

GPU_isolation.PNG


The isolation seems to work as executing nvidia-smi shows only the non isolated GPUs, so I understand that the IOMMU group is ready to passtrough to a VM.

However, we can see that both GPUs, with a lot of other random things, are in the same IOMMU group.
IOMMU_groups.PNG

(the gtx 690 appears twice becasue its a dual chip GPU)

And both GPUs being in the same IOMMU group 18 is giving me this error when trying to use the isolated GPU on a VM:

VM_error.PNG


Full error code:
Code:
Error: Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/middlewared/plugins/vm/supervisor/supervisor_base.py", line 174, in start
    if self.domain.create() < 0:
  File "/usr/lib/python3/dist-packages/libvirt.py", line 1353, in create
    raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: 2021-10-21T21:55:36.338385Z qemu-system-x86_64: -device vfio-pci,host=0000:08:00.0,id=hostdev0,bus=pci.0,addr=0x6: vfio 0000:08:00.0: group 18 is not viable
Please ensure all devices within the iommu_group are bound to their vfio bus driver.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 150, in call_method
    result = await self.middleware._call(message['method'], serviceobj, methodobj, params, app=self,
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 1262, in _call
    return await methodobj(*prepared_call.args)
  File "/usr/lib/python3/dist-packages/middlewared/schema.py", line 1182, in nf
    return await func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/middlewared/schema.py", line 1092, in nf
    res = await f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/middlewared/plugins/vm/vm_lifecycle.py", line 47, in start
    await self.middleware.run_in_thread(self._start, vm['name'])
  File "/usr/lib/python3/dist-packages/middlewared/utils/run_in_thread.py", line 10, in run_in_thread
    return await self.loop.run_in_executor(self.run_in_thread_executor, functools.partial(method, *args, **kwargs))
  File "/usr/lib/python3.9/concurrent/futures/thread.py", line 52, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/lib/python3/dist-packages/middlewared/plugins/vm/vm_supervisor.py", line 62, in _start
    self.vms[vm_name].start(vm_data=self._vm_from_name(vm_name))
  File "/usr/lib/python3/dist-packages/middlewared/plugins/vm/supervisor/supervisor_base.py", line 183, in start
    raise CallError('\n'.join(errors))
middlewared.service_exception.CallError: [EFAULT] internal error: qemu unexpectedly closed the monitor: 2021-10-21T21:55:36.338385Z qemu-system-x86_64: -device vfio-pci,host=0000:08:00.0,id=hostdev0,bus=pci.0,addr=0x6: vfio 0000:08:00.0: group 18 is not viable
Please ensure all devices within the iommu_group are bound to their vfio bus driver.


I've tried to break down the IOMMU groups adding pcie_acs_override=downstream,pcie_acs_override=multifunction and pcie_acs_override=downstream,multifunction (not at the same time) to the Python script "/usr/local/bin/truenas-grub.py".
After rebooting the flag is added correctly to the grub file "/etc/default/grub.d/truenas.cfg", but the IOMMU groups do not change.

Is there something I'm doing wrong?
Is there something else that I can try to break down the IOMMU groups?

I've used Manjaro in this very same motherboard in the past and I don't remember having so many things in the same IOMMU group, at the time I was using a GTX 1080 and a Quadro p620 I was able to passtrough one GPU to a VM.

I hope someone can bring some light to this.

Thanks in advance!

Lucas VT.
 

Lucas VT

Cadet
Joined
Oct 22, 2021
Messages
3
UPDATE:

I've been playing with the bios options, chnaging the PCI version manually, setting IOMMU from"auto" to "enabled" and disabling CSM as well as SR-IOV.

Nothing chnages anything related to the IOMMU groups.
 

Lucas VT

Cadet
Joined
Oct 22, 2021
Messages
3
Update:

I've been trying different OS.

Unraid, Manjaro, Ubuntu and RedHat have no issues breaking down the IOMMU groups.
 

sylvain42

Cadet
Joined
Dec 14, 2021
Messages
1
Hi, same problem with ASROCK X570 Creator, I can split on Unraid and Proxmox but not on TrueNas Scale.
Best regards
 

sagit

Cadet
Joined
Dec 17, 2020
Messages
8
edit
Code:
nano /usr/share/grub/default/grub

add
Code:
intel_iommu=on pcie_acs_override=downstream
to
Code:
GRUB_CMDLINE_LINUX_DEFAULT="quiet"

update
Code:
update-grub

1645851206979.png

and then ,reboot
 

dffvb

Dabbler
Joined
Apr 14, 2021
Messages
42
@sagit Thanks for shwoing this, from what I learned this might be okay in home setups, but only if your trust your system, since thi sdownstream patch apparently lowers security, meaning break out of infected VMs is easier...
 

Adnan

Dabbler
Joined
Sep 4, 2015
Messages
22
Anyone managed to do it on TrueNas Scale?
 

Adnan

Dabbler
Joined
Sep 4, 2015
Messages
22

Migsi

Dabbler
Joined
Mar 3, 2021
Messages
40
Necro posting, but I've encountered the exact same problem. I just went from TrueNAS Core, where splitting was perfectly fine, to Scale, where even the acs override does not change anything. I'm 1:1 on the same build, same BIOS settings, just the OS got changed. Is there any hint to what could cause this weird behavior?
 

Migsi

Dabbler
Joined
Mar 3, 2021
Messages
40
I'm having a very similar issue and have had the same lack of success as you when applying the ACS patch. Hoping someone can shed some light on the issue.

My post is here for reference: https://www.truenas.com/community/threads/iommu-issue-with-gpu-passthrough-to-windows-vm.104209/
I *think* I now can shed some light. I'm still not 100% sure, but the acs patch might be applied recursively over a pcie hierarchy tree. If it is so, it is applied starting from the pcie root port, traversing down to all attached devices. BUT: the patch is made to skip devices which provide acs functionality, which in my case the root port does, thus resulting in skipping all "downstream" attached devices. I've read some threads on reddit and arch wiki (sorry, don't have the links anymore :/) that by removing the acs feature flag check within the patch, it splits devices properly. Besides the hassle, compiling your own kernel is an absolute no-go on TrueNAS...
If I only had some more spare time, I'd check the kernel sources if the patch indeed behaves this way.
 

skittlebrau

Explorer
Joined
Sep 1, 2017
Messages
54
Have any of you had any success with the ACS patch in TrueNAS SCALE since?

ACS patch works fine in Proxmox for me, but not in TrueNAS SCALE. At the moment I've kind of just assumed the patch wasn't compiled into SCALE's kernel.
 

mav@

iXsystems
iXsystems
Joined
Sep 29, 2011
Messages
1,428
As I can see, the patch is not in the main Linux tree even decade later. I suppose because with unqualified use and misbehaving or malicious hardware/software it may cause invisible and impossible to diagnose data corruptions between VMs. It is a protocol violation, so it should not be enabled by default, while we discourage users from touching kernel parameters manually. If it so much needed, please create a ticket and collect a feedback.
 

skittlebrau

Explorer
Joined
Sep 1, 2017
Messages
54
As I can see, the patch is not in the main Linux tree even decade later. I suppose because with unqualified use and misbehaving or malicious hardware/software it may cause invisible and impossible to diagnose data corruptions between VMs. It is a protocol violation, so it should not be enabled by default, while we discourage users from touching kernel parameters manually. If it so much needed, please create a ticket and collect a feedback.
I’ve submitted a ticket.


The patch is present in TrueNAS Core, but wasn’t included in SCALE.
 

mav@

iXsystems
iXsystems
Joined
Sep 29, 2011
Messages
1,428
TrueNAS Core is based on FreeBSD. It has completely different kernel code than SCALE.
 

eldxmgw

Dabbler
Joined
May 5, 2021
Messages
32
Any news after submitting a ticket on implementing a fix in Scale? @mav@ @skittlebrau
Checking the log after submitting the ticket seems to me like no interest at all.

I'm also affected by this strange behavior and spending days reading threads where many users suffer of this problems since years.
I can't switch to Core just knowing the problem doesn't happens there.
Running this passthrough SAS controller on a VM on Scale means i don't have to do it on a host which has a much bigger power consumption footprint compared to the Scale box which overall would save energy costs. And those are in Germany one of the most expensive on the planet!

My release train is Bluefin, latest available release. Would update to Cobia if somebody could proof that a fix has finally been implmented.

My problem is i can't passthough my SAS PCIe card: https://www.truenas.com/community/t...ding-a-sas-hba-pci-passthrough-device.115874/
 
Last edited:
Top