diff options
author | David Woodhouse <dwmw@amazon.co.uk> | 2020-10-24 22:35:02 +0100 |
---|---|---|
committer | Thomas Gleixner <tglx@linutronix.de> | 2020-10-28 20:26:24 +0100 |
commit | 47bea873cf809f490cfac0c4e88533fd7fed6064 (patch) | |
tree | 9ec6e5c1da5261a2eb7b2cc05ac17eeac60df064 /arch/x86/kernel/apic/x2apic_uv_x.c | |
parent | 26573a97746c7a99f394f9d398ce91a8853b3b89 (diff) | |
download | linux-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