Allow iovctl to create VFs that are restricted to specific VLAN IDs.
Reviewed by: kib, np
MFC after: 2 weeks
Sponsored by: Orange Business Services
Differential Revision: https://reviews.freebsd.org/D45402
For activate/deactivate resource, use a more standard check at the
start of the function since the addition of the PCI_IOV code made this
more complex. For the three recently added methods, just add the
typical check at the beginning that I missed.
This wasn't always fatal as if your system only had PCI device_t's as
children of PCI bus devices it would happen to work ok, but if you
have a non-PCI child device (e.g. an ATA channel) then dereferencing
ivars for non-direct-children could fault.
Reported by: Cirrus-CI (via emaste)
Reviewed by: emaste
Fixes: 871b33ad65 pci: Consistently use pci_vf_* for suballocated VF memory resources
Differential Revision: https://reviews.freebsd.org/D45499
`argsp` is not defined in `generic_pcie_unmap_resource(..)`. Remove the
parameter passed to `bus_generic_unmap_resource(..)` as this parameter
is never passed to `generic_pcie_unmap_resource(..)`.
Fixes: 98056127dd ("acpi/pci/vmd: Fix a nit with nested resource mapping requests")
Reported by: Jenkins (aarch64, armv6, armv7, etc)
Differential Revision: https://reviews.freebsd.org/D45493
Some of the bus resource methods were passing these up to the parent
which triggered rman mismatch assertions in INVARIANTS kernels.
Reported by: kp
Reviewed by: imp
Tested by: kp (earlier version)
Differential Revision: https://reviews.freebsd.org/D45406
Some bus drivers use rmans to suballocate resources to child devices.
When the driver for a child device requests a mapping for a
suballocated resource, the bus driver translates this into a mapping
request for a suitable subrange of the original resource the bus
driver allocated from its parent. This nested mapping request should
look like any other resource mapping request being made by the bus
device (i.e. as if the bus device had called bus_map_resource() or
bus_alloc_resource() with RF_ACTIVE).
I had slightly flubbed this last bit though since the direct use of
bus_generic_map/unmap_resource passed up the original child device
(second argument to the underlying kobj interface). While this is
currently harmless, it is not strictly correct as the resource being
mapped is owned by the bus device, not the child and can break for
other bus drivers in the future.
Instead, use bus_map/unmap_resource for the nested request where the
requesting device is now the bus device that owns the parent resource.
Reviewed by: imp
Fixes: 0e1246e334 acpi: Cleanup handling of suballocated resources
Fixes: b377ff8110 pcib: Refine handling of resources allocated from bridge windows
Fixes: d79b6b8ec2 pci_host_generic: Don't rewrite resource start address for translation
Fixes: d714e73f78 vmd: Use bus_generic_rman_* for PCI bus and memory resources
Differential Revision: https://reviews.freebsd.org/D45433
In pci_host_generic_acpi.c we loop over pci_acpi_quirks to check if
we need to handle any quirks. GCC doesn't like the terminatin as it
sets a fixed width string to 0.
As this the array is only ever used in this file change to use nitems
to find when to stop the loop.
Reviewed by: brooks, imp, jhb, emaste
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45265
QEMU for armv7 includes a PCI memory range whose CPU address is
greater than 4GB. This falls outside the range of armv7's global
mem_rman used by the nexus driver. As a result, pcib0 fails to
attach blocking all PCI devices.
Instead, change the driver to be a bit more tolerant. If allocating a
resource for a range fails, don't fail attaching the entire driver,
but do skip adding the associated PCI range to the relevant rman in
the pcib driver. This will prevent child devices from using BARs that
allocate from this range. In the case of QEMU on armv7 devices can
still allocate from an earlier PCI memory range that is within the
32-bit address space (and in fact none of the firmware-assigned memory
BARs use addresses from the upper range).
While here, reorder the operations on I/O ranges a bit: 1) print the
range under bootverbose first (rather than last) so that the range is
printed before any relevant errors for the range, 2) move
rman_manage_region last after the parent resource has been set and
allocated.
Reported by: markj, Jenkins
Reviewed by: markj
Fixes: d79b6b8ec2 pci_host_generic: Don't rewrite resource start address for translation
Differential Revision: https://reviews.freebsd.org/D44698
The public bus_release_resource() API still accepts both forms, but
the internal kobj method no longer passes the arguments.
Implementations which need the rid or type now use rman_get_rid() or
rman_get_type() to fetch the value from the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44131
The public bus_activate/deactivate_resource() API still accepts both
forms, but the internal kobj methods no longer pass the arguments.
Implementations which need the rid or type now use rman_get_rid() or
rman_get_type() to fetch the value from the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44130
The public bus_map/unmap_resource() API still accepts both forms, but
the internal kobj methods no longer pass the argument.
Implementations which need the type now use rman_get_type() to fetch
the value from the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44129
The public bus_adjust_resource() API still accepts both forms, but the
internal kobj method no longer passes the argument. Implementations
which need the type now use rman_get_type() to fetch the value from
the allocated resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44128
Use rman_set_type to set the type of allocated resources everywhere
rman_set_rid is currently called.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44123
Inline generic_pcie_translate_resource_common into its sole caller.
No functional change.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D44206
The generic_pcie_containing_range helper added in commit d79b6b8ec2
assumed that the passed in (start, end) range used to locate the
containing mapping range was a valid address range (with end >=
start). The previous version of
generic_pcie_translate_resource_common only used the start address to
locate a mapping range, so the end address of 0 did not matter, but an
end of 0 now causes the first range to match and an incorrect
translation for resources using a later range.
PR: 277211
Reported by: dch, tuexen
Reviewed by: tuexen
Fixes: d79b6b8ec2 pci_host_generic: Don't rewrite resource start address for translation
Differential Revision: https://reviews.freebsd.org/D44205
Previously ranges were only enumerated for the FDT attachment but not
ACPI. This commit moves the enumeration to the shared attach routine
so it is done for both. While here, don't list empty ranges but do
include the resource type for each range.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D44132
Unlike other bus methods updated to use bus_generic_rman_* in commit
d79b6b8ec2, the bus_release_resource method was using
bus_generic_rman_release_resource for all types other than
PCI_RES_BUS. Instead, bus_generic_rman_* should only be used for
memory and I/O port resources for this driver.
Tested by: cperciva
Reviewed by: cperciva
Fixes: d79b6b8ec2 pci_host_generic: Don't rewrite resource start address for translation
Differential Revision: https://reviews.freebsd.org/D43925
Previously pci_host_generic_attach was returning 0 (success)
incorrectly if allocating a range failed. The error value was 0 from
the previously successful call to bus_set_resource in this case.
Fixes: d79b6b8ec2 pci_host_generic: Don't rewrite resource start address for translation
Allocate resources from the parent device for decoded physical address
ranges. When child resources suballocated from rman's are mapped,
translate those mapping requests into a mapping request of the
associated physical address range in a bus_map_resource method.
While here, convert generic_pcie_rman to a bus_get_rman method and use
bus_generic_rman_* for operations on child resources.
Factor out a generic_pcie_containing_range to share logic between
bus_translate_resource and bus_*map_resource.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43894
The rman description strings now match those used in the PCI-PCI
bridge driver. Using more specific names removes ambiguity in devinfo -u
output on systems with multiple host to PCI bridges.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43890
Fix a long-standing layering violation in the original NEW_PCIB code
by not passing suballocated resources up to the parent bus for
activation and mapping. Instead, handle activation and mapping of
sub-allocated resources in this driver. When mapping resources,
request a mapping from a suitable sub-region of the resource allocated
from the parent bus for the associated bridge window.
Note that this does require passing RF_ACTIVE (with RF_UNMAPPED) when
allocating bridge window resources from the parent.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43690
These functions are not used by pcib subclasses so do not need to
be exposed in pcib_private.h.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D43688
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: emaste, imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43195
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: mhorne
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43191
This commit changes the API of pci_cfgreg(read|write) to add a domain
argument (referred to as a segment in ACPI parlance) (note that this
is not the same as a NUMA domain, but something PCI-specific). This
does not yet enable access to domains other than 0, but updates the
API to support domains.
Places that use hard-coded bus/slot/function addresses have been
updated to hardcode a domain of 0. A few places that have the PCI
domain (segment) available such as the acpi_pcib_acpi.c Host-PCI
bridge driver pass the PCI domain.
The hpt27xx(4) and hptnr(4) drivers fail to attach to a device not on
domain 0 since they provide APIs to their binary blobs that only
permit bus/slot/function addressing.
The x86 non-ACPI PCI bus drivers all hardcode a domain of 0 as they do
not support multiple domains.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D42827
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
Tell bus_dma(9) which NUMA domain the PCI driver is closest to so it
can allocate memory from there when possible.
Reviewed by: markj, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D42186
If a parent downstream port doesn't support ARI, the code would try to
create VFs anyway but then all PCI config space access to those VFs
would fail.
Tested by: np
Sponsored by: Chelsio Communications
When remapping a MSI-X vector, we would always return ENOENT, even if
successful. This didn't really matter, as the sole caller of
BUS_REMAP_INTR also didn't check for errors.
Return 0 if there's no error, so that we can start handling (or at least
warning about) actual failures.
Reviewed by: jhb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41449
rid was stack garbage, so the bus_alloc_resource_any() call could fail
and fall through to the SMCCC version check even if a bridge had a
memory resource.
Debugging help: jrtc27
Reviewed by: jrtc27
Fixes: c9a05c0722 Add a PCI driver that follows the Arm DEN0115 spec
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D41025
Simply speaking, being started the drm-kmod driver should create sysfs helpers,
which is «drm» class devices, with the unit number 0, 128 and, perhaps 64.
If a drm helper created by vgapci driver with the corresponding unit number
exists then the drm-kmod driver initialize it by the device_initialize() lkpi
method, otherwise drm-kmod driver create new «drm» device.
For hw, where two or more different GPU installed, it's not guaranteed that
the order of loading GPU drivers will be the same as the vgapci devices numbered.
I.e., on hw where vgapci0 is Nvidia GPU and vgapci1 is Intel GPU, when drm-kmod
loaded first it will use drm0 helper of vgapci0 device.
There is no problem for drm-kmod driver unless we do not traverse device
tree, as needed for https://reviews.freebsd.org/D38545.
drm-kmod is ok for this change as it has fallback to create corresponding
drm device.
Reviewed by:
Differential Revision: https://reviews.freebsd.org/D38546
This update contains a rewrite of the VPD parser based on the
definition of the structure of the VPD data (ident, R/O resource
data, optional R/W data, end tag).
The parser it replaces was based on a state machine, with the tags
and the parsed data controlling the state changes. The flexibility
of this parser is actually not required, and it has caused kernel
panics when operating on malformed data.
Analysis of the VPD code to make it more robust lead me to believe
that it was easier to write a "strict" parser than to restrict the
flexible state machine to detect and reject non-well-formed data.
A number of restrictions had already been added, but they make the
state machine ever more complex and harder to understand.
This updated parser has been verified to return identical parsed data
as the current implementation for the example VPD data given in the
PCI standard and in some actual PCIe VPD data.
It is strict in the sense that it detects and rejects any deviation
from a well-formed VPD structure.
PR: 272018
Approved by: kib
MFC after: 4 weeks
Differential Revision: https://reviews.freebsd.org/D34268
This is required for pci_alloc_msix() to work and to thus use
MSI-X interrupts for PCI-e hotplug.
Reported by: cperciva
Reviewed by: cperciva
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D40581
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
Teach the pci host generic ACPI attachment about PCI_ID_OFW_IOMMU. This
will be used by the arm64 smmu IOMMU driver to read the xref and ID
this interface provides in a bus-agnostic way.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D39182
