acpi_pci: Honor device proximity for DMA tags
A PCI function with its own _PXM still inherits a DMA tag carrying
the upstream bridge's proximity domain. Resolving an SR-IOV VF's
locality through its PF therefore does not affect the domain used for
DMA allocations.
Create and cache a private child tag when the function, or a VF's
owning PF, has an explicit _PXM. Parent it to the existing PCI or IOMMU
tag so its constraints remain intact, then apply the function's domain
without mutating a shared tag.
pci_get_dma_tag() already performs the IOMMU lookup, so remove the
duplicated lookup in the ACPI subclass while here.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59063
(cherry picked from commit f1f58bdf7b5fc58e6011c6ac2ae2ba129dc41991)
acpi_pci: Cache PCI proximity domains
A PCI function's _PXM is stable for the lifetime of its device
instance, but CPU and DMA locality queries may evaluate it repeatedly.
SR-IOV amplifies this because every VF resolves locality through the
same PF.
Cache successful mappings and the stable absence of _PXM on the
locality source device, and share that result between CPU and domain
queries. Continue to retry generic evaluation or mapping errors rather
than making a potentially transient failure permanent.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59207
(cherry picked from commit 5f78d024695b39208a6c92f6a96017bae53cdf2c)
acpi_pci: Preserve CPU locality queries for descendants
bus_generic_get_cpus() preserves the original leaf device while
forwarding a request through the bus hierarchy. Consequently,
acpi_pci_get_cpus() may receive a descendant below a PCI function
rather than one of the PCI bus's direct children.
Only apply the SR-IOV PF-locality mapping to direct PCI children.
Preserve the previous ACPI CPU-locality lookup for descendants so their
unrelated bus ivars are not interpreted as PCI device information.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59206
(cherry picked from commit dc4f80da18f0dcc557a969b4283a86569266eb5c)
acpi_pci: Inherit PF locality for SR-IOV VFs
SR-IOV VFs are instantiated from their PF and intentionally do not
receive an ACPI handle by matching their runtime BDF. Consequently,
ACPI locality queries for a VF fall back to the upstream bus. This is
usually sufficient, but loses a _PXM supplied specifically for the PF.
Use the PCI core's owning-PF accessor for BUS_GET_DOMAIN and
BUS_GET_CPUS requests made for a VF. This preserves the VF's lack of
an ACPI handle while allowing its CPU and NUMA placement to follow the
PF.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59062
(cherry picked from commit 1a2a88684a0126be8d7172362d5ec7dbb7a41c81)
acpi_pci: Do not match SR-IOV VFs to ACPI devices
SR-IOV VFs are instantiated dynamically from their PF rather than
enumerated from ACPI. A VF's runtime slot and function can match an
unrelated _ADR below the bridge. acpi_pci_save_handle() stores that
handle in the VF's devinfo before acpi_pci_update_device() runs.
If the handle is already bound to another device_t whose parent is not
acpi0, acpi_pci_update_device() panics under INVARIANTS. Without
INVARIANTS, the VF retains the unrelated handle, so subsequent ACPI
lookups, including NUMA and power-management operations, can act on the
wrong namespace node.
Skip ACPI namespace matching for VFs.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59061
(cherry picked from commit 8b74806161a188103666387013cdd93fb3f5dc07)
acpi_pci: Honor device proximity for DMA tags
A PCI function with its own _PXM still inherits a DMA tag carrying
the upstream bridge's proximity domain. Resolving an SR-IOV VF's
locality through its PF therefore does not affect the domain used for
DMA allocations.
Create and cache a private child tag when the function, or a VF's
owning PF, has an explicit _PXM. Parent it to the existing PCI or IOMMU
tag so its constraints remain intact, then apply the function's domain
without mutating a shared tag.
pci_get_dma_tag() already performs the IOMMU lookup, so remove the
duplicated lookup in the ACPI subclass while here.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59063
(cherry picked from commit f1f58bdf7b5fc58e6011c6ac2ae2ba129dc41991)
acpi_pci: Cache PCI proximity domains
A PCI function's _PXM is stable for the lifetime of its device
instance, but CPU and DMA locality queries may evaluate it repeatedly.
SR-IOV amplifies this because every VF resolves locality through the
same PF.
Cache successful mappings and the stable absence of _PXM on the
locality source device, and share that result between CPU and domain
queries. Continue to retry generic evaluation or mapping errors rather
than making a potentially transient failure permanent.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59207
(cherry picked from commit 5f78d024695b39208a6c92f6a96017bae53cdf2c)
acpi_pci: Preserve CPU locality queries for descendants
bus_generic_get_cpus() preserves the original leaf device while
forwarding a request through the bus hierarchy. Consequently,
acpi_pci_get_cpus() may receive a descendant below a PCI function
rather than one of the PCI bus's direct children.
Only apply the SR-IOV PF-locality mapping to direct PCI children.
Preserve the previous ACPI CPU-locality lookup for descendants so their
unrelated bus ivars are not interpreted as PCI device information.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59206
(cherry picked from commit dc4f80da18f0dcc557a969b4283a86569266eb5c)
acpi_pci: Inherit PF locality for SR-IOV VFs
SR-IOV VFs are instantiated from their PF and intentionally do not
receive an ACPI handle by matching their runtime BDF. Consequently,
ACPI locality queries for a VF fall back to the upstream bus. This is
usually sufficient, but loses a _PXM supplied specifically for the PF.
Use the PCI core's owning-PF accessor for BUS_GET_DOMAIN and
BUS_GET_CPUS requests made for a VF. This preserves the VF's lack of
an ACPI handle while allowing its CPU and NUMA placement to follow the
PF.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59062
(cherry picked from commit 1a2a88684a0126be8d7172362d5ec7dbb7a41c81)
acpi_pci: Do not match SR-IOV VFs to ACPI devices
SR-IOV VFs are instantiated dynamically from their PF rather than
enumerated from ACPI. A VF's runtime slot and function can match an
unrelated _ADR below the bridge. acpi_pci_save_handle() stores that
handle in the VF's devinfo before acpi_pci_update_device() runs.
If the handle is already bound to another device_t whose parent is not
acpi0, acpi_pci_update_device() panics under INVARIANTS. Without
INVARIANTS, the VF retains the unrelated handle, so subsequent ACPI
lookups, including NUMA and power-management operations, can act on the
wrong namespace node.
Skip ACPI namespace matching for VFs.
Reviewed by: jhb
Sponsored by: BBOX.io
Differential Revision: https://reviews.freebsd.org/D59061
(cherry picked from commit 8b74806161a188103666387013cdd93fb3f5dc07)
MFC: fsck_msdosfs: add a test for reconnecting on volumes larger than 4 GiB
MFC after: 1 week
(cherry picked from commit 37aec55d0a7165960f686e5277f030ab3d44cf45)
MFC: fsck_msdosfs: add a test for reconnecting on volumes larger than 4 GiB
MFC after: 1 week
(cherry picked from commit 37aec55d0a7165960f686e5277f030ab3d44cf45)
libjail: fix fetching mac.label for multiple jails
When doing a basic `jls -n`, jls(8) will jailparam_get() the mac.label
for every jail on the system using the same set of jailparams, and thus
the same jp_value. We only init the mac_t the first time, so the first
jail would populate it with `?` from /etc/mac.conf and the resulting
jail_get(2) would clobber it with the empty string, then a second jail
would try to pass the empty string to the kernel and fail because it
must have a non-zero length.
Fix it by invoking jps_get() every time. Drop some comments to note
that jps_get() will be invoked with zero || garbage from previous call,
and be sure that we don't leak our previous mac_t. There aren't any
other jps_get implementations at this time, so this shouldn't cause any
unexpected problems.
Reported by: ivy
Reviewed by: jamie
Differential Revision: https://reviews.freebsd.org/D57280
linuxkpi: Define `DEFINE_CLASS()` and `CLASS()`
`DEFINE_CLASS()` is in fact named `LINUXKPI_DEFINE_CLASS()` because it
conflicts with `DEFINE_CLASS()` defined in <sys/kobj.h>.
This macro defines a type and a pair of constructor/destructor
functions.
They are to be used by `CLASS()`: this one declares a variable,
initialise it with the constructor and set the `__cleanup()` attribute
to call the destructor once the variable goes out of scope.
The DRM drivers generic code started to use `CLASS()` in Linux 6.13. It
requires the `fd` class to be defined in <linux/file.h>.
Reviewed by: bz
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57583
