ghost82

In my opinion the issue is with the nvidia drivers. It's not clear what drivers you are trying to install, if that of windows or from nvidia; moreover you are continuing to say that it's the upgrade of unraid that broke the vm, but you are also saying that you are creating a new virtual machine (??). The facts: with unraid 6.10.x you have a working mac os vm and linux vm with gpu passthrough. Issue is only in windows: unraid virtualization is based on qemu and libvirt, if passthrough is working it means that the issue is not the host. The issue is windows, or the nvidiad drivers you are using (most probably the drivers). If you are installing drivers from windows update, delete them and install the latest nvidia drivers (currently at version 473.47 (16/05/2022)), from nvidia website. If you are installing latest drivers from nvidia website, try for older drivers, preferably newer than v.465. You may also want to try to change the features block in the windows vm to hide the hypervisor: <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='1234567890ab'/> </hyperv> <kvm> <hidden state='on'/> </kvm> <vmport state='off'/> <ioapic driver='kvm'/> </features> Delete also from your syslinux this: vfio-pci.ids=10de:11c6,10de:0e0b,8086:43d2,8086:1528,8086:4387,8086:f0c8,8086:43a3,8086:43a4 use unraid gui to attach devices to vfio at boot, not syslinux configuration.

Correct No, the usb audio has its own drivers. The "High definition audio controller" you see in msi utility is that of the gpu, which should be passed through to the vm together with the video component of the gpu (so it's correct what you are doing).

This has nothing to do to your issue, it refers to the qemu guest agent, which you could install inside the windows vm once the os is installed. If everything is set correctly you have 3 choices to run the windows installer: 1. once in the uefi shell: 1a. Type exit press enter --> this will go to ovmf bios 2a. Select continue, press enter 3a. When prompted to press a key to boot from cd/dvd, press a key 2. once in uefi shell: 2a. type FS0: press enter type cd EFI\BOOT\ press enter type BOOTX64.EFI press enter 3. boot your vm and be fast enough to press a key to boot from the windows dvd before entering the uefi shell

Hi, First make sure you are installing the latest drivers and not older ones. Main difference between the linux and windows vms is that the linux one is a q35 type, the windows one is i440fx. i440fx has only bus 0, q35 has bus 0 and also pcie-root-ports to create bus 1, 2, 3 etc. This is why you have that error, you cannot use a bus number greater than 0 in a i440fx machine. In both vms the gpu is not set as multifunction, but if it works...however the preferred way is to set it as a multifunction device in the vm. Better to attach diagnostics because your pictures say nothing.

If you are not passing through the usb controller directly, you are passing through single devices that attach to emulated usb controller. For example, in an xml you could have this: <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0' multifunction='on'/> </controller> This defines a single multifunction emulated usb controller, 2.0/1.1 (ehci/uhci). This emulated usb controller has index=0, this means that if you want to attach usb devices to these virtual controller you need to attach them at bus 0, for example: <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x046d'/> <product id='0x0892'/> </source> <address type='usb' bus='0' port='2'/> </hostdev> You see bus 0 here that corresponds to index 0 for the usb controller; ehci/uhci is automatically chosen depending on the usb device. About the port in the usb device block: you see that device is attached to port 2, because: - port 0 on any usb controller is always the usb root hub - port 1 is hardcoded for the device "USB Tablet" if you have it in your xml, this attaches to usb controller uhci, port 1 So if you have multiple usb devices to passthrough to emulated usb controllers, if you want to use ehci/uhci, just define a single emulated multifunction usb controller and attach usb devices starting from port 2. Uhci controller supports a maxmum of 2 ports while ehci controller supports 6. So you can definetly delete the second multifunction usb controller you have in the xml, unless you have more than 1 usb 1.1. device (I don't think so..). Is it not the audio controller of the gpu for digital audio output? Passing through a usb controller instead of single devices is always the best option: 1- for usb devices compatibility 2- to have usb hotplug

this wont work because they don't support msi: irq line based is defined by "linebased", message signaling interrupts (msi) by "msi" and/or "msix".

That are the usb emulated controllers you defined in the xml: ehci/uhci. You still have a shared irq between an emulated usb controller and the high definition audio of your gpu: the audio supports msi so enable it also for the audio, then as far as it concern irq sharing you are good. If it still lags causes are elsewhere... Emulated usb controllers can be deleted if you are not passing through any single usb device, or you can decrease their number, I don't think you need 2 usb 2.0 (ehci) and 2 usb 1.1 (uhci). Note that one ehci always needs its companion uhci. The lags come from the usb, so maybe that setting msi for conflicting audio will solve the lag.

I'm using latencymon: https://www.resplendence.com/latencymon https://www.resplendence.com/download/LatencyMon.exe just run it for some time and it will tell you latencies and drivers which may have issues. If you find issues, high latency, try the msi utility: https://forums.unraid.net/topic/76035-help-struggling-with-nvidia-audio-passthrough/?do=findComment&comment=1076592 Choose v3 and run it as admin. Check if there are any irq conflict and if any, enable msi for one of the conflicting devices.

Yes, unfortunately things are going worse in general, with apple cutting hardware compatibility a lot in the latest ventura, I can't understand how people can continue to buy apple products, especially macs, when in some cases you have 3/4 years of software updates (the 2014 mac mini for example was officially sold till the end of 2018, the mac pro 2013 till 2019, and the same for the macbook air 2017!)..when I spend money to build something powerful I expect to last for about ten years. And the worst thing is not that the hardware is outdated or not performing, it's just a market decision to sell more hardware. In ventura the i210 driver was totally removed. I'm trying to find someone who can share a fresh preinstalled disk image of ventura to check compatibility with older cpus (<ivy bridge); unfortunately, without avx2 and maybe other newer cpu instructions it's not possible to complete installation for my cpu, but should be able to boot a preinstalled image. So, if you have a high speed connection and want to share the vdisk of an installed ventura please contact me in private, so I can continue to test the latest os and provide support for other users. For any reason, feel free to ignore this message, I understand that it's quite a pain to share this..

that 3 in front of the string is wrong. Double check within the unraid terminal to see if the device is there, cd /dev/serial/by-id/ nad perform an ls command.

Issue is with audio at 00:1f.3 you are trying to passthrough. You attached nothing to vfio at boot, all devices that you want to passthrough should be attached to vfio at boot. Currently, audio is in the same iommu group with: 00:1f.0 ISA bridge [0601]: Intel Corporation C236 Chipset LPC/eSPI Controller [8086:a149] (rev 31) Subsystem: Dell Device [1028:07c5] 00:1f.2 Memory controller [0580]: Intel Corporation 100 Series/C230 Series Chipset Family Power Management Controller [8086:a121] (rev 31) DeviceName: Onboard SATA #1 Subsystem: Dell Device [1028:07c5] 00:1f.3 Audio device [0403]: Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller [8086:a170] (rev 31) Subsystem: Dell Device [1028:07c5] 00:1f.4 SMBus [0c05]: Intel Corporation 100 Series/C230 Series Chipset Family SMBus [8086:a123] (rev 31) Subsystem: Dell Device [1028:07c5] Kernel driver in use: i801_smbus Kernel modules: i2c_i801 You may want to apply the acs override patch in unraid to see if it can break iommu group 7 and separate the audio. Or.....do not passthrough audio at all.

VGA is in a iommu group with other devices that can't be passed through, probably in the same iommu group of your usb controller to which you have plugged your flash pendrive.

Then I don't know sorry..there's nothing in the host log pointing to issues making the vm to hang..perhaps the issue is in windows itself,,for example, are you able to boot to the installer with a new vm, with gpu passthrough and an empty vdisk?

Hi, not sure if it's related to this, but in the logs you have a kernel panic due to your ethernet card at address 00:19.0 As far as the vm settings, all I can see is: 1. you are using a quite old machine version: if you want to still use i440fx at least use a more recent machine version, like >6. 2. your gpu is not correctly set as multifunction, replace this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </hostdev> with this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x0' multifunction='on'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/> </hostdev> Note that the 2 hostdev blocks in the xml are separated, that's ok, but if you search for the whole block you wont find anything. 3. Usually it's better to bind the gpu to vfio at boot, but if it works as it is it should be ok

Bind to vfio at boot iommu groups 22 and 23. Moreover, BAR 1 is currently assigned to efifb: modify your syslinux config, adding to the 'append' line: video=efifb:off Reboot

Please after modifications check that all are applied, efifb off is correctly applied but now multifunction and passed through devices are wrong, replace this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </hostdev> with this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x2'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x2'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x3'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x3'/> </hostdev> If you still have a black screen, boot without gpu and only with qxl/vnc, install/enable remote desktop inside the vm, shutdown, delete vnc/qxl from the vm settings and reapply the gpu passthrough (set it multifunction, pass all devices), boot, if you have black screen connect with a second device to the vm to the remote desktop enabled inside the vm, check system devices and see what's wrong, install latest nvidia drivers.

During WWDC 2022 the new Mac os 13.0 Ventura was presented and some hours later the first beta 1 was available for download. The most interesting features for me are the ability to download security updates without downloading a traditional delta update (like in windows) and the new stage manager coupled with mission control for windows management. There are good news and bad news: for my build only bad news I was not able to complete a clean installation in qemu, nor to run a preinstalled image: that's because during installation mac os requires avx+ instructions (user syncretic reported that there are more or less 1,680,140 AVX+ instructions in 172 files....quite a lot!), so all the old cpus without avx+ will not able to complete a clean installation (and this includes also my sandy bridge cpus ). At the current time I still don't know if avx2.0 is enough or not. However there's some hope to be able to run a pre-installed image, I didn't test it, need to wait for one to be available online (or if someone succeeded to install it and want to share the preinstalled disk image he/she can contact me in private).. Update: I want to try to replace the os.dmg in the preboot volume with that of a mac m1 (M1 Rosetta doesn't support AVX and that's why you can bypass the need of AVX2 for the kernel), then since sandy bridge supports avx1 the setup assistant should proceed...it seems that's how someone booted a mac pro with westmere cpu..will report back if it will work. <-- Not working, the setup proceeds a little bit further, then it hangs.. Older gpus than polaris wont work out of the box, apple removed the drivers. Opencore is working and able to boot Ventura at the time of writing (it could be needed to set to false AvoidRuntimeDefrag, untill acidanthera fixes it --> fixed today 11/06/2022); some 'polishing' is still required obviously, we are still in early beta. I'm reporting also that some users were able to install Ventura in qemu.

It seems so. Kernel panic refers to the flash drive.

No you see there are several blocks, each defined by the line starting with "label". You edited the append line of memtest, this means that efifb off will be applied when you boot into memtest. Revert your change. So, if you boot unraid os (without the gui, edit the proper block, i.e.: label Unraid OS menu default kernel /bzimage append video=efifb:off initrd=/bzroot

You can edit the content from unraid gui, from menu: Main - Boot Device - Flash - Syslinux Configuration Edit the append line such it will be: append video=efifb:off OtherThingsYouHave or you can modify the file directly such it will be: append video=efifb:off initrd=/bzroot This for unraid Without gui, obviously if you re booting something else, like uraid with gui, modify the proper append line in the proper section. After modification reboot unraid and try the passthrough

About the vm, it should be better to bind to vfio at boot the gpu, iommu groups 24 and 25, reboot. Did you install the latest nvidia drivers in the vm? Have a look at this: https://forums.unraid.net/topic/124409-error-43-gpu-passthrough-bare-metal-win-10-pro-uefi-boot-nvidia-gtx-1060-6g-unraid-6102/

Hi, is this a legacy or uefi installation?

You need to do this! Main - Boot Device - Flash - Syslinux Configuration Add that to the 'append' line in the block with the green label.

Hi, all I can see is that there is something wrong in your syslinux append line, your actual cmdline looks like this from the logs: BOOT_IMAGE=/bzimage pcie acs override=multifunction video=efifb:off vfio_iommu_type1.allow_unsafe_interrupts=1 pcie_acs_override=downstream,multifunction initrd=/bzroot Remove: pcie acs override=multifunction and reboot, but not sure it will fix things.

Replace this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> with this: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0' multifunction='on'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x1'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x2'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x2'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x21' slot='0x00' function='0x3'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x3'/> </hostdev> Add to the append line of your syslinux configuration: video=efifb:off Reboot and try