pciutils / pciutils Goto Github PK

I want to cross compile pciutils,but I don't know how to do it。Can you teach me？

Hello again,

When using the file produced from "lspci -xxxx" command with "lspci -F file -vvvv", the size of memory is not printed as it would when simply doing "lspci -vvvv" on the same system.

Notice how the following two commands differ:
$ lspci -vvvv | grep Region....Memory
$ lspci -xxxx | lspci -F /dev/stdin -vvvv | grep Region....Memory

The first line of the first command:
Region 0: Memory at db000000 (64-bit, non-prefetchable) [size=16M]

The first line of the second command:
Region 0: Memory at db000000 (64-bit, non-prefetchable)

When using the dump of the mmconfig from the file, we are missing the size at the end, which makes looking at dumps much more difficult when you care about the size.

Is this something you are willing to fix?

Thank you!

When I try to compile and port this to windows 64 bit, I find some errors as following.
Is there anything wrong for me to correct for building pciutils for windows 10 64bit ?

Host OS :
Linux debian9 4.18.0-1-amd64 #1 SMP Debian 4.18.6-1 (2018-09-06) x86_64 GNU/Linux
Source Branch :
https://github.com/gitGNU/pciutils/tree/windows

install apt packages info :
https://github.com/gitGNU/pciutils/blob/windows/installed_apt.log
make log info :
https://github.com/gitGNU/pciutils/blob/windows/make.log

lib/sysdep.h:27:10: fatal error: asm/byteorder.h: No such file or directory
 #include <asm/byteorder.h>
          ^~~~~~~~~~~~~~~~~
compilation terminated.

Build the code and run it on windows. Then found that the pcie device with bus number 175 cannot be enumerated.

Hello,
I have an XPS laptop with a built-in nvidia 1050 graphics card and an external nvidia 1070ti graphics card via thunderbolt 3.Under Windows (which I compiled myself), I found that my 1070ti, which was connected to thunderbolt 3, could be scanned normally(with i386-io-windows.h), but the 1050 inside the laptop could not.After analyzing the source code, I found that in the pci_generic_scan_bus function, pci_read_long(PCI_VENDOR_ID), returns the value 0xffffffff.May I ask why?Under Linux, 1050 can be scanned by lspci.Through the Windows device manager, I see that bus for 1050 is 0x1, dev is 0x0, and func is 0x0
thanks!

Hi Martin Mares,

We are planning to add the PCI config space dump in the JSON structured format,
since JSON is structured and user friendly in PCI config space dump analysis.

The cli options will similar to hex dump: lspci -s B:D.F -j

The idea is to traverse the over the config as per the offset and length of the field
print the appropriate key-value pair.

e.g. cli option in my linux pc: lspci -s 00:0.0 -j,
      00:00.0 Host bridge: Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers (rev 07)
      {
            "id" : 1052934278,
            "cmd" : 6,
            "sts" : 8336,
            "rid" : 7
      }

Above is a sample output, for -j, shows JSON -dump of the standard part of the config space.

Sample Implementation:

static void
show_json_dump(struct device *d)
{
	struct json_object *root;
	root = json_create_object();
  
	json_object_add_value_uint(root, "id", get_conf_long(d, 0));
	json_object_add_value_uint(root, "cmd", get_conf_word(d, 4));
	json_object_add_value_uint(root, "sts", get_conf_word(d, 6));
	json_object_add_value_uint(root, "rid", get_conf_byte(d, 8));

	json_print_object(root, NULL);
	putchar('\n');
	json_free_object(root);
}

All the JSON utitlity warppers will be part of json.c and json.h (new files)

Please share your opinion, will be happy to enhance the lspci with this option.

We are seeing different Thunderbolt downstream port speed between kernel and lspci. It turns out to be lspci uses PCI_EXP_LNKCAP, while kernel uses PCI_EXP_LNKCAP2 to determine the speed cap [1]. Quote the comment in pcie_get_speed_cap():
/*
* Link Capabilities 2 was added in PCIe r3.0, sec 7.8.18. The
* implementation note there recommends using the Supported Link
* Speeds Vector in Link Capabilities 2 when supported.
*
* Without Link Capabilities 2, i.e., prior to PCIe r3.0, software
* should use the Supported Link Speeds field in Link Capabilities,
* where only 2.5 GT/s and 5.0 GT/s speeds were defined.
*/
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/pci.c#n5773

Hi,
cap_ats doesn't decode the 'Page Aligned Request' flag in the ATS Capability Register; I'm not seeing a defintiion of the bit in the header either It's set in some recent qemu's virtio devices but lspci -vvv doesn't show it.
It looks like Linux's pci_regs.h gained it in 2019.

This, for instance, worked fine in 3.7.0:

lspci -vvv -d 0x8086:0x2018

but breaks with "Invalid Vendor ID" in 3.9.0. I get that 'x' was repurposed to "match anything", but that is not supported in -d queries anyway and this is breaking scripts left and right.

A patch would be something to effect of:

diff --git a/lib/filter.c b/lib/filter.c
index 7038451..2f6c1c2 100644
--- a/lib/filter.c
+++ b/lib/filter.c
@@ -76,6 +76,9 @@ parse_hex_field(char *str, int *outp, unsigned int *maskp, unsigned int max)
   if (!field_defined(str))
     return 1;  // and keep the defaults

