]> CyberLeo.Net >> Repos - FreeBSD/stable/10.git/commit
MFC: 327314
authormarius <marius@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Wed, 14 Mar 2018 23:59:52 +0000 (23:59 +0000)
committermarius <marius@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Wed, 14 Mar 2018 23:59:52 +0000 (23:59 +0000)
commit863524360d34cf4c479683923e0633b82ad048ed
tree65d707f1e8298e41d40761a115dc751148c44502
parentba2e8eb763181d097937cb5fec5480ef2b6e9b73
MFC: 327314

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)

git-svn-id: svn://svn.freebsd.org/base/stable/10@330959 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/x86/x86/io_apic.c