x86/ioapic: Generate RTE directly from parent irqchip's MSI message
authorDavid Woodhouse <dwmw@amazon.co.uk>
Sat, 24 Oct 2020 21:35:21 +0000 (22:35 +0100)
committerThomas Gleixner <tglx@linutronix.de>
Wed, 28 Oct 2020 19:26:27 +0000 (20:26 +0100)
commit5d5a97133887b2dfd8e2ad0347c3a02cc7aaa0cb
tree8d5dcf503609c3dbd615e5063a002c929d17a547
parent341b4a7211b6ba3a7089e1dc09ac4bd576dfb05f
x86/ioapic: Generate RTE directly from parent irqchip's MSI message

The I/O-APIC generates an MSI cycle with address/data bits taken from its
Redirection Table Entry in some combination which used to make sense, but
now is just a bunch of bits which get passed through in some seemingly
arbitrary order.

Instead of making IRQ remapping drivers directly frob the I/OA-PIC RTE, let
them just do their job and generate an MSI message. The bit swizzling to
turn that MSI message into the I/O-APIC's RTE is the same in all cases,
since it's a function of the I/O-APIC hardware. The IRQ remappers have no
real need to get involved with that.

The only slight caveat is that the I/OAPIC is interpreting some of those
fields too, and it does want the 'vector' field to be unique to make EOI
work. The AMD IOMMU happens to put its IRTE index in the bits that the
I/O-APIC thinks are the vector field, and accommodates this requirement by
reserving the first 32 indices for the I/O-APIC.  The Intel IOMMU doesn't
actually use the bits that the I/O-APIC thinks are the vector field, so it
fills in the 'pin' value there instead.

[ tglx: Replaced the unreadably macro maze with the cleaned up RTE/msi_msg
   bitfields and added commentry to explain the mapping magic ]

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-22-dwmw2@infradead.org
arch/x86/include/asm/hw_irq.h
arch/x86/kernel/apic/io_apic.c
drivers/iommu/amd/iommu.c
drivers/iommu/hyperv-iommu.c
drivers/iommu/intel/irq_remapping.c