History log of /freebsd/sys/x86/x86/io_apic.c (Results 1 – 25 of 89)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: release/14.2.0
# 90fb07ed 01-Oct-2024 Elliott Mitchell <ehem+freebsd@m5p.com>

intr/x86: add ioapic_drv_t to reduce number of casts in IO-APIC implementation

void * is handy when you truly do not care about the type. Yet there is
so much casting back and forth in the IO-APIC

intr/x86: add ioapic_drv_t to reduce number of casts in IO-APIC implementation

void * is handy when you truly do not care about the type. Yet there is
so much casting back and forth in the IO-APIC code as to be hazardous.
Achieve better static checking by the compiler using a typedef.

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1457

show more ...


# 839fb853 03-Oct-2024 Elliott Mitchell <ehem+freebsd@m5p.com>

intr/x86: cleanup io_apic device method tables

Replace the { 0, 0 } construct with the preferred DEVMETHOD_END. Add
a space after to indicate it is separate from the section above.

Reviewed by: im

intr/x86: cleanup io_apic device method tables

Replace the { 0, 0 } construct with the preferred DEVMETHOD_END. Add
a space after to indicate it is separate from the section above.

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1457

show more ...


# ea4e4449 13-Oct-2024 Konstantin Belousov <kib@FreeBSD.org>

apic: add ioapic_get_dev() method

which returns apic device_t by apic_id, if there exists the pci representer

Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC aft

apic: add ioapic_get_dev() method

which returns apic device_t by apic_id, if there exists the pci representer

Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week

show more ...


Revision tags: release/13.4.0, release/14.1.0, release/13.3.0, release/14.0.0
# 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

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

show more ...


Revision tags: release/13.2.0, release/12.4.0
# 7ae99f80 23-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.f

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

show more ...


Revision tags: release/13.1.0
# 80d2b3de 07-May-2022 John Baldwin <jhb@FreeBSD.org>

x86: Remove unused devclass arguments to DRIVER_MODULE.


Revision tags: release/12.3.0, release/13.0.0, release/12.2.0
# 6186bfbd 29-Sep-2020 Ruslan Bukin <br@FreeBSD.org>

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 ...


# ab6c81a2 01-Sep-2020 Mateusz Guzik <mjg@FreeBSD.org>

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


Revision tags: release/11.4.0
# 46ed9da5 18-Mar-2020 Konstantin Belousov <kib@FreeBSD.org>

Do not spuriously re-enable disabled io_apic pin on EOI for some configurations.

