iommu/amd: Fix IOMMU interrupt generation in X2APIC mode
authorDavid Woodhouse <dwmw@amazon.co.uk>
Wed, 11 Nov 2020 12:09:01 +0000 (12:09 +0000)
committerThomas Gleixner <tglx@linutronix.de>
Wed, 18 Nov 2020 19:55:59 +0000 (20:55 +0100)
commitd1adcfbb520c43c10fc22fcdccdd4204e014fb53
tree5900c04ae9ca2402493c8119f9387c445aa548dd
parent2df985f5e44c43f5d29d8cc3aaa8e8ac697e9de6
iommu/amd: Fix IOMMU interrupt generation in X2APIC mode

The AMD IOMMU has two modes for generating its own interrupts.

The first is very much based on PCI MSI, and can be configured by Linux
precisely that way. But like legacy unmapped PCI MSI it's limited to
8 bits of APIC ID.

The second method does not use PCI MSI at all in hardawre, and instead
configures the INTCAPXT registers in the IOMMU directly with the APIC ID
and vector.

In the latter case, the IOMMU driver would still use pci_enable_msi(),
read back (through MMIO) the MSI message that Linux wrote to the PCI MSI
table, then swizzle those bits into the appropriate register.

Historically, this worked because__irq_compose_msi_msg() would silently
generate an invalid MSI message with the high bits of the APIC ID in the
high bits of the MSI address. That hack was intended only for the Intel
IOMMU, and I recently enforced that, introducing a warning in
__irq_msi_compose_msg() if it was invoked with an APIC ID above 255.

Fix the AMD IOMMU not to depend on that hack any more, by having its own
irqdomain and directly putting the bits from the irq_cfg into the right
place in its ->activate() method.

Fixes: 47bea873cf80 "x86/msi: Only use high bits of MSI address for DMAR unit")
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Link: https://lore.kernel.org/r/05e3a5ba317f5ff48d2f8356f19e617f8b9d23a4.camel@infradead.org
arch/x86/include/asm/hw_irq.h
drivers/iommu/amd/init.c