Skitals

What board are you using? The navi reset patch stability seems completely dependent on your hardware. It works flawlessly for many. Other hardware, not so much. If you have a x570 board I would give the reset patch a shot, it works great on this platform.

Oh, and to fix your gpu issue, for single gpu on x570 you need to disable the framebuffer in unraid. Add this parameter to your syslinux.cfg: video=efifb:off When you boot unraid, you will get no video output after the bootloader. A gtx1070 should work fine with a good vbios. This was my previous setup before upgrading to a 5700XT + second gpu.

The numbers in the address stand for Bus:Device.Function. You want to pass all functions of a device. Typically saying passing the whole IOMMU group means the same thing... but in this case there is weirdness with the groupings. It's the same reason you want to pass through your gpu audio along with the graphics card, even if they are in different groups (xx:xx.0 and xx:xx.1).

I would use unraid as your base and virtualize your gaming machine in unraid. I'm doing a lite version of your build with a 3900x and very pleased with the performance.

Also note that my 0d:00.1 does not have reset functionality. 0d:00.0 "non-essential instrumentation" controls reset for that controller, which is why it's passed together.

https://josephlo.wordpress.com/2018/03/24/not-another-article-on-flashing-dell-h310-to-it-mode/

You can not pass through that usb controller on x570. That and onboard audio will lock up unraid without fail. You can pass through the other two usb controllers together, assuming your unraid usb isn't plugged into one of them. See my screenshot, on my system there are 4 devices in group 24. Pass all three devices I have checked together. If you use my VFIO-PCI Config plugin you can see which usb controller your unraid usb is connected to. In my case it's the Cruzer Fit in 14.00.3. Not that the ".3" here is a bit of a red flag. Even though it is in its own IOMMU group, it is linked to the other 14.00.x devices (10.00.x in your case), which includes the problematic onboard audio (that should be 10.00.4 in your case). It is an agesa bug at the very least. I've seen reports of getting onboard audio working with a kernel patch, I haven't investigated yet, it might also fix the usb issue. Either way, it is best case scenario to use your 10.00.3 for unraid usb and pass the others.

What do your IOMMU groups looks like with and without acs override? According to the documentation, the vfio-pci.cfg method binds the entire IOMMU group if there are multiple devices in it even if you only list a single address. Does vfio-pci.ids work the same way? If vfio-pci.ids was working but this method does not, my guess is it's a "bug" with pcie_acs_override since you aren't seeing your "natural" IOMMU groups.

It now shows USB devices attached to each controller. If a USB controller is bound to vfio, the USB devices will not be visible.

The next version of the plugin I'm planning to list the usb devices connected to each usb controller to assist in selection of a usb controller for passthrough. I would appreciate any other suggestions or feedback!

You can use entirely custom styling. The nice thing about using the included custom variables is users can more easily tweak the colors, though.

Now available in Community Applications! Search for "VFIO-PCI Config"

It's definitely hitting the character limit for the GET request. I am changing it to a POST request. Edit: Update should be live!

What elements in particular are you having trouble styling? I might have a look into it. What are your thoughts on including all your themes with the plugin? Or would you rather distribute them yourself via a zip url?

A plugin to create and modify vfio-pci.cfg from the unRAID webGui. Allows you to bind PCI devices by address to the vfio-pci driver. Also displays IOMMU groupings and which devices support reset. Unbound USB controllers display USB devices connected to them. Bound devices will be available to pass through to your VMs under "Other PCI Devices" in the Edit VM Form View. Please see the release notes for 6.7.0-rc1 for more information on this binding method. Search for "VFIO-PCI Config" in Community Applications Github repository: https://github.com/Skitals/unraid-vfio-pci/ URL for manual plugin install: https://raw.githubusercontent.com/Skitals/unraid-vfio-pci/master/plugins/vfio.pci.plg

Ah, yes. I believe there is a 2048 character limit with the method I'm using to move data around. It will work fine editing the css file manually as you are doing. I will look into a workaround.

Can you save any changes, or only when trying to use custom variables? If you add just a few letters and hit apply, does it save? It's possible what you are inputting has special characters that are getting misinterpreted when the textarea is passed to the script.

Change BIND="09:00.0 09:00.1 0b:00.0 0b:00.1" to BIND=09:00.0 09:00.1 0b:00.0 0b:00.1 Better yet, to make sure it's in the right place, just type this in terminal: echo "BIND=09:00.0 09:00.1 0b:00.0 0b:00.1" >/boot/config/vfio-pci.cfg

Along the lines of what I said above, zip handling will now only extract files in the format *-*.cfg and *-*.css. Just pushed out another minor update.

I just pushed out an update that adds an option (checkbox) to overwrite existing files when importing a zip. My concern was that if a user customizes a theme, their work might get inadvertently overwritten if a theme pack or the like unknowingly contains a theme with the same file name. The code for importing from a url had little logic and would have unzipped literally any zip file into your themes directory. Now it will only extract .cfg and .css files from an archive. I'm new to all this programming stuff and I've quickly learned getting something to do what you want is only 10% of the work. The other 90% is plugging holes so a user doesn't break something doing something you didn't anticipate

I uploaded themes.zip to github, and you can load the whole themepack by pasting this url and hitting import: https://github.com/Skitals/theme-engine-styles/raw/master/ThemePackbyRaz.zip Note that the current behavior is that if a theme file already exists it wont get overwritten when importing a zip. So if you wanted to update a theme from a zip, you would need to delete it from Saved Themes first. How do you think that should be handled? Checkbox option to overwrite if file exists?

Note that if the zip file is in the format as exported from the plugin, they can be loaded directly from usb without extracting by putting them in the themes folder. That is themename-basename.zip containing themename-basename.cfg and (optionally) themename-basename.css.

I updated the first post with basic instructions and new screenshots.

If you could, uninstall the plugin and reinstall fresh to make sure your theme (that is included) looks right. Of course when you uninstall it deletes everything in the /boot/config/plugins/theme.engine folder, so make sure any of your work is backed up.

The update just rolled out. It might not look like much, but it was 4 days of work, 17 files changed, 829 insertions(+), 127 deletions(-). Hopefully there aren't TOO many bugs I didn't catch...