+  if (!maskp && str[0] == '0' && (str[1] == 'x' || str[1] == 'X'))
+    str += 2;
+
   while (*str)
     {
       int c = *str++;

Is lspci reliable to detect VM type on Linux besides dmi?

Wrenashe

It's probably the SocketDirect hardware

[Test case]

1. On a system with a Mellanox CX5 Socket Direct Adapter card, run: lspci -vv -s 17:00.0 | grep Speed
2. Verify that the output shows 'Speed unknown'.
3. Install pciutils from -proposed.
4. Run 'lspci -vv -s 17:00.0 | grep Speed' again.
5. Verify that the output shows 'Speed 16GT/s'.

[Regression potential]
Minimal, and none on systems without the new hardware; this is a code change to trivially extend switch/case statements with a new value.

---Problem Description---
This bugzilla is for tracking that the pciutils tool needs to be updated to support Direct Adapter Cards.
lspci |grep Mell
17:00.0 Ethernet controller: Mellanox Technologies MT28841
b1:00.0 Ethernet controller: Mellanox Technologies MT28841

This is what I see with CX5:
lspci -s 17:00.0 -vvv | grep -E 'Width|PCIeGen'
LnkCap: Port #0, Speed unknown, Width x8, ASPM not supported, Exit Latency L0s unlimited, L1 <4us
LnkSta: Speed unknown, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
[V0] Vendor specific: PCIeGen4 x16

dpkg -l |grep pciutils
ii pciutils 1:3.5.2-1 amd64 Linux PCI Utilities

I also used version 3.9 with the same effect

FreeBSD11.4 no device and vender name print,only print Device venderId:deviceId.like:

00:01.0 Class 0604: Device 8086:7191 (rev 01)
00:07.0 Class 0601: Device 8086:7110 (rev 08)
00:07.1 Class 0101: Device 8086:7111 (rev 01)
00:07.3 Class 0680: Device 8086:7113 (rev 08)
00:07.7 Class 0880: Device 15ad:0740 (rev 10)

It has pci.ids table here.

Hello,

Open bug in launchpad.net
https://bugs.launchpad.net/bugs/1791309

In console:

# lspci -vvnn > a.txt
pcilib: sysfs_read_vpd: read failed: Input/output error

Best regards,

Cristian Aravena Romero (caravena)

I'm building libpci as part of a flatpak, which has to be built on various obscure architectures. With the custom Makefile-based build system it's quite hard to set up the various different prefixes and build options so that libpci is usable by other libraries and binaries such as flashrom.

Rather than add various kludges to the Makefiles (which I initially did), it was actually easier and more understandable for me to just add support for the meson buildsystem. Meson is a fairly new project, but it already has a lot of users including core projects like wayland, the x-server and tons of GUI applications. I'm not a meson developer or advocate, just a content user who thinks it's quite a nice project.

I know hacking on build systems isn't useful time fixing bugs, but I do think pciutils would benefit from making everything simpler. Meson support adds just 147 lines for similar functionality to Make (i.e. pkgconfig files, header includes, shared library, config arguments, 2xCLI tools), although admittedly I've only added the Linux bits. Adding support for other OS's would probably add another 50 lines to the PR.

That said, I don't want to spent any more time on this than required; if you said "I'm quite happy with a Makefile" then I can just close this issue, use my patch to built flashrom as a flatpak and then move onto other things. If you say that the project might has outgrown the Makefile as a build system then I'm happy to do the extra work and add the ifs for the various BSDs and OS-X etc. I've noticed the Fedora distro package for pciutils basically re-implements the install functionality, including properly installing the shared library on Linux. It seems other distros do similar.

Let me know what you think. If you're curious I can submit a PR but didn't want to be overly pushy. Thanks.

pci_malloc does not zero the allocated memory, therefore the following line needs to be added to pci_add_cap to prevent pci_find_cap_nr from causing a segmentation fault.

cap->next = NULL;

Noticed on lspci versions 3.5.2 and 3.6.2 when fourth Thunderbolt device in daisy-chain is attached.

When PCI tree is large, we get stack smashing with "lspci -vt" - although it only happens at the end, so technically it has already printed the tree successfully before it smashes.

Thunderbolt is becoming more common now so this needs to be fixed.

lspci-no-stack-smashing.txt
lspci-stack-smashing.txt

Cheers!

I have a X299 board (running macOS 10.13)
pciutils only shows the devices connected to Intel's X299 PCH.

None of the PCI devices running on the CPU's PCIe lanes are showing.

When executing lspci -vv with one of the functions being an RCiEP (root complex integrated endpoint), not all bits within the device capability register within the PCI Express are verbosely expressed. An example: the FLR (function level reset) bit within this register (bit 28) has no verbose status shown when the component is an RCiEP. However, it is shown for PCIe endpoints and legacy endpoints.

Hello, I have a crash problem today. The call stack is as follows:
pci_scan_bus -> sysfs_scan -> sysfs_get_resources -> fgets(fp = 0x0)
So, after fopen fails, should it return directly?

version: pciutils-3.6.4

Option -d does not work in tree view.

Test case:

$ lspci --version
lspci version 3.7.0
$ lspci -tvnn -d 1002:6660

No output. But without -d it lists device 1002:6660 correctly:

$ lspci -tvnn
-[0000:00]-+-00.0  Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller [8086:0c04]
           +-01.0-[01]----00.0  Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330 / M430] [1002:6660]
...

I tested both v3.7.0 git tag and master branch, same results.

It looks like that older version of lspci was able to show device specified by -d also in tree view:

$ lspci --version
lspci version 3.5.2
$ lspci -tvnn -d 1002:6660
-+-[0000:01]---00.0  Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330 / M430 / Radeon 520 Mobile] [1002:6660]
 \-[0000:00]-

Ref: fastfetch-cli/fastfetch#433

When libpci fail to init, it prints an error message Cannot find any working access method and exits the program.

In my case, I want to catch this error and continue my program. I tried to set access->error to a noop

static void handlePciError(char *msg, ...)
{
// noop
}

void myProgram()
{
    struct pci_access* access = pci_alloc();
    access->error = handlePciError;
    pci_init(access);
    if(!access->methods)
        // handle error
}

Got this warning

src/detection/gpu/gpu_linux.c:248:23: warning: assignment makes ‘__attribute__((noreturn))’ qualified function pointer from unqualified [-Wdiscarded-qualifiers]
  248 |    access->error = handlePciError;

This was bad. AFAIK, returning from a function marked as noreturn is an undefined behavior. So I have to touch the SJLJ shit to handle a simple requirement.

Any ideas?

