History log of /freebsd-current/sys/dev/acpica/acpi_pxm.c
Revision Date Author Comments
# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


# 4d846d26 10-May-2023 Warner Losh <imp@FreeBSD.org>

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

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


# bab8274c 25-Apr-2023 Dimitry Andric <dim@FreeBSD.org>

Use bool for one-bit wide bit-fields

A signed one-bit wide bit-field can take only the values 0 and -1. Clang
16 introduced a warning that "implicit truncation from 'int' to a
one-bit wide bit-field changes value from 1 to -1". Fix the warnings by
using C99 bool.

Reported by: Clang 16
Reviewed by: emaste, jhb
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D39705


# 7ae99f80 22-Sep-2022 John Baldwin <jhb@FreeBSD.org>

pmap_unmapdev/bios: Accept a pointer instead of a vm_offset_t.

This matches the return type of pmap_mapdev/bios.

Reviewed by: kib, markj
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D36548


# 0f8b212a 18-Dec-2020 Mark Johnston <markj@FreeBSD.org>

acpi: Ensure that adjacent memory affinity table entries are coalesced

The SRAT may contain multiple distinct entries that together describe a
contiguous region of physical memory. In this case we were not
coalescing the corresponding entries in the memory affinity table, which
led to fragmented phys_avail[] entries. Since r338431 the vm_phys_segs[]
entries derived from phys_avail[] will be coalesced, resulting in a
situation where vm_phys_segs[] entries do not have a covering
phys_avail[] entry. vm_page_startup() will not add such segments to the
physical memory allocator, leaving them unused.

Reported by: Don Morris <dgmorris@earthlink.net>
Reviewed by: kib, vangyzen
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27620


# e76aab6a 14-May-2020 Mark Johnston <markj@FreeBSD.org>

Call acpi_pxm_set_proximity_info() slightly earlier on x86.

This function is responsible for setting pc_domain in each pcpu
structure. Call it from the main function that starts APs, rather than
a separate SYSINIT. This makes it easier to close the window where
UMA's per-CPU slab allocator may be called while pc_domain is
uninitialized. In particular, the allocator uses pc_domain to allocate
domain-local pages, so allocations before this point end up using domain
0 for everything.

Reviewed by: kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24757


# a5e5548c 18-Aug-2019 Jeff Roberson <jeff@FreeBSD.org>

Allocate all per-cpu datastructures in domain correct memory.

Reviewed by: kib, gallatin (some objections)
Tested by: pho
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D21242


# 13aacaee 08-Dec-2018 Jayachandran C. <jchandra@FreeBSD.org>

acpica: support parsing of arm64 affinity in acpi_pxm.c

ACPI SRAT table on arm64 uses GICC entries to provide CPU locality
information. These entries use an AcpiProcessorUid to identify the
CPU (unlike on x86 where the entries have an APIC ID).

Update acpi_pxm.c to extend the cpu_add/cpu_find/cpu_get_info
functions to handle AcpiProcessorUid. Use the updated functions
while parsing ACPI_SRAT_GICC_AFFINITY entry for arm64.

Also update sys/conf/files.arm64 to build acpi_pxm.c when ACPI is
enabled.

Reviewed by: markj (previous version)
Differential Revision: https://reviews.freebsd.org/D17942


# 9417fa9e 08-Dec-2018 Jayachandran C. <jchandra@FreeBSD.org>

acpica : move SRAT/SLIT parsing to sys/dev/acpica

This moves the architecture independent parts of sys/x86/acpica/srat.c
to sys/dev/acpica/acpi_pxm.c, to be used later on arm64. The function
declarations are moved to sys/dev/acpica/acpivar.h

We also need to update sys/conf/files.{i386,amd64} to use the new file.
No functional changes.

Reviewed by: markj, imp
Differential Revision: https://reviews.freebsd.org/D17941