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

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, 20223 yr by ghost82

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?

 

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

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, 20223 yr by ghost82

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?

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

 

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

 

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

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.

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?

 

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

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

 

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.