Trying to show device 1:1:1.0 via lspci bus mapping mode with arguments -G -M -s 1:1:1.0 shows very strange message that device was discovered but then filtered out even that it was explicitly set to not filter it via -s:

Mapping bus 01
Discovered device 01:01.0
But it was filtered out.

Summary of buses:

01: Secondary host bus (?)

Currently in lspci manpage is documented that bus mapping works only for devices at domain 0, but from above message it is not obvious.

So it would be nice to add support for bus mapping mode also for non-zero domains OR at least improve that lspci output message...

Hi Martin Mares,
I have two questions for you：
What is the purpose of the files in the "tests" folder?
Does the community have test cases?
Many thanks for your continuing work on pciutils.

not possible to build existing libpci for arm architecture.

This is indeed a question about whether we need a lock for user space application to access IO port. Thanks for reading.
In Linux source arch\x86\pci\direct.c, we saw that the access of IO port is locked by raw_spin_lock_irqsave().
raw_spin_lock_irqsave(&pci_config_lock, flags);
While in pciutils source:
For the linux-syfs method, the handlers in arch\x86\pci\direct.c are called eventually, thus the accessing is protected by a lock.
For the intel-conf1 method, there is also a lock function intel_io_lock(), but it is empty for most platforms except DOS.

I know that raw_spin_lock_irqsave() is not available for Linux user space. Could we say that accessing using intel-conf1 without a locking mechanism is not reliable?

hello
I downloaded pciutils_win64 from https://eternallybored.org/misc/pciutils and found a DirectIOLibx64.dll inside. but I see pciutils source code said the winio.dll needed, also need to install a unsigned kernel driver.
Is the directiolibx64.dll provided a substitute for winio.dll? Where can I download or get the source code, or where can I get more information about it?
Thank you !

I have got file binary at the link: https://mj.ucw.cz/download/linux/pci/windows/
I run the command: lspci.exe. But I got the this line:

pcilib: Cannot retrieve resource data of PCI device PCI\VEN_xxx&DEV_E101&SUBSYS_00000000&REV_04\3&230dc244&0&08: Empty data.
pcilib: Cannot retrieve resource data of PCI device PCI\VEN_xxx&DEV_E101&SUBSYS_00000000&REV_04\3&230dc244&0&08: Empty data.

Please help me to clear it.

• FreeBSD 13.0
• clang 11.0.1
• git version (commit cac545f)

guest@freebsd:~ $ git clone https://github.com/pciutils/pciutils
guest@freebsd:~ $ git rev-parse HEAD
cac545f64e6f5863b430f5b94442b777aa7f1165
guest@freebsd:~/pciutils $ gmake
...
fbsd-device.c:199:9: error: void function 'fbsd_fill_info' should not return a value [-Wreturn-type]
        return 0;
        ^      ~
fbsd-device.c:210:26: error: expected ')'
  if (want_fill(d, flags PCI_FILL_BASES | PCI_FILL_SIZES))
                         ^
./pci.h:201:25: note: expanded from macro 'PCI_FILL_BASES'
#define PCI_FILL_BASES          0x0004
                                ^
fbsd-device.c:210:16: note: to match this '('
  if (want_fill(d, flags PCI_FILL_BASES | PCI_FILL_SIZES))
               ^
fbsd-device.c:227:3: error: void function 'fbsd_fill_info' should not return a value [-Wreturn-type]
                return 0;
                ^      ~
fbsd-device.c:358:3: warning: incompatible function pointer types initializing 'void (*)(struct pci_dev *, unsigned int)' with an expression of type 'void (struct pci_dev *, int)' [-Wincompatible-function-pointer-types]
  fbsd_fill_info,
  ^~~~~~~~~~~~~~
1 warning and 3 errors generated.
gmake[1]: *** [<builtin>: fbsd-device.o] Error 1
gmake: *** [Makefile:70: lib/libpci.a] Error 2

While preparing the update for the Debian packages for pciutils, the tools noticed that several symbols disappeared:

dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
dpkg-gensymbols: warning: debian/libpci3/DEBIAN/symbols doesn't match completely debian/libpci3.symbols
--- debian/libpci3.symbols (libpci3_1:3.9.0-1_amd64)
+++ dpkg-gensymbols9yTQPY       2022-11-24 02:12:32.801510299 +0000
@@ -19,16 +19,16 @@
  pci_fill_info@LIBPCI_3.5 1:3.5.0
  pci_fill_info@LIBPCI_3.8 1:3.8.0
  pci_filter_init@LIBPCI_3.0 1:3.0.0
- pci_filter_init@LIBPCI_3.3 1:3.3.0
+#MISSING: 1:3.9.0-1# pci_filter_init@LIBPCI_3.3 1:3.3.0
  pci_filter_init@LIBPCI_3.8 1:3.8.0
  pci_filter_match@LIBPCI_3.0 1:3.0.0
- pci_filter_match@LIBPCI_3.3 1:3.3.0
+#MISSING: 1:3.9.0-1# pci_filter_match@LIBPCI_3.3 1:3.3.0
  pci_filter_match@LIBPCI_3.8 1:3.8.0
  pci_filter_parse_id@LIBPCI_3.0 1:3.0.0
- pci_filter_parse_id@LIBPCI_3.3 1:3.3.0
+#MISSING: 1:3.9.0-1# pci_filter_parse_id@LIBPCI_3.3 1:3.3.0
  pci_filter_parse_id@LIBPCI_3.8 1:3.8.0
  pci_filter_parse_slot@LIBPCI_3.0 1:3.0.0
- pci_filter_parse_slot@LIBPCI_3.3 1:3.3.0
+#MISSING: 1:3.9.0-1# pci_filter_parse_slot@LIBPCI_3.3 1:3.3.0
  pci_filter_parse_slot@LIBPCI_3.8 1:3.8.0
  pci_find_cap@LIBPCI_3.1 1:3.1.0
  pci_find_cap_nr@LIBPCI_3.7 1:3.6.3
dh_makeshlibs: error: failing due to earlier errors

