ghost82

Check if the irq of the netwrok controller is shared with some other device; if it is, switch at least one of the devices that shares the same irq to msi-x with the msi utility, search and download it in this forum.

No I don't have it, but an additional op region should be necessary to correctly inizitialize the gpu as described here, and especially for windows, that's why for uhd630 I always proposed to try that rom files I linked: https://github.com/patmagauran/i915ovmfPkg

Basically, it means that qemu detected a device that it wont work when passed through to a vm (vfio) and automatically notify you and disabled it for the virtual machine. -- Looking at the qemu source code, it seems your device has broadcom BCM 57810, or a device with vendor 0x14e4, id 0x168e: if (vfio_opt_rom_in_denylist(vdev)) { if (dev->opts && qdict_haskey(dev->opts, "rombar")) { warn_report("Device at %s is known to cause system instability" " issues during option rom execution", vdev->vbasedev.name); error_printf("Proceeding anyway since user specified" " non zero value for rombar\n"); } else { warn_report("Rom loading for device at %s has been disabled" " due to system instability issues", vdev->vbasedev.name); error_printf("Specify rombar=1 or romfile to force\n"); return; } } Your case is inside the else block. The "deny list" is specified here, together with the explanation of why they included that device: /* * List of device ids/vendor ids for which to disable * option rom loading. This avoids the guest hangs during rom * execution as noticed with the BCM 57810 card for lack of a * more better way to handle such issues. * The user can still override by specifying a romfile or * rombar=1. * Please see https://bugs.launchpad.net/qemu/+bug/1284874 * for an analysis of the 57810 card hang. When adding * a new vendor id/device id combination below, please also add * your card/environment details and information that could * help in debugging to the bug tracking this issue */ static const struct { uint32_t vendor; uint32_t device; } rom_denylist[] = { { 0x14e4, 0x168e }, /* Broadcom BCM 57810 */ }; To force loading loading the rom you need to specify romfile in the xml of the vm, like you do with a vbios for a gpu passthrough: <rom file='/path/to/romfile.rom'/> inside the hostdev block. Or, (I think), force loading rom with: <rom bar='on'/> inside the hostdev block. but are you sure you want to pass it even knowing it could cause issues?If the blacklist is hardcoded into qemu I would not modify it...

If you can't fix it by changing some options in bios, what about buying a hdmi dummy plug and attaching it to the igpu? If you have a second monitor, or you have a friend with a monitor, you can try to attach one to igpu and one to the gpu passed to the vm, if it will work, it will work with the dummy plug too.

Nov 24 16:04:25 Tower kernel: pci 0000:11:00.0: vgaarb: setting as boot VGA device you need vbios passed Nov 24 16:04:25 Tower kernel: pci 0000:11:00.0: BAR 0: assigned to efifb you need video=efifb:off in syslinux Multifunction should be setup for gpu passthrough q35 should be preferred instead of i440fx.

See this: https://forums.unraid.net/topic/130008-unraid-611-having-trouble-passing-through-intel-uhd-graphics-630-to-a-vm-on-hp-290-g2-mt-server/

Can you share a new diagnostics booted with uefi? I'm just curious to see the syslog and boot arguments.

Hi, this is a reply from Laszlo, one of the most important maintainers of the edk2 firmware. Question: >> My question is, what happens from a firmware initialisation perspective if >> edk2 is passed as a bios rom instead of as pflash? Reply: In particular, I think this is the reason: If pflash is detected, then you get a UEFI variable service implementation that conforms to the UEFI spec, and everything will work fine. If, however, case (1) is detected, then OVMF switches to a kind of variable store "emulation" So, just a matter of compatibility to be in conformity with uefi specifications.

Sounds like corrupted iso, download the iso again and check its checksum before using it to make sure it's not corrupted. Check also that disk and ram have proper values.

As far as I know that screenshot is normal if you bound to vfio the gpu: gpu is not available from that moment for the host (last line logged is vfio-pci getting loaded for the gpu), but unraid will (hopefully) complete the boot. Try to connect to unraid gui from another device in the lan.

As supposed, there's no trace in memory of efifb, and also from the last command output it seems efifb is not in use, but the syslog is reporting BAR 1 attached to efifb. Try the legacy mode, if it doesn't work I really don't know..

It's nearly impossible to tell this, because this could depend not only from the generic hardware, but also from the software, bios, firmware, hardware revisions, etc. Just install unraid on usb and try it directly with the free trial, that's the only way to see if it will work, it's just like booting a live linux distro. Do this only to check if the hardware is well recognized; unraid needs an array, so you should need to format a disk to be the array, use a spare disk for the array, or if you don't have it, simply do not format anything and use unraid to check only the hardware.

