pci: Add helper routines to iterate over a device's BARs.

Reviewed by: imp, markj, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3

pci: Add helper routines to iterate over a device's BARs.

Reviewed by: imp, markj, emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36237

show more ...

ddb: annotate some commands with DB_CMD_MEMSAFE

This is not completely exhaustive, but covers a large majority of
commands in the tree.

Reviewed by: markj
Sponsored by: Juniper Networks, Inc.
Spons

ddb: annotate some commands with DB_CMD_MEMSAFE

This is not completely exhaustive, but covers a large majority of
commands in the tree.

Reviewed by: markj
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D35583

show more ...

pci(4): Fix a common typo in source code comments

- s/transistions/transitions/

MFC after: 3 days

pci: Remove unused devclass arguments to DRIVER_MODULE.

pci: recognize "non-essential instrumentation" devices

Some AMD EPYC VCPUs generated boot message of the type:

pci4: <unknown> at device 0.0 (no driver attached)

These are displayed for devic

pci: recognize "non-essential instrumentation" devices

Some AMD EPYC VCPUs generated boot message of the type:

pci4: <unknown> at device 0.0 (no driver attached)

These are displayed for device class 0x13 devices, e.g.:

none8@pci0:130:0:0: class=0x130000 rev=0x00 hdr=0x00 vendor=0x1022 \
device=0x148a subvendor=0x1022 subdevice=0x148a
vendor = 'Advanced Micro Devices, Inc. [AMD]'
device = 'Starship/Matisse PCIe Dummy Function'
class = non-essential instrumentation

Since these devices serve no purpose (no driver attaches) I have
enabled the reporting of suich devices only for verbose boots (a
diversion from the patch provided in the PR).

A verbose boot will now display such devices as:

pci4: <non-essential instrumentation> at device 0.0 (no driver attached)

PR: 263469
Reported by: jfc@mit.edu (John F. Carr)
MFC after: 1 week

show more ...

Mark cfg as __unused to avoid ifdef soup

Sponsored by: Netflix

pci: Add arbitrary locator support to pci.

If the pciX:Y:Z and pciW:X:Y:Z 'at' locations don't work, allow try the
LOCATOR:PATH syntax. Use dev_wired_cache to generically look them up.

Sponsored by

pci: Add arbitrary locator support to pci.

If the pciX:Y:Z and pciW:X:Y:Z 'at' locations don't work, allow try the
LOCATOR:PATH syntax. Use dev_wired_cache to generically look them up.

Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D32784

show more ...

pci: switch logic a little

If we find a match, then assign it. Flip the logic in the if and assign
the unit rather than continuing if it doesn't match. Will make it easier
to expand to other matchin

pci: switch logic a little

If we find a match, then assign it. Flip the logic in the if and assign
the unit rather than continuing if it doesn't match. Will make it easier
to expand to other matching schemes.

Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D32779

show more ...

Add UEFI locator for bus_get_device_path, pci acpi

Add a UEFI locator type. It prints the UEFI device names for a FreeBSD
device_t name. It works with PCI and ACPI device nodes. USB forthcoming.

Sp

Add UEFI locator for bus_get_device_path, pci acpi

Add a UEFI locator type. It prints the UEFI device names for a FreeBSD
device_t name. It works with PCI and ACPI device nodes. USB forthcoming.

Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D32749

show more ...

dev/pci: fix potential panic due to bogus VPD data

A panic has been observed on a system with a Intel X520 dual LAN
device. The panic is caused by a KASSERT() noticing that the amount
of VPD data co

dev/pci: fix potential panic due to bogus VPD data

A panic has been observed on a system with a Intel X520 dual LAN
device. The panic is caused by a KASSERT() noticing that the amount
of VPD data copied out to the pciconf command does not match the
amount of data read from the device.

The cause of the size mismatch was VPD data that started with 0x82,
the VPD tag that indicates that a VPD ident follows, but with a length
of more than 255 characters, which happens to be the maximum ident
size supported by the API between kernel and the pciconf program.
The data provided did not resemble an actual VPD identifier, and it
can be assumed that the initial tag value 0x82 happens to be there
by accident.

An ident size of 255 far exceeds the sensible length of that data
element, which is in the order of at most 30 to 40 bytes.

This patch adds several consitstency checks to the VPD parser, the
most critical being that ident lengths of more than 255 bytes are
rejected. Other checks reject VPD with more than one ident tag or
with an empty (zero length) ident string.

This patch prevents the panic that occured when "pciconf -lV" was
executed on the affected system.

During the anaylsis of the issue and the VPD code it has been
found that the VPD parser uses a state machine that accepts tags
in any order and combination. This is a bad match for the actual
VPD data, which has a very simple structure that can be parsed
with a non-recursive direct descent parser (which always knows
exactly which token to expect next).

A review fpr a much simpler VPD parser that performs many more
consistency checks and rejects invalid VPD has been proposed in
review https://reviews.freebsd.org/D34268.

Reported by: mikej at paymentallianceintl.com (Michael Jung)
Approved by: jhb
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D34255

show more ...

pci: Don't try to read cfg registers of non-existing devices

Instead of returning 0xffs some controllers, such as Layerscape generate
an external exception when someone attempts to read any register

pci: Don't try to read cfg registers of non-existing devices

Instead of returning 0xffs some controllers, such as Layerscape generate
an external exception when someone attempts to read any register
of config space of a non-existing device other than PCIR_VENDOR.
This causes a kernel panic.
Fix it by bailing during device enumeration if a device vendor register
returns invalid value. (0xffff)
Use this opportunity to replace some hardcoded values with a macro.

I believe that this change won't have any unintended side-effects since
it is safe to assume that vendor == 0xffff -> hdr_type == 0xffff.

