summaryrefslogtreecommitdiffstats
path: root/arch/x86/kernel/apic/x2apic_uv_x.c
diff options
context:
space:
mode:
authorDavid Woodhouse <dwmw@amazon.co.uk>2020-10-24 22:35:02 +0100
committerThomas Gleixner <tglx@linutronix.de>2020-10-28 20:26:24 +0100
commit47bea873cf809f490cfac0c4e88533fd7fed6064 (patch)
tree9ec6e5c1da5261a2eb7b2cc05ac17eeac60df064 /arch/x86/kernel/apic/x2apic_uv_x.c
parent26573a97746c7a99f394f9d398ce91a8853b3b89 (diff)
downloadlinux-47bea873cf809f490cfac0c4e88533fd7fed6064.tar.bz2
x86/msi: Only use high bits of MSI address for DMAR unit
The Intel IOMMU has an MSI-like configuration for its interrupt, but it isn't really MSI. So it gets to abuse the high 32 bits of the address, and puts the high 24 bits of the extended APIC ID there. This isn't something that can be used in the general case for real MSIs, since external devices using the high bits of the address would be performing writes to actual memory space above 4GiB, not targeted at the APIC. Factor the hack out and allow it only to be used when appropriate, adding a WARN_ON_ONCE() if other MSIs are targeted at an unreachable APIC ID. That should never happen since the compatibility MSI messages are not used when Interrupt Remapping is enabled. The x2apic_enabled() check isn't needed because Linux won't bring up CPUs with higher APIC IDs unless IR and x2apic are enabled anyway. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20201024213535.443185-3-dwmw2@infradead.org
Diffstat (limited to 'arch/x86/kernel/apic/x2apic_uv_x.c')
0 files changed, 0 insertions, 0 deletions