Hi, I had a look at your setup, and I can say for what I saw that you setup all correctly, you are one of few users that set the things right. Unfortunately I haven't a solution for your use case, but I can say the following: 1. the fwcfg device is not an issue, I have that too (invalid data, code 10) and it isn't causing any issue; you don't need it, that device is used by qemu when you pass kernel parameters or files into the guest (you set additional block in the xml for this, and this isn't the case); maybe if libvirt xml is set with fwcfg parameters data wont be anymore incorrect and the device will stop reporting invalid data 2. make sure ASUSGK208edited3.rom is dumped for your card, and if dumped with gpuz, make sure to remove the nvflash header (I think you already did it); vbios must start with 55 AA (hex) 3. shared interrupts should not be a stopper: if the gpu is using irqs and these irqs are shared with other devices, all you should see is lag in digital audio or video output, that's why you switch to msi, but this isn't causing issue with installing drivers 4. Error 43 usually stands for "nvidia found that you are passing through a gpu to a vm, this is not allowed"; this was the case with old nvidia drivers and consumer gpus, nvidia drivers installed from windows software update may use a old version, so use the newest nvidia drivers from nvidia website. Nvidia is now allowing user to passthrough consumer gpus, so no more error 43 5. despite you are correctly using video=efifb:off as a kernel parameter to prevent the host to attach efifb to the gpu, if you check your syslog you can read: Nov 15 14:30:11 Tower kernel: pci 0000:84:00.0: BAR 1: assigned to efifb I read about a few cases and I think the issue comes from here. Unfortunately I don't have a solution for this, could be a kernel bug, a bios bug, or who knows.... You can try to manually detach the gpu from efiframebuffer before starting the vm, with these commands: echo 0 > /sys/class/vtconsole/vtcon0/bind echo 0 > /sys/class/vtconsole/vtcon1/bind echo efi-framebuffer.0 > /sys/bus/platform/drivers/efi-framebuffer/unbind But I'm not sure it will work....because if you run 'cat /proc/iomem' efifb should not be reported... Or...you can try to boot unraid in legacy mode instead of uefi: by this way you exclude at all efifb. I would definetly try this.. Note that running unraid in legacy mode doesn't prevent you from running vms in uefi mode, so your vm setup is still correct.

I compile them from official edk github source, I usually compile stable branches, the attached is the latest stable available (august 2022 if I remember well). Please provide additional info and provide the vars file after booting or trying to boot the vm.

Sometimes setting cpu pinning could bring to worse performance than not setting it. When you use cpu pinning you should consider: 1. to not pin core 0 and its hyperthread, core 0 and its hyperthread is preferred to be used for the host and not in the vm; 2. to set emulatorpin cpuset to core 0/hyperthread (that in use in the host) 3. to use lstopo to map your cpu topology, so you can assign correctly vcpupin, emulatorpin and iothreadpin 4. to use lstopo to define a topology in your xml About lstopo, here is a tutorial from 2018, but still valid: https://forums.unraid.net/topic/74207-video-guide-how-to-use-lstopo-for-better-vm-performance-on-multi-cpu-and-threadripper-systems/

You are probably using virbr0 network looking at your ip. Just change network from virbr0 to bridged br0.

The p400 should work without any issue, I think there are some reports here of users running it successfully. The issue in this post was that gpu was in use by efifb on the host side (at least, the syslog was reporting this) even with the kernel parameter video=efifb:off. The issue could be: 1. a kernel bug, which could have been resolved in recent kernels 2. a bios issue: I read about a similar report (BAR 3 assigned to efifb with video=efifb:off); that user had a x79 motherboard with ami bios and he was booting the host in uefi mode, and he had to force expose uefi on pcie lanes to fix this, i.e. enable cms in bios with "uefi only" options set in all subfields.

me too...but it seems even the lte carrier cannot give to you proper info..I read that even if you have a public ip you could be in some sort of cgnat..or it could be the lte carrier firewall blocking all inbound connections. I didn't understand if you tried an identical router or you moved the router too: to better identify the issue I would try to decreasing at minimum the variables and if possible I would try to use the same hardware with changing only the internet carrier (lte to wired); if it works with wired the issue is for sure the lte. If you aren't able to solve this, you can look at wireguard, it should bypass cgnat.

Can you please try the attached ovmf? Just decompress the zip, backup your original files: /usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi-tpm.fd /etc/libvirt/qemu/nvram/1a8fdacb-aad4-4bbb-71ea-732b0ea1051a_VARS-pure-efi-tpm.fd move these files in a secure place rename the extracted files to OVMF_CODE-pure-efi-tpm.fd and 1a8fdacb-aad4-4bbb-71ea-732b0ea1051a_VARS-pure-efi-tpm.fd move these renamed files to: /usr/share/qemu/ovmf-x64/ /etc/libvirt/qemu/nvram/ Once done, modify the vm template, deleting <boot dev='hd'/> and adding <boot order='1'/> to the nvme block (let's try the traditional way first). If it doesn't boot, shutdown the vm, compress 1a8fdacb-aad4-4bbb-71ea-732b0ea1051a_VARS-pure-efi-tpm.fd and share it here Before shutting down the vm check if you have the double entry 'Windows boot manager' OVMF-secboot.zip

If they are the same you are not under cgnat...I would double check your router/firewall settings, I have no idea other than this...

The chipset of the ethernet card should be the ar8161 which should work with alx drivers in linux and unraid should have these included if I'm not wrong.. Can you post diagnostics file?

As far as I know no problem. I don't know too

You have no vm saved with that uuid. You can: 1. Open the vm in xml mode, replace this line: <uuid>xxxxxxxxxxxxxxxxxxxxxxxx</uuid> with: <uuid>7c611489-4ea2-11ed-9e19-52540070811c</uuid> Or, delete the vm from the gui without deleting vdisk(s) and create a new vm pointing at existing vdisk(s)

I bet that the qcow2 disk doesn't have any uefi partition...try to boot with seabios instead of ovmf.

If it's not changed from the xml in your diagnostics, I cannot explain, the address is there, and also it was e1000 and now it's virtio. Anyway, 04:00.0 or 02:01.0, e1000 or virtio, doesn't make any difference, you have the virtio network inside the vm, the issue is inside the vm, not related to qemu or libvirt, maybe you just need to configure the connection inside the vm (networkmanager?)