ghost82

Make sure you have big sur 11.4 at least, previous versions don't have the drivers for navi 21.

You probably didn't set your gpu as a multifunction device; whatevergreen kext needs the audio part to be on function 1, same slot and same bus as the video part of the gpu, as in the real hardware.

You need to download the right qcow2 file, you are using aarch64 qcow2, which is for arm, but you are using x64 qemu.

Don't bother to it, cpu-z fault.

change from this: <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/HomeAssistant/haos_ova-10.3.qcow2'/> to this: <driver name='qemu' type='qcow2' cache='writeback'/> <source file='/mnt/user/domains/HomeAssistant/haos_ova-10.3.qcow2'/>

Usually, windows 10 vms are configured with cpu hostpassthrough, so if the real cpu supports aes, the aes flag will be passed to the guest too...can you check with cpu-z if aes is listed in the cpu flags?and what is the real cpu?

You need the full dsdt aml file (so, compiled file, use maciasl for example) saved in EFI/OC/ACPI folder, and then you need to add it in the opencore config: config.plist -> ACPI -> Add You can find copies of my dsdts in the gitlab link above, but take into account that part of the dsdt is built based on the addresses you have in the xml. My issue was related to the passed through sata controller. The new qemu 8 adds names (S00, for example) in the dsdt for all the devices attached to pcie root ports, and for whatever reason my sata controller doesn't like it. Once understood the issue, my final fix was to hide the S00 for the specific sata controller in a ssdt, instead of injecting the whole old dsdt.

delete vfio-pci.ids=1ac1:089a from syslinux, reboot, and you should see it listed for passthrough.

You have actually 2 scsi controllers defined: And your optical drive is attached to controller with index 0: Settings are correct. Since you are passing the optical drive only and not the whole controller, the optical drive is attached to a virtio emulated scsi controller and you need drivers for it, drivers are not included in windows. So, open device manager and manually install drivers for the 2 controllers (option "I have a disk"). After mounting the virtio iso inside the vm, point the driver search to x:\vioscsi\w11\amd64\ directory. If you have issues with the 225 virtio release try the latest one: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.229-1/virtio-win-0.1.229.iso

Add this to your syslinux config (in the block of unRAID OS label): Main - Boot Device - Flash - Syslinux Configuration label unRAID OS menu default kernel /bzimage append intel_iommu=on iommu=pt vfio_iommu_type1.allow_unsafe_interrupts=1 initrd=/bzroot Reboot Then, obviously start unraid without gui

download and install nvidia drivers, latest: https://www.nvidia.it/Download/driverResults.aspx/205173/en-us

I think you need to include in your vm settings also the audio part of the gpu, iommu group 28, address 2b:00.1. Make it a multifunction device with the video part of the gpu.

It's not, read carefully, there are files attached ready to be used, or alternatively instructions to build yours.

Please don't take it badly, I'm only trying to give proper info on this. You use vbios when it's needed, i.e. when the gpu that has to be passed is flagged as boot vga by the host; in all the other cases there's no need to pass a vbios; to check if it's flagged as "boot vga" one has to simply check for that string in the system log and check the corresponding address. This is because the video rom saved by the host it's not a 1:1 copy of the video rom of the gpu if it's flagged as boot vga; if it's not the boot vga the video rom is a 1:1 copy. As far as multifunction, one has to always set the gpu as a multifunction device: in bare metal hardware the gpu is a multifunction device so we emulate it as a multifunction device. Although the gpu can work if the gpu is not set as multifunction in the guest, in some cases, if it is not set as multifunction drivers can play badly. Moreover it's always strongly suggested to pass all the subdevices to the vm (video, audio, usb controller, etc.), for the same reason described above. +1 for checking cpu features.