netdev - bnxt_en 0000:01:09.1 s1p2: hwrm req_type 0xe0 seq id 0xcdf error 0x3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 20 Aug 2020 12:28:32 -0400
From:   Marc Smith <msmith626@...il.com>
To:     Netdev <netdev@...r.kernel.org>
Subject: bnxt_en 0000:01:09.1 s1p2: hwrm req_type 0xe0 seq id 0xcdf error 0x3

Hi,

I'm using vanilla Linux 5.4.45 in a QEMU/KVM virtual machine. This
virtual machine has VF's from a Broadcom BCM57416 passed into it (via
PCI pass-through). We see messages like these in the kernel log very
frequently:
...
[45171.097040] bnxt_en 0000:01:09.0 s1p1: hwrm req_type 0xe0 seq id
0xcde error 0x3
[45171.098279] bnxt_en 0000:01:09.1 s1p2: hwrm req_type 0xe0 seq id
0xcde error 0x3
[45186.098663] bnxt_en 0000:01:09.0 s1p1: hwrm req_type 0xe0 seq id
0xcdf error 0x3
[45186.100161] bnxt_en 0000:01:09.1 s1p2: hwrm req_type 0xe0 seq id
0xcdf error 0x3
...

If I've used the decoder ring correctly, these appear to be the
req_type and error values:
req_type -> HWRM_TEMP_MONITOR_QUERY
error -> HWRM_ERR_CODE_RESOURCE_ACCESS_DENIED

This only occurs for the virtual functions, and those messages appear
in both the virtual machines that use the VF's (via PCI pass-through)
and VF's that are not passed through into VM's (eg, still present and
unused at the hypervisor level). I don't see these messages for the
PF's.

I can trigger the kernel log entries above by doing the following on
an hwmon sysfs entry for one of the VF's:
# cat /sys/class/hwmon/hwmon0/device/hwmon/hwmon0/temp1_input

So I assume this is because VF's don't have access to the temperature
sensors, either by design or something else is misconfigured. If this
is expected for VF's, perhaps we could set those messages to silent if
it's a VF PCI ID? Or handle this in bnxt_hwmon_open() if it's a VF PCI
ID (eg, not do anything)?

This certainly isn't causing any problems, so not high priority, but
the messages aren't pretty to look at. =)

PF device information:
# bnxtnvm -dev=em1 device_info

Device Interface Name     : em1
MACAddress                : 3c:ec:ef:45:98:82
Part Number               : BCM57416
Description               : N/A
PCI Vendor Id             : 14e4
PCI Device Id             : 16d8
PCI Subsys Vendor Id      : 15d9
PCI Subsys Device Id      : 16d8
PCI Device Name           : 0000:c8:00.0
Adapter Rev               : 01
Active Package version    : N/A
Package version on NVM    : N/A
bnxtnvm_get_nvm_cfg_version status = -1 ver = 0.0.0
NVM config version        : N/A
bnxtnvm_get_active_cfg_version status = 0
Active NVM config version : 0.0.0
Firmware Reset Counter    : Not Available
Error Recovery Counter    : Not Available
Crash Dump Timestamp      : Not Available
Reboot Required           : No

# ethtool -i em1
driver: bnxt_en
version: 1.10.1-216.0.169.4
firmware-version: 214.0.191.0
expansion-rom-version:
bus-info: 0000:c8:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

Thanks for your time.

--Marc