ghost82

tis and crb are interfaces that are exposed by tpm. Either you check the hardware specifications or you simply try one or the other and see if it is detected.

Configuration seems good to me. I imagine the vbios is dumped from your card and hex edited, and not a downloaded one, right? Did you try to enable remote desktop in windows vm (booted without gpu passthrough) and see if it boots or if it's hanging? Once you enable remote desktop and the os is able to boot but with a black screen, try to install the gpu drivers. I noticed that your mb bios is not the latest, I would try to update to v. 4401 released on 31st of october.

When you passthrough the tpm device you need to choose a model. In this example: <devices> <tpm model='tpm-tis'> <backend type='passthrough'> <device path='/dev/tpm0'/> </backend> </tpm> </devices> you are passing through a tpm device located at /dev/tpm0 'tis' type. If the device is crb just use 'tpm-crb' instead of 'tpm-tis' for the model.

e1000-82545em takes advantage of alternative built-in linux drivers other than virtio, so it should work. Make sure it's detected inside the vm and configured properly to have internet access, use ip addr command for example to see if it's detected.

Diagnostics please. Second line means that the gpu is in use by the host for efifb. However you wrote: 2) Appending "video=efifb:off" So, either you didn't do it correctly, or you didn't reboot the host, or something strange is happening. Append again video=efifb:off reboot the host, boot the vm, and then attach diagnostics

Change network from virtio (or virtio-net) to e1000-82545em. Change disks from virtio to sata.

Seems like the gpu is not properly isolated and as soon you restart or shoutdown the vm the host is using it without releasing it properly on the next vm boot.

Resize command of qemu-img doesn't work on vmdk files; you need to convert vmdk to qcow2 or raw with qemu-img convert command, then resize it.

he is speaking about the kernel of the linux virtual machine, not that of unraid. I think he simply updated the kernel of the virtual machine: centos should use yum command, so, 'sudo yum -y update' should update the system, including the kernel.

Yes, unraid terminal (mount is a linux command) Not sure I understood..the vdisk has to be saved somewhere that could be accessed by the host (unraid) with read/write permissions. To see if your share folder "works" try to access it with the cd command in the unraid terminal (cd /path/to/the/share) and try to create a file (touch test.txt). If it doesn't work, choose another folder or fix what it doesn't work.

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.