Fan Posted November 26, 2022 Share Posted November 26, 2022 After I pass through the NIC to the virtual machine, there are the following alarms in the virtual machine startup log, what does this mean, how to solve it, or can it be ignored? But I can't dial up to the Internet normally through the network card please help me thanks Quote Link to comment
Solution ghost82 Posted November 26, 2022 Solution Share Posted November 26, 2022 (edited) 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... Edited November 26, 2022 by ghost82 Quote Link to comment
Fan Posted November 26, 2022 Author Share Posted November 26, 2022 1 hour ago, ghost82 said: 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... Yes, I have a bcm57810 network card, and I also saw an error about it in the system log, as shown in the picture below, so this problem is because of the compatibility between this card and unriad? Quote Link to comment
Fan Posted November 26, 2022 Author Share Posted November 26, 2022 I currently have a requirement that I can only use this card, I have tried countless times for this, I will try the method you said and try again to see how it turns out, thank you very much Quote Link to comment
ghost82 Posted November 26, 2022 Share Posted November 26, 2022 (edited) 3 minutes ago, Fan said: so this problem is because of the compatibility between this card and unriad? It's a problem of incompatibility between your network card and qemu, which unraid includes for virtualization (but the issue is in the rom/firmware of that broadcom device). So even if you switch to any other linux distro, like manjaro, arch or whatever you want, and you use qemu for virtualization you will get the same error. Edited November 26, 2022 by ghost82 Quote Link to comment
Fan Posted November 26, 2022 Author Share Posted November 26, 2022 4 minutes ago, ghost82 said: It's a problem of incompatibility between your network card and qemu, which unraid includes for virtualization. So even if you switch to any other linux distro, like manjaro, arch or whatever you want, and you use qemu for virtualization you will get the same error. Thank you for pointing out the cause of the problem. I wonder if the syslog error is also due to this problem? Quote Link to comment
Fan Posted November 26, 2022 Author Share Posted November 26, 2022 1 hour ago, ghost82 said: Looking at the qemu source code, it seems your device has broadcom BCM 57810, or a device with vendor 0x14e4, id 0x168e: Yep , that's it, exactly what you said Quote Link to comment
ghost82 Posted November 26, 2022 Share Posted November 26, 2022 1 minute ago, Fan said: I wonder if the syslog error is also due to this problem? In my opinion, yes, quoting from the launchpad link of my first reply: Quote The guest hangs during option rom execution. Moreover, if an attempt is made to quit qemu when the guest is in the hung state, the card gets into an inoperable state. Only a powercycle then, restores the card back into working order, just unloading/loading the driver does not help. Quote The output of lspci when the card is broken - 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: bnx2x 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Quote Link to comment
Fan Posted November 26, 2022 Author Share Posted November 26, 2022 1 hour ago, ghost82 said: https://bugs.launchpad.net/qemu/+bug/1284874 Is it possible to solve this problem by updating the firmware, I found the report in this link is in 2014, I just updated the latest 2022 firmware for this card yesterday Quote Link to comment
ghost82 Posted November 26, 2022 Share Posted November 26, 2022 maybe...but for it to be passed through you need to force load the rom in one of the 2 ways I described, since the blacklist is still hardcoded into qemu. Quote Link to comment
Fan Posted November 26, 2022 Author Share Posted November 26, 2022 2 hours ago, ghost82 said: <rom file='/path/to/romfile.rom'/> This command seems to be invalid, it should be my problem, which one is the romfile below? Quote Link to comment
ghost82 Posted November 26, 2022 Share Posted November 26, 2022 None of them!! you need to dump it in some way from your card.. But you should not need it, just use rom bar=on Quote Link to comment
Fan Posted November 27, 2022 Author Share Posted November 27, 2022 7 hours ago, ghost82 said: None of them!! you need to dump it in some way from your card.. But you should not need it, just use rom bar=on Yes, this command works, but there are still warnings in the boot log, the warnings are a little different, the card still doesn't work, I give up, I'm going to sell the card, thank you very much for your help Quote Link to comment
ghost82 Posted November 27, 2022 Share Posted November 27, 2022 Yes, unfortunately this was expected. Now it tries to passthrough the device but when the rom is force loaded the mess begins...good choice, sell that card. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.