July 28, 20241 yr 10 minutes ago, SimonF said: YES but system drivers wil! create the file. Came back from a reboot and the option is still not available to pass to the VM. I did notice if I expanded the view from "in use" to "all" drivers, the Common is listed in use as well. Im going to blacklist that as well, reboot and see if that helps.
July 28, 20241 yr Community Expert 4 minutes ago, spotopolis said: Came back from a reboot and the option is still not available to pass to the VM. I did notice if I expanded the view from "in use" to "all" drivers, the Common is listed in use as well. Im going to blacklist that as well, reboot and see if that helps. Does it show boumd to vfio on lspci -k?
July 28, 20241 yr 21 minutes ago, SimonF said: Does it show boumd to vfio on lspci -k? After running lspci -k, I happened to scroll up and caught this up top. It does not look like it is bound to vfio. EDIT: This is what I am seeing in the VFIO-PCI log I dont understand because it looks like its bound to VFIO in the logs. Edited July 28, 20241 yr by spotopolis
July 28, 20241 yr Community Expert 31 minutes ago, spotopolis said: After running lspci -k, I happened to scroll up and caught this up top. It does not look like it is bound to vfio. EDIT: This is what I am seeing in the VFIO-PCI log I dont understand because it looks like its bound to VFIO in the logs. try changing blacklist to blacklist qat_dh895xcc
July 28, 20241 yr 26 minutes ago, SimonF said: try changing blacklist to blacklist qat_dh895xcc That resolved the errors at the top of the lspci -k output, but the device is still not showing as in use by vfio EDIT: brain fart. I just realized that the device would not show up as "in use" until it was attached to the VM and "IN USE", however, it is still not displayed as an option to add to the VM when I go to edit it. Am I going to need to manually add it in the XML view again? I dont believe that would work at this point though because I am still not seeing the QAT in Edited July 28, 20241 yr by spotopolis
July 28, 20241 yr Community Expert 15 minutes ago, spotopolis said: That resolved the errors at the top of the lspci -k output, but the device is still not showing as in use by vfio EDIT: brain fart. I just realized that the device would not show up as "in use" until it was attached to the VM and "IN USE", however, it is still not displayed as an option to add to the VM when I go to edit it. Am I going to need to manually add it in the XML view again? I dont believe that would work at this point though because I am still not seeing the QAT in If you cannot get it bound to vfio you will need to do a manual edit. Will only show other pci devs if bound to vfio in gui.
July 28, 20241 yr 12 minutes ago, SimonF said: If you cannot get it bound to vfio you will need to do a manual edit. Will only show other pci devs if bound to vfio in gui. Ill have to pick this up tomorrow if I am going to be editing the XML. I am away from home right now, so anytime I have rebooted my server, I have to wait for that VM to come back up to be able to connect to my VPN, to check the changes made. If I need to edit the XML, that means the VM is down, and I wont have a remote connection.
July 29, 20241 yr 16 hours ago, SimonF said: If you cannot get it bound to vfio you will need to do a manual edit. Will only show other pci devs if bound to vfio in gui. I got back home and did a manual edit to the XML: After saving the XML and trying to boot the VM, the VM would not boot and I got this error: 37 is the correct IOMMU group Edited July 29, 20241 yr by spotopolis
July 29, 20241 yr I undid everything and rebooted to start over from scratch thinking maybe something was done out of order causing the issue. I started by just editing /boot/config/VMPCIOverride.cfg and adding to it "0000:83:00.0|8086:0435": I then rebooted and checked if that made a difference on its own. No. It did not. So I then checked the corresponding box under Tools->System Devices: and then verified that it was actually written to the file in /boot/config/vfio-pci.cfg: (the other two devices are a dual port Intel NIC I have already passed to the VM successfully) Yes it is actaully showing up in the vfio-pci.cfg when the box is ticked in the GUI. So I rebooted once more after making that change. This still did not allow me to add the QAT to the VM. I then checked the VFIO-PCI log in Tools->System Devices. At the top of the log, the device is being detected and has been bound to the vfio-pci, however, at the bottom of the log, I am only seeing the dual port Intel NIC that I have already passed though to the VM. The QuickAssist card is not showing up as listed in /sys/bus/pci/drivers/vfio-pci: I went ahead and tried to add it to the VM XML again anyway: This is how it was added. I got the same error again about the device not being found. So I went back to edit the XML to revert the changes I made, and noticed the bus had changed from '0x00' to '0x04': Im assuming this is referencing the VMs virtual bus that it is attached to, and not the physical bus on the host, correct? I also checked the path for the IOMMU groups since I was getting the error that 37 did not exist: Indeed only the dual port Intel NIC is showing up in that path and 37 for the QAT is not listed. Edited July 29, 20241 yr by spotopolis
July 29, 20241 yr I did find this LINK in the Netgate documentation about this specific QAT device and the issues with VFIO-PCI checks. On their devices the drivers have the QAT on a denylist. Is it possible this is also in a denylist that can be overridden in Unraid?
July 29, 20241 yr Community Expert 1 hour ago, spotopolis said: I did find this LINK in the Netgate documentation about this specific QAT device and the issues with VFIO-PCI checks. On their devices the drivers have the QAT on a denylist. Is it possible this is also in a denylist that can be overridden in Unraid? Looks like to can add this option to the vfio driver and reboot. options vfio-pci disable_denylist=1 https://patchwork.kernel.org/project/linux-crypto/patch/[email protected]/ The reason in the post above seems to indicate that it may make the system unstable if you bind qat to vfio.
July 29, 20241 yr 36 minutes ago, SimonF said: Looks like to can add this option to the vfio driver and reboot. options vfio-pci disable_denylist=1 https://patchwork.kernel.org/project/linux-crypto/patch/[email protected]/ The reason in the post above seems to indicate that it may make the system unstable if you bind qat to vfio. I just tried that, and I didn't see any difference after another reboot. I ran lspci -k and the card is still not binding to vfio-pci
July 29, 20241 yr Community Expert 33 minutes ago, spotopolis said: I just tried that, and I didn't see any difference after another reboot. I ran lspci -k and the card is still not binding to vfio-pci I dont have any more suggestions at this point.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.