On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote:
> On Tue, 2020-11-10 at 10:17 -0600, Tom Lendacky wrote:
>> Yep. The warning started triggering with:
>> 47bea873cf80 ("x86/msi: Only use high bits of MSI address for DMAR unit")
>>
>> Here's the backtrace:
>>
>> [ 15.745929] irq_chip_compose_msi_msg+0x2e/0x40
>> [ 15.750984] msi_domain_activate+0x4b/0x90
>> [ 15.755556] __irq_domain_activate_irq+0x53/0x80
>> [ 15.760707] ? irq_set_msi_desc_off+0x5a/0x90
>> [ 15.765568] irq_domain_activate_irq+0x25/0x40
>> [ 15.770525] __msi_domain_alloc_irqs+0x16a/0x310
>> [ 15.775680] __pci_enable_msi_range+0x182/0x2b0
>> [ 15.780738] ? e820__memblock_setup+0x7d/0x7d
>> [ 15.785597] pci_enable_msi+0x16/0x30
>> [ 15.789685] iommu_init_msi+0x30/0x190
>
> It's asking the core code to generate a PCI MSI message for it and
> actually program that to the PCI device (since the IOMMU itself is a
> PCI device).
>
> That isn't actually used for generating MSI, but is instead interpreted
> to write the intcapxt registers which *do* generate the interrupts.
>
> That wants fixing, preferably not to go via MSI format at all, or maybe
> just to use the 'dmar' flag to __irq_msi_compose_msg(). Either way by
> having an irqdomain of its own like the Intel IOMMU does.
>
> If I could get post-5.5 kernels to boot at all with the AMD IOMMU
> enabled, I'd have a go at throwing that together now...
It can share the dmar domain code. Let me frob something.