Reverting commit 0478e1f fixed the issue.

Hello,

I want to write to the PCIe config space in Windows but it is not working.

I compiled the pciutils on Windows 10 64Bit with cygwin and mingw. Here is my make command:

make CROSS_COMPILE=x86_64-w64-mingw32- HOST=x86_64-windows ZLIB=no IDSDIR="" -j 8

On the access methods only win32-cfgmgr32 works. Reading from the config space also works:

$ ./setpci.exe -s 05:00.0 10.l
pcilib: Cannot retrieve resource data of PCI device PCI\VEN_11F8&DEV_8531&SUBSYS_11F80000&REV_00\4&296156d4&0&00E8: Empty data.
[some more empty data warnings, but they don't match the VID/DID of my PCIe Device]
aa300000

Now I want to write to this register (I know, this is BAR0, but my PCIe card is not used by any driver or any program):

$ ./setpci.exe -s 05:00.0 10.l=0x12345678
pcilib: Cannot retrieve resource data of PCI device PCI\VEN_11F8&DEV_8531&SUBSYS_11F80000&REV_00\4&296156d4&0&00E8: Empty data.
[some more empty data warnings, but they don't match the VID/DID of my PCIe Device]

But when I read it back again, it is still the old value. If I do this with the pciutils from https://eternallybored.org/misc/pciutils/ reading and writing works. I know, this version uses a driver (DirectIO) to access the config space.

Is it possible to write to the config space from Windows with pciutils? I am quite sure it is possible and the error is on my side. So, do I have to change anything with the compilation or do I have to add another access method? Do I have to change or enable anything on windows to make it work?

I think that it would be good to flush away all already accumulated patches and make new release :)

Ability to show subtree by adding -s to -t option is broken by this commit 82dfc66

Before:

# lspci -tv -s 8:7
0000:08:07.0-[10-15]----00.0-[11-15]--+-01.0-[12]----00.0  Intel Corporation NVMe Datacenter SSD [Optane]
                                      +-02.0-[13]----00.0  Intel Corporation NVMe Datacenter SSD [Optane]
                                      +-09.0-[14]----00.0  Intel Corporation NVMe Datacenter SSD [Optane]
                                      \-0a.0-[15]----00.0  Intel Corporation NVMe Datacenter SSD [Optane]

After:

# lspci -tv -s 8:7
-[0000:00]-+-01.0-[05-fd]----00.0-[06-fd]--+-04.0-[07-1c]----00.0-[08-1c]--+-07.0-[10-15]--

In machine-readable mode, kernel modules aren't output when -k is specified
lspci -mm and lspci -mm -k produce identical output that doesn't contain the kernel modules used

I've provided output run inside a gentoo qemu VM, with pciutils version 3.6.4
tux ~/helper # lspci -mm 00:00.0 "Host bridge" "Intel Corporation" "440FX - 82441FX PMC [Natoma]" -r02 "Red Hat, Inc." "Qemu virtual machine" 00:01.0 "ISA bridge" "Intel Corporation" "82371SB PIIX3 ISA [Natoma/Triton II]" "Red Hat, Inc." "Qemu virtual machine" 00:01.1 "IDE interface" "Intel Corporation" "82371SB PIIX3 IDE [Natoma/Triton II]" -p80 "Red Hat, Inc." "Qemu virtual machine" 00:01.3 "Bridge" "Intel Corporation" "82371AB/EB/MB PIIX4 ACPI" -r03 "Red Hat, Inc." "Qemu virtual machine" 00:02.0 "VGA compatible controller" "Vendor 1234" "Device 1111" -r02 "Red Hat, Inc." "Device 1100" 00:03.0 "Ethernet controller" "Red Hat, Inc." "Virtio network device" "Red Hat, Inc." "Virtio network device" 00:04.0 "SCSI storage controller" "Red Hat, Inc." "Virtio SCSI" "Red Hat, Inc." "Virtio SCSI" 00:05.0 "Unclassified device [00ff]" "Red Hat, Inc." "Virtio RNG" "Red Hat, Inc." "Virtio RNG"

tux ~/helper # lspci -mm -k 00:00.0 "Host bridge" "Intel Corporation" "440FX - 82441FX PMC [Natoma]" -r02 "Red Hat, Inc." "Qemu virtual machine" 00:01.0 "ISA bridge" "Intel Corporation" "82371SB PIIX3 ISA [Natoma/Triton II]" "Red Hat, Inc." "Qemu virtual machine" 00:01.1 "IDE interface" "Intel Corporation" "82371SB PIIX3 IDE [Natoma/Triton II]" -p80 "Red Hat, Inc." "Qemu virtual machine" 00:01.3 "Bridge" "Intel Corporation" "82371AB/EB/MB PIIX4 ACPI" -r03 "Red Hat, Inc." "Qemu virtual machine" 00:02.0 "VGA compatible controller" "Vendor 1234" "Device 1111" -r02 "Red Hat, Inc." "Device 1100" 00:03.0 "Ethernet controller" "Red Hat, Inc." "Virtio network device" "Red Hat, Inc." "Virtio network device" 00:04.0 "SCSI storage controller" "Red Hat, Inc." "Virtio SCSI" "Red Hat, Inc." "Virtio SCSI" 00:05.0 "Unclassified device [00ff]" "Red Hat, Inc." "Virtio RNG" "Red Hat, Inc." "Virtio RNG"

tux ~/helper # lspci -k 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) Subsystem: Red Hat, Inc. Qemu virtual machine 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] Subsystem: Red Hat, Inc. Qemu virtual machine 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] Subsystem: Red Hat, Inc. Qemu virtual machine Kernel driver in use: ata_piix 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) Subsystem: Red Hat, Inc. Qemu virtual machine 00:02.0 VGA compatible controller: Device 1234:1111 (rev 02) Subsystem: Red Hat, Inc. Device 1100 00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device Subsystem: Red Hat, Inc. Virtio network device Kernel driver in use: virtio-pci 00:04.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI Subsystem: Red Hat, Inc. Virtio SCSI Kernel driver in use: virtio-pci 00:05.0 Unclassified device [00ff]: Red Hat, Inc. Virtio RNG Subsystem: Red Hat, Inc. Virtio RNG Kernel driver in use: virtio-pci

Hello,
I am wondering if there is any possibility that libpci specifically could be relicensed under a slightly more permissive LGPL or similar license so that proprietary programs can still link to it. This seems to be a pretty common convention for similar libraries such as libusb, libnvme, etc.

I obviously want to respect the developers, and it's not my intent to open a can of worms with this request. I feel like it would end up enriching the community, since not all developers(or their employers) are willing to release their code under a GPL license.

Hello,

lspci version 3.6.4 on Fedora 33 x86_64 with GNU/Linux kernel 5.10.4-200.fc33.x86_64

Trying the command below in a root console prints an error through stderr:

lspci -vvv | grep -i vga
[...]
pcilib: sysfs_read_vpd: read failed: Input/output error
[...]

The same command with -v outputs no error.
The same command with -vv outputs the same error.

Removing the pipe to grep for the 3 variants of the -v commutator (-v, -vv, -vvv) outputs no errors.
Seems that piping lspci with double or triple -v commutator produces the stderr message.

Hope this description will help.

Feel free to make any comment.

Cordially,

--
NVieville

I downloaded master as zip and run make && make install in the path of pciutils-master, however when I tried lspci, the output was lspci not found.

% sw_vers
ProductName:	macOS
ProductVersion:	11.4
BuildVersion:	20F71

% uname -a
Darwin XUESHANs-MacBook-Pro.local 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 05:10:31 PDT 2021; root:xnu-7195.121.3~9/RELEASE_ARM64_T8101 arm64

% pwd
/Users/Downloads/pciutils-master

% make
cd lib && ./configure
Configuring libpci for your system... arm64--darwin 20.5.0 arm64 darwin
Looking for access methods... darwin dump
Checking for zlib support... yes (auto-detected)
Checking for DNS support... yes (auto-detected)
Checking whether to build a shared library... no (set manually)
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C lib all
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o init.o init.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o access.o access.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o generic.o generic.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o dump.o dump.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o names.o names.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o filter.o filter.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o names-hash.o names-hash.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o names-parse.o names-parse.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o names-net.o names-net.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o names-cache.o names-cache.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o names-hwdb.o names-hwdb.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o params.o params.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o caps.o caps.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o darwin.o darwin.c
rm -f libpci.a
ar rcs libpci.a init.o access.o generic.o dump.o names.o filter.o names-hash.o names-parse.o names-net.o names-cache.o names-hwdb.o params.o caps.o darwin.o
ranlib libpci.a
sed <libpci.pc.in >libpci.pc -e 's,@PREFIX@,/usr/local,' \
		-e 's,@INCDIR@,/usr/local/include,' \
		-e 's,@LIBDIR@,/usr/local/lib,' \
		-e 's,@IDSDIR@,/usr/local/share,' \
		-e 's,@VERSION@,3.8.0,' \
		-e 's,@LDLIBS@, -lresolv -framework CoreFoundation -framework IOKit -lz ,' \
		-e 's,@WITH_LIBS@, -lresolv -framework CoreFoundation -framework IOKit -lz ,'
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o lspci.o lspci.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o ls-vpd.o ls-vpd.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o ls-caps.o ls-caps.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o ls-caps-vendor.o ls-caps-vendor.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o ls-ecaps.o ls-ecaps.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes    -c -o ls-kernel.o ls-kernel.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o ls-tree.o ls-tree.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o ls-map.o ls-map.c
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o common.o common.c
cc   lspci.o ls-vpd.o ls-caps.o ls-caps-vendor.o ls-ecaps.o ls-kernel.o ls-tree.o ls-map.o common.o lib/libpci.a  -lresolv -framework CoreFoundation -framework IOKit -lz   -o lspci
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o setpci.o setpci.c
cc   setpci.o common.o lib/libpci.a  -lresolv -framework CoreFoundation -framework IOKit -lz  -o setpci
cc -O2 -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes   -c -o example.o example.c
cc   example.o lib/libpci.a  -lresolv -framework CoreFoundation -framework IOKit -lz  -o example
M=`echo 2022-04-18 | sed 's/-01-/-January-/;s/-02-/-February-/;s/-03-/-March-/;s/-04-/-April-/;s/-05-/-May-/;s/-06-/-June-/;s/-07-/-July-/;s/-08-/-August-/;s/-09-/-September-/;s/-10-/-October-/;s/-11-/-November-/;s/-12-/-December-/;s/\(.*\)-\(.*\)-\(.*\)/\3 \2 \1/'` ; sed <lspci.man >lspci.8 "s/@TODAY@/$M/;s/@VERSION@/pciutils-3.8.0/;s#@IDSDIR@#/usr/local/share#;s#@PCI_IDS@#pci.ids.gz#"
M=`echo 2022-04-18 | sed 's/-01-/-January-/;s/-02-/-February-/;s/-03-/-March-/;s/-04-/-April-/;s/-05-/-May-/;s/-06-/-June-/;s/-07-/-July-/;s/-08-/-August-/;s/-09-/-September-/;s/-10-/-October-/;s/-11-/-November-/;s/-12-/-December-/;s/\(.*\)-\(.*\)-\(.*\)/\3 \2 \1/'` ; sed <setpci.man >setpci.8 "s/@TODAY@/$M/;s/@VERSION@/pciutils-3.8.0/;s#@IDSDIR@#/usr/local/share#;s#@PCI_IDS@#pci.ids.gz#"
M=`echo 2022-04-18 | sed 's/-01-/-January-/;s/-02-/-February-/;s/-03-/-March-/;s/-04-/-April-/;s/-05-/-May-/;s/-06-/-June-/;s/-07-/-July-/;s/-08-/-August-/;s/-09-/-September-/;s/-10-/-October-/;s/-11-/-November-/;s/-12-/-December-/;s/\(.*\)-\(.*\)-\(.*\)/\3 \2 \1/'` ; sed <pcilib.man >pcilib.7 "s/@TODAY@/$M/;s/@VERSION@/pciutils-3.8.0/;s#@IDSDIR@#/usr/local/share#;s#@PCI_IDS@#pci.ids.gz#"
M=`echo 2022-04-18 | sed 's/-01-/-January-/;s/-02-/-February-/;s/-03-/-March-/;s/-04-/-April-/;s/-05-/-May-/;s/-06-/-June-/;s/-07-/-July-/;s/-08-/-August-/;s/-09-/-September-/;s/-10-/-October-/;s/-11-/-November-/;s/-12-/-December-/;s/\(.*\)-\(.*\)-\(.*\)/\3 \2 \1/'` ; sed <pci.ids.man >pci.ids.5 "s/@TODAY@/$M/;s/@VERSION@/pciutils-3.8.0/;s#@IDSDIR@#/usr/local/share#;s#@PCI_IDS@#pci.ids.gz#"
sed <update-pciids.sh >update-pciids "s@^DEST=.*@DEST=/usr/local/share/pci.ids.gz@;s@^PCI_COMPRESSED_IDS=.*@PCI_COMPRESSED_IDS=1@"
chmod +x update-pciids
M=`echo 2022-04-18 | sed 's/-01-/-January-/;s/-02-/-February-/;s/-03-/-March-/;s/-04-/-April-/;s/-05-/-May-/;s/-06-/-June-/;s/-07-/-July-/;s/-08-/-August-/;s/-09-/-September-/;s/-10-/-October-/;s/-11-/-November-/;s/-12-/-December-/;s/\(.*\)-\(.*\)-\(.*\)/\3 \2 \1/'` ; sed <update-pciids.man >update-pciids.8 "s/@TODAY@/$M/;s/@VERSION@/pciutils-3.8.0/;s#@IDSDIR@#/usr/local/share#;s#@PCI_IDS@#pci.ids.gz#"
gzip -9n <pci.ids >pci.ids.gz
xueshanzhang@XUESHANs-MacBook-Pro pciutils-master % sudo make install
Password:
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C lib all
make[1]: Nothing to be done for `all'.
install -d -m 755 /usr/local/bin /usr/local/sbin /usr/local/share /usr/local/share/man/man8 /usr/local/share/man/man7 //usr/local/share/man/man5
install -c -m 755 -s lspci /usr/local/sbin
install -c -m 755 -s setpci /usr/local/sbin
install -c -m 755 update-pciids /usr/local/sbin
install -c -m 644 pci.ids.gz /usr/local/share
install -c -m 644 lspci.8 setpci.8 update-pciids.8 /usr/local/share/man/man8
install -c -m 644 pcilib.7 /usr/local/share/man/man7
install -c -m 644 pci.ids.5 /usr/local/share/man/man5

% lspci 
zsh: command not found: lspci

Did I miss anything?
Appreciate for your help.

setpci is unable to find a capability unless you include the index of the capability in the @ parameter or the capability is the first capability. index is incorrectly counting all capabilities instead of the one we want. The loop should look like this:

  for (c=d->first_cap; c; c=c->next)
    {
      if (c->type == type && c->id == id)
	{
	  if (target == index)
	    found = c;
          index++;
	}
    }

I have not found documentation with explanation of the meaning of Region X: lspci lines.

What kind of address should these lines contain?

Because for I/O ports there are at least 3 different type of addresses which belong to one I/O port mapping region:

• PCI bus address
• physical CPU address
• remapped CPU address

Probably on x86 systems they are same but e.g. on arm64 system they can be different.

Here is the output from Linux arm64 system on which PCI bus address = physical CPU address = 0xe8000000 and remapped CPU address = 0x0 for SATA controller add-on PCIe card which uses I/O ports. Output is different when called with and without -b.

lspci -vv
        Region 0: I/O ports at 1020 [size=8]
        Region 1: I/O ports at 1030 [size=4]
        Region 2: I/O ports at 1028 [size=8]
        Region 3: I/O ports at 1034 [size=4]
        Region 4: I/O ports at 1000 [size=32]
        Region 5: Memory at e9010000 (32-bit, non-prefetchable) [size=512]

lspci -vv -b
        Region 0: I/O ports at e8001020
        Region 1: I/O ports at e8001030
        Region 2: I/O ports at e8001028
        Region 3: I/O ports at e8001034
        Region 4: I/O ports at e8001000
        Region 5: Memory at e9010000 (32-bit, non-prefetchable)

Which means that lspci without -b prints different address type than with -b. It is expected behavior?

Should lspci without -b really prints remapped CPU address which is not used neither by PCI HW nor by CPU itself?

If yes, this should be documented, what lspci output means. If not, it should be fixed so same type of address is printed with or without -b.

In card resource file is this content:

/sys/bus/pci/devices/0000:03:00.0/resource
0x0000000000001020 0x0000000000001027 0x0000000000040101
0x0000000000001030 0x0000000000001033 0x0000000000040101
0x0000000000001028 0x000000000000102f 0x0000000000040101
0x0000000000001034 0x0000000000001037 0x0000000000040101
0x0000000000001000 0x000000000000101f 0x0000000000040101
0x00000000e9010000 0x00000000e90101ff 0x0000000000040200
0x00000000e9000000 0x00000000e900ffff 0x0000000000046200

In PCI config space this content:

03:00.0 
00: 21 1b 12 06 07 04 10 00 02 01 06 01 00 00 00 00
10: 21 10 00 e8 31 10 00 e8 29 10 00 e8 35 10 00 e8
20: 01 10 00 e8 00 00 01 e9 00 00 00 00 21 1b 60 10
30: 00 00 00 00 50 00 00 00 00 00 00 00 3a 01 00 00

And relevant lines from /proc/ioports and /proc/iomem:

/proc/ioports
00000000-00ffffff : pcie@d0070000
  00001000-00002fff : PCI Bus 0000:01
    00001000-00001fff : PCI Bus 0000:02
      00001000-00001fff : PCI Bus 0000:03
        00001000-0000101f : 0000:03:00.0
          00001000-0000101f : ahci
        00001020-00001027 : 0000:03:00.0
          00001020-00001027 : ahci
        00001028-0000102f : 0000:03:00.0
          00001028-0000102f : ahci
        00001030-00001033 : 0000:03:00.0
          00001030-00001033 : ahci
        00001034-00001037 : 0000:03:00.0
          00001034-00001037 : ahci

/proc/iomem
e9000000-efffffff : pcie@d0070000
  e9000000-e91fffff : PCI Bus 0000:01
    e9000000-e91fffff : PCI Bus 0000:02
      e9000000-e90fffff : PCI Bus 0000:03
        e9000000-e900ffff : 0000:03:00.0
        e9010000-e90101ff : 0000:03:00.0
          e9010000-e90101ff : ahci

On other arm64 setup where even PCI bus address and physical CPU address are different I verified that lspci with -b prints really PCI bus address.

Currently filtering with -d allows selection of vendor:device:class, but the class field is really "Class Code + Sub-Class Code", looking at the PCI spec.

In the case where, for example, we'd like to detect all mass storage controllers (of any type), this isn't currently possible

# lspci -n -d ::0104
18:00.0 0104: 1000:0016 (rev 01)

# lspci -n -d ::01
[no output]

As it doesn't seem particularly useful to filter only on subclass, could the syntax above be acceptable to pci_filter_parse_id()?

Variables with u32 type are currently printed via %u or %x format. This is incorrect because on C99 systems is u32 type aliased to C99 uint32_t type and for printing uint32_t type on C99 systems is required to use C99 PRIu32 constant. Same applies for non-C99 systems (e.g. Windows) for which pciutils defines appropriate u32 type.

On some systems is u32 type by pciutils defined as unsigned long and therefore %u or %x usage is incorrect.

Similar issue is with 64-bit types, on some systems it is unsigned long and on some other systems it is unsigned long long.

Incorrect usage of printf formats throws following -Wformat gcc warning (implicitly enabled by -Wall in top level Makefile):

lspci.c:453: warning: format ‘%04x’ expects type ‘unsigned int’, but argument 2 has type ‘pciaddr_t’

trying to setpci on device A (in this example: 0000:81:00.0)
setpci -A linux-sysfs -s 81:00.0 0.L

adding/removing unrelated devices will cause the setpci to fail.
for example, when adding and removing SRIOV devices on device B (commands in a loop for fast repro):
[root@localhost]$ for i in {0..99} ; do for j in 6 0 ; do echo $j > /sys/bus/pci/devices/0000:82:00.0/sriov_numvfs ; done ; done

[root@localhost]$ i=0 ; while [ 1 ] ; do echo -n "i=$i ; " ; setpci -A linux-sysfs -s 81:00.0 0.L ; if [ $? -ne 0 ] ; then break ; fi ; let i+=1 ; done
setpci on device A failing on the unrelated device B:
setpci: Cannot open /sys/bus/pci/devices/0000:82:00.5/resource: No such file or directory

Yeah .. looks like git version tag for 3.8.0 is missing in git repo 😃

Using x86_64-unknown-linux-gnu-gcc (crosstool-NG 1.24.0) 6.5.0

filter.c fails to compile:

make[2]: Entering directory '/home/dev/astlinux/trunk/output/build/pciutils-3.8.0/lib'
/home/dev/astlinux/trunk/output/host/usr/bin/x86_64-unknown-linux-gnu-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os  -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes -fPIC -fvisibility=hidden   -c -o init.o init.c
/home/dev/astlinux/trunk/output/host/usr/bin/x86_64-unknown-linux-gnu-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os  -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes -fPIC -fvisibility=hidden   -c -o access.o access.c
/home/dev/astlinux/trunk/output/host/usr/bin/x86_64-unknown-linux-gnu-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os  -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes -fPIC -fvisibility=hidden   -c -o generic.o generic.c
/home/dev/astlinux/trunk/output/host/usr/bin/x86_64-unknown-linux-gnu-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os  -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes -fPIC -fvisibility=hidden   -c -o dump.o dump.c
/home/dev/astlinux/trunk/output/host/usr/bin/x86_64-unknown-linux-gnu-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os  -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes -fPIC -fvisibility=hidden   -c -o names.o names.c
/home/dev/astlinux/trunk/output/host/usr/bin/x86_64-unknown-linux-gnu-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os  -Wall -W -Wno-parentheses -Wstrict-prototypes -Wmissing-prototypes -fPIC -fvisibility=hidden   -c -o filter.o filter.c
{standard input}: Assembler messages:
{standard input}:5: Error: multiple versions [`pci_filter_init@@LIBPCI_3.8'|`pci_filter_init@LIBPCI_3.3'] for symbol `pci_filter_init_v38'
{standard input}:7: Error: multiple versions [`pci_filter_parse_slot@@LIBPCI_3.8'|`pci_filter_parse_slot@LIBPCI_3.3'] for symbol `pci_filter_parse_slot_v38'
{standard input}:9: Error: multiple versions [`pci_filter_parse_id@@LIBPCI_3.8'|`pci_filter_parse_id@LIBPCI_3.3'] for symbol `pci_filter_parse_id_v38'
{standard input}:11: Error: multiple versions [`pci_filter_match@@LIBPCI_3.8'|`pci_filter_match@LIBPCI_3.3'] for symbol `pci_filter_match_v38'
make[2]: *** [<builtin>: filter.o] Error 1

I tried adding -std=c99 but that caused other errors.

Any help would be appreciated.

kernel.org/pub/software/utils/pciutils/ doesn't contain 3.9.0.
Please fix.

Hello, this is not a problem with pciutils, but rather another "help wanted" question, which, however, I hope wouldn't be too burdensome to answer for the who involved in lspci development and know it in depth.

lspci is capable to show physical slot number in the verbose presentation:

I'd like to find out how it does it. I am going to apply this method in the driver that I would like to modify, so it would enumerate the devices (with the same ID) and disambiguate the device files according to physical slot. Like /dev/device__physslot_ . The driver will run on Ubuntu 18

I tried to dig in the source code. I found the relevant line 775 in https://github.com/pciutils/pciutils/blob/master/lspci.c :

if (p->phy_slot)
    printf("\tPhysical Slot: %s\n", p->phy_slot);

p is struct pci_dev. That had been quite confusing because standard linux/pci.h does not have field phy_slot until I figured out that is their own (re)definition

The structure is filled by the function

int
pci_fill_info_v38(struct pci_dev *d, int flags)
{
  unsigned int uflags = flags;
  if (uflags & PCI_FILL_RESCAN)
    {
      uflags &= ~PCI_FILL_RESCAN;
      pci_reset_properties(d);
    }
  if (uflags & ~d->known_fields)
    d->methods->fill_info(d, uflags);
  return d->known_fields;
}

fill_info is a function pointer defined in https://github.com/pciutils/pciutils/blob/master/lib/internal.h (line 44)

And that's where I lost track.

So I am interested in code that could retrieve the physical slot number on Ubuntu 18

Broken Link: http://www.internals.com/ mentioned in README.Windows

Hi,

I have previously been able to build the pcilib shared library on Solaris (11.4 with latest SRU 11.4.32.88.3) but I am having issues building pcilib 3.7.0. I can build lspci and setpci as static binaries fine, but building the shared library results in a library that seems to not work.

linking lspci against it results it undefined symbol errors:

gcc lspci.o ls-vpd.o ls-caps.o ls-caps-vendor.o ls-ecaps.o ls-kernel.o ls-tree.o ls-map.o common.o lib/libpci.so.3.7.0 -o lspci
Undefined first referenced
symbol in file
pci_filter_init lspci.o
pci_filter_match lspci.o
pci_fill_info lspci.o
pci_init lspci.o
pci_filter_parse_slot lspci.o
pci_filter_parse_id lspci.o
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
gmake: *** [Makefile:99: lspci] Error 1

Any clues as to what debugging steps I should perform would be greatly appreciated.

Regards,
Richard

Today I cloned the repo in Cygwin and received the following warning. Hopefully this will be an easy fix.

warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

'maint/RELEASE'
'maint/release'

Only the "release" file was present in my working tree.

I've been using this utility with Linux for some time and I think I've found a memory leak using Valgrind on the example.c program. I think the pci_cleanup(...) command doesn't fully free all memory used by the pci_alloc(...) pci_init(...) and pci_scan_bus(...). Valgrind points to memory allocated with pci_scan_bus(...).

The output of valgrind is as follows:

vg_out.txt

Apology if this has been previously reported.
In the case of large BAR window sizes where the lower half of the BAR is all zero.
I have been noticing for a while that lspci, in verbose formatted listings of the PCI header,
these large BARs are always listed as being virtual. Which is not actually the case.
I have a suspicion that the behavior might be due to the expression around
lspci.c:426 , in show_bases()
I mean, at first glance I was thinking that the code might be making this decision solely
using the low half of the BAR; and it doesn't see whether the upper half is assigned non-zero.

  else if (pos && !(flg & ((flg & PCI_BASE_ADDRESS_SPACE_IO) ? PCI_BASE_ADDRESS_IO_MASK : PCI_BASE_ADDRESS_MEM_MASK)))
{
  /* Reported by the OS, but not by the device */
  printf("[virtual] ");
  flg = pos;
  virtual = 1;
}

Further details that might be helpful, for description of the issue --

root@here:/# setpci -d ::_class_ 14.L
0000000c
0000000c
  ( ... )

root@here:/# setpci -d ::_class_ 18.L
00000640
00000360
  ( ... )

root@here:/# lspci -xs 7:0.0
07:00.0 My Class: My Corporation Device _xx_ (rev a1)
00: xx xx xx xx 06 04 10 00 a1 00 xx xx 10 00 00 00
10: 00 00 00 f8 0c 00 00 00 60 04 00 00 0c 00 00 6e
  ( ... )

root@here:/# cat /sys/bus/pci/devices/0000:07:00.0/resource
0x00000000f8000000 0x00000000f8ffffff 0x0000000000040200
0x0000046000000000 0x0000046_xx_fffff 0x000000000014220c
  ( ... )

root@here:/# grep '07:00' /proc/iomem
          f8000000-f8ffffff : 0000:07:00.0
          46000000000-46_xx_fffff : 0000:07:00.0
            ( ... )

root@here:/# lspci -d ::_class_ -vs 7:
07:00.0 My Class: My Corporation Device _xx_ (rev a1)
        Subsystem: My Corporation Device _yy_
        Flags: bus master, fast devsel, latency 0, IRQ 62, NUMA node 0
        Memory at f8000000 (32-bit, non-prefetchable) [size=16M]
        [virtual] Memory at 46000000000 (64-bit, prefetchable) [size=_some_G]
  ( ... )

root@here:/# lspci -vvd ::_class_ | grep -i "^[       ]region 1"
        Region 1: [virtual] Memory at 46000000000 (64-bit, prefetchable) [size=_some_G]
        Region 1: [virtual] Memory at 44000000000 (64-bit, prefetchable) [size=_some_G]
          ( ... )

root@here:/# lspci --version
lspci version 3.6.2
root@here:/# setpci --version
setpci version 3.6.2

root@here:/# lsb_release -a
LSB Version:    core-11.0.1ubuntu1-noarch:security-11.0.1ubuntu1-noarch
Distributor ID: Ubuntu
Description:    Ubuntu 19.10
Release:        19.10
Codename:       eoan

root@here:/# dpkg -l pciutils
  ( ... )
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  pciutils       1:3.6.2-2    amd64        PCI utilities