Virtual machine log alarm


Fan
Go to solution Solved by ghost82,

Recommended Posts

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

 

image.thumb.png.54bc41a7ae4a3d725605cee1c9cee28f.png

 

please help me thanks

Link to comment
  • Solution

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 by ghost82
Link to comment
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?

 

image.thumb.png.18a3ab6d49a17ad0658342fbc532db10.png

Link to comment
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 by ghost82
Link to comment
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?

Link to comment
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

 

Link to comment
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

 

image.thumb.png.0d1780eb4b1c7f69936f4d80d74ad20e.png

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.