If EOI suppression is supported but reported ioapic version is so old
that it does not has EOI register (weird virtua

Do not spuriously re-enable disabled io_apic pin on EOI for some configurations.

If EOI suppression is supported but reported ioapic version is so old
that it does not has EOI register (weird virtualization setup), fix
Intel trick of eoi-ing by flipping pin type (edge/level) to account
for the disabled pin.

Reported by: Juniper
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D23965

show more ...


# 1314c492 18-Mar-2020 Konstantin Belousov <kib@FreeBSD.org>

Stop (trying to) renumber io apics.

It does not serve any purpose now, the io apic id is not seen by
software, and some Intel documents claim that the register is
implemented for FUD reasons. More,

Stop (trying to) renumber io apics.

It does not serve any purpose now, the io apic id is not seen by
software, and some Intel documents claim that the register is
implemented for FUD reasons. More, renumbering seems to not work on
new Intel machines which actually have mismatched MADT and hw IDs.

On older machines where separate APIC bus existed, unique numbering of
all APICs was required for bus arbitration to work, but it is no
longer true (that machines were SMP from pre-Pentium IV era).

When matching PCIe IOAPIC device against MADT-enumerated IOAPICs,
compare io_apic_id from BAR against io_apic_id read from the
MADT-pointed register page.

Reviewed by: jhb
Tested by: flo (previous version), pho
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D23965

show more ...


# c105f5c1 18-Mar-2020 Konstantin Belousov <kib@FreeBSD.org>

Widen the stored io_apic_id to 8 bits.

It seems that the newer Intel chipset did that, and Linux reads 8
bits. The only detail is that all seen datasheets, even under NDA,
claim that io apic id is 4

Widen the stored io_apic_id to 8 bits.

It seems that the newer Intel chipset did that, and Linux reads 8
bits. The only detail is that all seen datasheets, even under NDA,
claim that io apic id is 4 bits.

Submitted by: jeff
Reviewed by: jhb
Tested by: flo, pho
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D23965

show more ...


Revision tags: release/12.1.0
# ea321107 15-Aug-2019 John Baldwin <jhb@FreeBSD.org>

Stop listing "on motherboard" as the parent of nexus devices on x86.

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D21256


Revision tags: release/11.3.0
# 2aaf9152 18-Mar-2019 Alan Somers <asomers@FreeBSD.org>

MFHead@r345275


# ff511f1f 11-Mar-2019 Enji Cooper <ngie@FreeBSD.org>

MFhead@r344996


# 2e43efd0 06-Mar-2019 John Baldwin <jhb@FreeBSD.org>

Drop "All rights reserved" from my copyright statements.

Reviewed by: rgrimes
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D19485


Revision tags: release/12.0.0
# da2d1e9d 29-Aug-2018 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r338298 through r338391.


# fd036dea 28-Aug-2018 John Baldwin <jhb@FreeBSD.org>

Dynamically allocate IRQ ranges on x86.

Previously, x86 used static ranges of IRQ values for different types
of I/O interrupts. Interrupt pins on I/O APICs and 8259A PICs used
IRQ values from 0 to

Dynamically allocate IRQ ranges on x86.

Previously, x86 used static ranges of IRQ values for different types
of I/O interrupts. Interrupt pins on I/O APICs and 8259A PICs used
IRQ values from 0 to 254. MSI interrupts used a compile-time-defined
range starting at 256, and Xen event channels used a
compile-time-defined range after MSI. Some recent systems have more
than 255 I/O APIC interrupt pins which resulted in those IRQ values
overflowing into the MSI range triggering an assertion failure.

Replace statically assigned ranges with dynamic ranges. Do a single
pass computing the sizes of the IRQ ranges (PICs, MSI, Xen) to
determine the total number of IRQs required. Allocate the interrupt
source and interrupt count arrays dynamically once this pass has
completed. To minimize runtime complexity these arrays are only sized
once during bootup. The PIC range is determined by the PICs present
in the system. The MSI and Xen ranges continue to use a fixed size,
though this does make it possible to turn the MSI range size into a
tunable in the future.

As a result, various places are updated to use dynamic limits instead
of constants. In addition, the vmstat(8) utility has been taught to
understand that some kernels may treat 'intrcnt' and 'intrnames' as
pointers rather than arrays when extracting interrupt stats from a
crashdump. This is determined by the presence (vs absence) of a
global 'nintrcnt' symbol.

This change reverts r189404 which worked around a buggy BIOS which
enumerated an I/O APIC twice (using the same memory mapped address for
both entries but using an IRQ base of 256 for one entry and a valid
IRQ base for the second entry). Making the "base" of MSI IRQ values
dynamic avoids the panic that r189404 worked around, and there may now
be valid I/O APICs with an IRQ base above 256 which this workaround
would incorrectly skip.

If in the future the issue reported in PR 130483 reoccurs, we will
have to add a pass over the I/O APIC entries in the MADT to detect
duplicates using the memory mapped address and use some strategy to
choose the "correct" one.

While here, reserve room in intrcnts for the Hyper-V counters.

PR: 229429, 130483
Reviewed by: kib, royger, cem
Tested by: royger (Xen), kib (DMAR)
Approved by: re (gjb)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D16861

show more ...


Revision tags: release/11.2.0
# 27a3c9d7 28-Mar-2018 Jeff Roberson <jeff@FreeBSD.org>

Restore r331606 with a bugfix to setup cpuset_domain[] earlier on all
platforms. Original commit message as follows:

Only use CPUs in the domain the device is attached to for default
assignment. D

Restore r331606 with a bugfix to setup cpuset_domain[] earlier on all
platforms. Original commit message as follows:

Only use CPUs in the domain the device is attached to for default
assignment. Device drivers are able to override the default assignment
if they bind directly. There are severe performance penalties for
handling interrupts on remote CPUs and this should only be done in
very controlled circumstances.

Reviewed by: jhb, kib
Tested by: pho
Sponsored by: Netflix, Dell/EMC Isilon
Differential Revision: https://reviews.freebsd.org/D14838

show more ...


# 261c4087 27-Mar-2018 Jeff Roberson <jeff@FreeBSD.org>

Backout r331606 until I can identify why it does not boot on some
machines.


# a48de40b 27-Mar-2018 Jeff Roberson <jeff@FreeBSD.org>

Only use CPUs in the domain the device is attached to for default
assignment. Device drivers are able to override the default assignment
if they bind directly. There are severe performance penaltie

Only use CPUs in the domain the device is attached to for default
assignment. Device drivers are able to override the default assignment
if they bind directly. There are severe performance penalties for
handling interrupts on remote CPUs and this should only be done in
very controlled circumstances.

Reviewed by: jhb, kib
Tested by: pho (earlier version)
Sponsored by: Netflix, Dell/EMC Isilon
Differential Revision: https://reviews.freebsd.org/D14838

show more ...


# 4fc74049 29-Dec-2017 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r327169 through r327340.


# 15f00345 28-Dec-2017 Marius Strobl <marius@FreeBSD.org>

With the advent of interrupt remapping, Intel has repurposed bit 11
(now: Interrupt_Index[15]) and assigned the previously reserved bits
55:48 (Interrupt_Index[14:0] goes into 63:49 while Destination

With the advent of interrupt remapping, Intel has repurposed bit 11
(now: Interrupt_Index[15]) and assigned the previously reserved bits
55:48 (Interrupt_Index[14:0] goes into 63:49 while Destination Field
used 63:56 and bit 48 now is Interrupt_Format) in the IO redirection
tables (see the VT-d specification, "5.1.5.1 I/OxAPIC Programming").
Thus, when not using interrupt remapping, ensure that all previously
reserved bits in the high part of the RTEs are zero instead of doing
a read-modify-write for their Destination Field bits only.
Otherwise, on machines based on Apollo Lake and its derivatives such
as Denverton, typically some of the previously preserved bits remain
set after boot when not employing interrupt remapping. The result is
that INTx interrupts are not getting delivered.
Note: With an AMD IOMMU, interrupt remapping apparently bypasses the
IO APIC altogether.

Submitted by: loos (modulo comment)
Reviewed by: jhb (modulo comment)

show more ...


# ebf5747b 27-Nov-2017 Pedro F. Giffuni <pfg@FreeBSD.org>

sys/x86: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error

sys/x86: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

show more ...


Revision tags: release/10.4.0
# 8fcbcc2d 16-Sep-2017 Enji Cooper <ngie@FreeBSD.org>

MFhead@r323635


1234