Pali Rohár [Sun, 26 Dec 2021 23:34:08 +0000 (00:34 +0100)]
lspci: Show Slot Power Limit values above EFh
PCI Express Base Specification rev. 3.0 has the following definition for
the Slot Power Limit Value:
=======================================================================
When the Slot Power Limit Scale field equals 00b (1.0x) and Slot Power
Limit Value exceeds EFh, the following alternative encodings are used:
F0h = 250 W Slot Power Limit
F1h = 275 W Slot Power Limit
F2h = 300 W Slot Power Limit
F3h to FFh = Reserved for Slot Power Limit values above 300 W
=======================================================================
Replace function power_limit() by show_power_limit() which also prints
power limit value. Show reserved value as string ">300W".
Pali Rohár [Sun, 26 Dec 2021 22:47:03 +0000 (23:47 +0100)]
libpci: Fix intel_sanity_check() function
Function intel_sanity_check() calls conf1_read() which access d->domain
field. But intel_sanity_check() does not initialize this field and so
conf1_read() access some random data on stack.
Tests showed that intel_sanity_check() always fails as in d->domain is
stored some non-zero number.
Fix this issue by zeroing struct pci_dev d in intel_sanity_check() as
sanity check is verifying PCI devices at domain 0.
Pali Rohár [Sun, 26 Dec 2021 22:04:03 +0000 (23:04 +0100)]
lspci: Print buses of multibus PCI domain in ascending order
Currently PCI domains are printed in ascending order. Devices on each PCI
bus are also printed in ascending order. PCI buses behind PCI-to-PCI
bridges are also printed in ascending order.
But buses of PCI domain are currently printed in descending order because
function new_bus() puts newly created bus at the beginning of linked list.
In most cases PCI domain contains only one (top level) bus, so in most
cases it is not visible this inconsistency.
Multibus PCI domains (where PCI domain contains more independent top level
PCI buses) are available on ARM devices.
This change fixes print order of multibus PCI domains, so also top level
PCI buses are printed in ascending order, like PCI buses behind PCI-to-PCI
bridges.
Pali Rohár [Mon, 20 Dec 2021 15:56:59 +0000 (16:56 +0100)]
dump: Allow more leading zeros in dump line number
U-Boot's "pci display.b" command prints pci config space dump with 8 digits
in line number. So allow up to the 8 digits in line number to easily parse
U-Boot's pci config space dumps.
Pali Rohár [Sun, 26 Dec 2021 17:48:00 +0000 (18:48 +0100)]
win32: Remove old config.h and config.mk files
These files are old and cannot be used for compiling pcitutils anymore
(e.g. they use non-existent option TOOLPREFIX). As configure script now
works fine also for Windows build, remove these old win32 config files.
Pali Rohár [Sun, 26 Dec 2021 17:44:44 +0000 (18:44 +0100)]
Makefile: Add new option COMPAT_GETOPT
This new option controls if compat/getopt.c should be compiled and linked
into lspci and setpci binaries. Useful for ancient platforms.
For example it is required to set COMPAT_GETOPT=yes for all versions of
MinGW32 with CRTDLL (as this MinGW32 variant does not have linkable
getopt() implementation). And also for MinGW32 with MSVCRT older than 3.0.
Pali Rohár [Sun, 26 Dec 2021 17:42:35 +0000 (18:42 +0100)]
Makefile: Append EXEEXT variable to executable filename rules
If x86_64-w64-mingw32-gcc compiler is called with -o filename option
without any file extension then compiler automatically appends suffix
".exe" to output filename.
This behavior of x86_64-w64-mingw32-gcc compiler basically breaks pattern
rule of type '%: %.o' as x86_64-w64-mingw32-gcc compiler cannot generate
arbitrary output file via -o option just by stripping .o extension from
filename.
When generating executables by x86_64-w64-mingw32-gcc compiler it is
really the best option to specify .exe suffix in -o option.
So introduce a new makefile variable EXEEXT which will be automatically
appended to any executable filename. For Windows and DOS systems set it
to ".exe". For other systems set it just to empty string "".
GNU automake uses same makefile variable for same purpose.
Pali Rohár [Sun, 26 Dec 2021 18:06:53 +0000 (19:06 +0100)]
libpci: For PCI_OS_WINDOWS allows to load pci.ids from executable directory
For Windows applications it is common to have all support data files in the
same directory where is stored executable itself, instead of in directory
hardcoded at compile time.
When PCI_PATH_IDS_DIR is set to "." it means that pci.ids file is located
in the current working directory. This is also unsuitable for Windows
command line applications stored in %PATH% because cmd.exe starts in some
default user or system location.
Adds a new option to allow specifying PCI_PATH_IDS_DIR to empty string ""
and for PCI_OS_WINDOWS platform it would mean to locate pci.ids file in the
same directory where is stored currently running executable. On Windows it
is always possible to detected this directory.
Pali Rohár [Sat, 25 Dec 2021 14:52:20 +0000 (15:52 +0100)]
libpci: i386-io-windows.h: Enable I/O access via native NT ProcessUserModeIOPL syscall
libpci uses WinIo library from http://www.internals.com/ which is archived
at https://web.archive.org/web/20151005172744/http://www.internals.com/
This external WinIo library has two big issues:
1. Library license is incompatible with pciutils license.
2. It silently and automatically installs 3rd-party NT kernel module
WinIo.sys which is bundled in WinIO.dll binary.
That NT kernel module creates a device file "\\.\WinIo" which can be opened
by any running process. Via this device file can any process (including
unprivileged or those running under Guest account) ask that kernel module
to configure x86 TSS I/O port permissions for access to any I/O port. That
NT kernel module does not implement any permission checks and automatically
accept all requests.
Change in this commit replaces insecure WinIO.dll library and WinIo.sys
kernel module by proper NT system solution: Usage of ProcessUserModeIOPL
syscall (equivalent of iopl(3) on Linux) which is supported directly by NT
kernel. It does not require any external 3rd-party library or NT kernel
module.
This syscall can be invoked by NtSetInformationProcess() function from
ntdll.dll library (which is part of NT system) and for privileged processes
kernel changes x86 IOPL to 3.
Privileged process is that which has SeTcbPrivilege (Act as part of the
operating system privilege) or is running under account from local
Administrators group with SeImpersonatePrivilege (Impersonate a client
after authentication privilege). SeImpersonatePrivilege is enabled by
default for accounts from local Administrators group.
Usage of privileges is not easy operation and needs to call lot of
functions to gain required permissions, achieve thread-safety and follow
suggested guidelines. Hence code is quite long.
Privileges (including SeTcbPrivilege) can be enabled / disabled in User
Accounts settings by local Administrators and change takes effect after
next login, not immediately.
Pali Rohár [Sat, 25 Dec 2021 12:45:28 +0000 (13:45 +0100)]
libpci: i386-io-windows.h: Fix definitions of I/O port functions for UCRT, CRTDLL and for 64-bit mode
Functions _outp(), _outpw(), _outpd(), _inp(), _inpw() and _inpd() are
available only in 32-bit version of the old MSVCRT library. They are not
available in 64-bit version of old MSVCRT library and neither the oldest
CRTDLL library or in new UCRT library.
Function prototypes for 32-bit mode should be available in <conio.h> header
file. But they are missing in some MinGW toolchains.
For 64-bit mode I/O port functions are defined only as inline functions or
intrinsics macros in <intrin.h> header file but under different names:
__outbyte(), __outword(), __outdword(), __inbyte(), __inword(), __indword()
This header file is available also in UCRT-compatible compilers.
When compiling with the oldest CRTDLL library and not using <intrin.h>
header file, it is required to provide own implementation of these
functions. Do it via inline assembly.
With this change it is possible to compile i386-io-windows.h with all
combination of toolchains, compilers, crt library and arch mode.
The most important is the fix to allow compilation with modern UCRT
library.
Gustavo Pimentel [Wed, 18 Nov 2020 22:56:52 +0000 (23:56 +0100)]
lspci: Add PCIe 6.0 data rate (64 GT/s) support
This enables "lspci" to show PCIe 6.0 data rate (64 GT/s) properly
according to the contents in register PCI_EXP_LNKCAP, PCI_EXP_LNKSTA
and PCI_EXP_LNKCTL2.
configure: Support cross-building for GNU/kFreeBSD
We need to set a sys variable matching what would be found in the GNU
triplet for the GNU/kFreeBSD architecture, otherwise the later code will
not match correctly.
Sean V Kelley [Wed, 24 Jun 2020 22:39:40 +0000 (15:39 -0700)]
pciutils: Add decode support for RCECs
Root Complex Event Collectors provide support for terminating error
and PME messages from RCiEPs. This patch provides basic decoding for
the lspci RCEC Endpoint Association Extended Capability. See PCIe 5.0-1,
sec 7.9.10 for further details.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Sean V Kelley <sean.v.kelley@linux.intel.com>
Martin Mares [Sun, 31 May 2020 10:24:41 +0000 (12:24 +0200)]
Hurd: Do not identify devices during scan
Let us keep the bus scan light-weight. Whoever is interested
in device IDs, still has to call pci_fill_info(PCI_FILL_IDENT),
which handles this in generic way.
Martin Mares [Mon, 25 May 2020 13:28:33 +0000 (15:28 +0200)]
Library: Handle domains in all back-ends
Even if the back-end does not implement multiple domains, it can
be called on a device in a non-zero domain if the use obtained the
device by calling pci_get_dev() instead of scanning the bus.
In all such cases, report that 0 bytes were read/written.
Martin Mares [Mon, 25 May 2020 13:10:07 +0000 (15:10 +0200)]
Library: Big cleanup of pci_fill_info()
There was a lot of minor issues in the implementation of the fill_info
call-back in various back-ends. Most importantly, semantics of pci_dev->
known_fields was not formally defined and it was implemented inconsistently.
We now define known_fields as the set of fields which were already
obtained during the lifetime of the pci_dev. We never consider known
fields which are not supported by the back-end. All fields which are
unsupported by either the back-end, the OS, or the particular device,
are guaranteed to have sensible default values (0 or NULL). Also, bit
masks are always unsigned except for the signature of pci_fill_info()
which should be preferably kept stable.
All back-ends and the pci_generic_fill_info() function have been changed
to follow this semantics.
In the sysfs back-end, we read as few attributes as possible during
device initialization, so applications which use pci_get_dev() are not
slowed down unnecessarily.
In the Hurd back-end, we also respect the buscentric mode.
Martin Mares [Mon, 25 May 2020 10:26:07 +0000 (12:26 +0200)]
lspci: Generelized decoding of DVSEC extended capability
We decode the DVSEC capability header first. If we recognize the vendor
and ID (and the length is at least the minimum we need), we call
a specific function to interpret the rest of the capability.
Sean V Kelley [Mon, 20 Apr 2020 22:14:44 +0000 (15:14 -0700)]
pciutils: Decode Compute eXpress Link DVSEC
Compute eXpress Link[1] is a new CPU interconnect created with
workload accelerators in mind. The interconnect relies on PCIe
electrical and physical interconnect for communication via a Flex Bus
port which allows designs to choose between providing PCIe or CXL.
This patch introduces basic support for lspci decode of CXL and
builds upon the existing Designated Vendor-Specific support in
lspci through identification of a supporting CXL device using DVSEC
Vendor ID and DVSEC ID.
[1] https://www.computeexpresslink.org/
Signed-off-by: Sean V Kelley <sean.v.kelley@linux.intel.com>
Bjorn Helgaas [Thu, 21 May 2020 22:40:29 +0000 (17:40 -0500)]
lspci: Decode PCIe Link Capabilities 2, expand Link Status 2
Decode Link Capabilities 2, which includes the Supported Link Speeds
Vector, and decode more fields of Link Status 2.
The test case (data from https://bugzilla.kernel.org/show_bug.cgi?id=206837
comment #21) includes a Thunderbolt Downstream Port that advertises
2.5-8GT/s support in Link Capabilities 2.
Martin Mares [Wed, 22 Jan 2020 08:15:29 +0000 (09:15 +0100)]
Cleaned up dumping of I/O and memory regions
Originally, I wanted to fix a bug, which caused 64-bit addresses
with their lower 32 bits zero to be reported as virtual regions.
However, it turned out that the whole function is quite messy,
so I rewrote it.
Also, we now print "[virtual]" and "[enhanced]" after the base address
along other modifiers.
Kelsey Skunberg [Wed, 19 Jun 2019 16:48:58 +0000 (10:48 -0600)]
lspci: Change output for bridge with empty range to "[disabled]"
Change output displayed for memory behind bridge when the range is
empty to be consistent between each verbosity level. Replace "None" and
"[empty]" with "[disabled]". Old and new output examples listed below
for each verbosity level.
Show_range() is not called unless verbose == true. No output given
unless a verbose argument is provided.
OLD output for -v and -vv which uses "None" and -vvv uses "[empty]":
Kelsey Skunberg [Wed, 19 Jun 2019 16:48:57 +0000 (10:48 -0600)]
lspci: Remove unnecessary !verbose check in show_range()
Remove 'if (!verbose)' code in show_range() due to not being called.
show_range() will only be called when verbose is true. Additional call
to check for verbosity within show_range() is dead code.
!verbose was used so nothing would print if the range behind a bridge
had a base > limit and verbose == false. Since show_range() will not be
called when verbose == false, not printing bridge information is
still accomplished.
Bjorn Helgaas [Fri, 17 May 2019 18:40:22 +0000 (13:40 -0500)]
lspci: Reorder Express Root Complex registers to Cap, Ctl, Sta
Registers in the PCI Express Capability come in sets of three (Capability,
Control, Status), and we typically print them in that order. The Root
Complex-related registers were an exception: we printed them in the
(Control, Capability, Status) order.
Decode the RootCap, RootCtl, and RootSta registers in the usual order.
This enables "lspci" to show PCIe 5.0 data rate (32 GT/s) properly
according to the contents in register PCI_EXP_LNKCAP, PCI_EXP_LNKSTA
and PCI_EXP_LNKCTL2.