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
|