Sponsored by: Alstom
Obtained from: Semihalf
Reviewed by: jhb
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D33059

show more ...

pci: Implement pci_bar_enabled() for SR-IOV VFs

In a VF's configuration space, "memory space enable" is hard-wired to 0,
so the existing implementation always returns false. We need to read
the SR-

pci: Implement pci_bar_enabled() for SR-IOV VFs

In a VF's configuration space, "memory space enable" is hard-wired to 0,
so the existing implementation always returns false. We need to read
the SR-IOV control register from the PF device to get the value of the
MSE bit.

Fix pci_bar_enabled() to read this register instead for VFs. I don't
see any way to access the PF's config space without a backpointer in the
pci device ivars, so I added one.

This fixes a regression where bhyve(8) fails to map the MSI-X table
after commit 7fa233534736 ("bhyve: Map the MSI-X table unconditionally
for passthrough") when a VF is passed through, since with that commit we
use PCIOCBARMMAP to map the table and that ioctl always fails for VFs
without this change. As a bonus, pciconf(8) now correctly reports the
enablement of BARs for VFs.

Reported and tested by: Raúl Muñoz <raul.munoz@custos.es>
Reviewed by: rstone, jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32839

show more ...

LinuxKPI: Support lazy BAR allocation

Linux KPIs like pci_resource_start/len assume that BARs have been
allocated, but FreeBSD lazily allocates BARs if it cannot allocate the
firmware-allocated BARs

LinuxKPI: Support lazy BAR allocation

Linux KPIs like pci_resource_start/len assume that BARs have been
allocated, but FreeBSD lazily allocates BARs if it cannot allocate the
firmware-allocated BARs. Thus using the Linux KPIs must force allocation
of the BARs rather than returning 0 for the start and length, which can
crash drm-kmod drivers that assume the BARs are valid. This is needed
for the AMDGPU driver to be able to attach on SiFive's HiFive Unmatched.

Reviewed by: hselasky, jhb, mav
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D32447

show more ...

newbus: Move from bus_child_{pnpinfo,location}_src to bus_child_{pnpinfo,location} with sbuf

Now that the upper layers all go through a layer to tie into these
information functions that translates

newbus: Move from bus_child_{pnpinfo,location}_src to bus_child_{pnpinfo,location} with sbuf

Now that the upper layers all go through a layer to tie into these
information functions that translates an sbuf into char * and len. The
current interface suffers issues of what to do in cases of truncation,
etc. Instead, migrate all these functions to using struct sbuf and these
issues go away. The caller is also in charge of any memory allocation
and/or expansion that's needed during this process.

Create a bus_generic_child_{pnpinfo,location} and make it default. It
just returns success. This is for those busses that have no information
for these items. Migrate the now-empty routines to using this as
appropriate.

Document these new interfaces with man pages, and oversight from before.

Reviewed by: jhb, bcr
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D29937

show more ...

Set PCIe device's Max_Payload_Size to match PCIe root's.

Usually on boot the MPS is already configured by BIOS. But we've
found that on hot-plug it is not true at least for our Supermicro
X11 board

Set PCIe device's Max_Payload_Size to match PCIe root's.

Usually on boot the MPS is already configured by BIOS. But we've
found that on hot-plug it is not true at least for our Supermicro
X11 boards. As result, mismatch between root's configuration of
256 bytes and device's default of 128 bytes cause problems for some
devices, while others seem to work fine.

MFC after: 1 month
Sponsored by: iXsystems, Inc.

show more ...

pci: enhance printf for leaked MSI[-X] vectors

When debugging leaked MSI/MSI-X vectors through LinuxKPI I found
the informational printf unhelpful. Rather than just stating we
leaked also tell how

pci: enhance printf for leaked MSI[-X] vectors

When debugging leaked MSI/MSI-X vectors through LinuxKPI I found
the informational printf unhelpful. Rather than just stating we
leaked also tell how many MSI or MSI-X vectors we leak.

Sponsored-by: The FreeBSD Foundation
Reviewed-by: jhb
MFC-after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D29394

show more ...

Implement pci_get_relaxed_ordering_enabled() helper function.

Discussed with: kib@
MFC after: 1 week
Sponsored by: Mellanox Technologies // NVIDIA Networking

pci: Add pci_find_class_from

pci_find_class_from help finding one or multiple device matching
a class and subclass.
If the from argument is not null we will first loop in the device list
until we fi

pci: Add pci_find_class_from

pci_find_class_from help finding one or multiple device matching
a class and subclass.
If the from argument is not null we will first loop in the device list
until we find the matching device and only then start to check if the
class/subclass matches.

Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D27549

show more ...

Rename kernel option ACPI_DMAR to IOMMU.
This is mostly needed for a common arm64/amd64 iommu code.

Reviewed by: kib
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D265

Rename kernel option ACPI_DMAR to IOMMU.
This is mostly needed for a common arm64/amd64 iommu code.

Reviewed by: kib
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D26587

show more ...

o Rename acpi_iommu_get_dma_tag() -> iommu_get_dma_tag().
This function isn't ACPI dependent and we may use it on FDT systems
as well.
o Don't repeat the function declaration, include iommu.h ins

o Rename acpi_iommu_get_dma_tag() -> iommu_get_dma_tag().
This function isn't ACPI dependent and we may use it on FDT systems
as well.
o Don't repeat the function declaration, include iommu.h instead.

Reviewed by: andrew, kib
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D26584

show more ...

pci: clean up empty lines in .c and .h files

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)

Merge ^/head r363583 through r364040.

Enable hw.pci.enable_aspm tunable by default.

While effects on power saving is only a guess, effects on hot-plug are
clearly visible. Lets try to enable it and see what happen.

MFC after: 3 months

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)