linux-kernel - Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c2361f78-b739-2f71-562b-d2c5f20825e7@amd.com>
Date:   Tue, 17 Nov 2020 09:00:51 +0700
From:   Suravee Suthikulpanit <suravee.suthikulpanit@....com>
To:     David Woodhouse <dwmw2@...radead.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>
Cc:     linux-kernel@...r.kernel.org, x86 <x86@...nel.org>,
        Qian Cai <cai@...hat.com>, Joerg Roedel <joro@...tes.org>
Subject: Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity
 helpers

David,

On 11/13/20 10:14 PM, David Woodhouse wrote:
> On Wed, 2020-11-11 at 14:30 -0600, Tom Lendacky wrote:
>> I had trouble cloning your tree for some reason, so just took the top
>> three patches and applied them to the tip tree. This all appears to be
>> working. I'll let the IOMMU experts take a closer look (adding Suravee).
> 
> Thanks. I see Thomas has taken the first two into the tip.git x86/apic
> branch already, so we're just looking for an ack on the third. Which is
> this one...
> 
>  From 49ee4fa51b8c06d14b7c4c74d15a7d76f865a8ea Mon Sep 17 00:00:00 2001
> From: David Woodhouse <dwmw@...zon.co.uk>
> Date: Wed, 11 Nov 2020 12:09:01 +0000
> Subject: [PATCH] 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@...zon.co.uk>

I'm still working on testing this series using IO_PAGE_FAULT injection to trigger the IOMMU interrupts. I am still 
debugging some issues, and I'll keep you updated on the findings.

Thanks,
Suravee