linux-kernel - Re: [RFC PATCH v2 08/18] iommu/riscv: Use MSI table to enable IMSIC access

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: <20250922184336.GD1391379@nvidia.com>
Date: Mon, 22 Sep 2025 15:43:36 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Andrew Jones <ajones@...tanamicro.com>
Cc: iommu@...ts.linux.dev, kvm-riscv@...ts.infradead.org,
	kvm@...r.kernel.org, linux-riscv@...ts.infradead.org,
	linux-kernel@...r.kernel.org, zong.li@...ive.com,
	tjeznach@...osinc.com, joro@...tes.org, will@...nel.org,
	robin.murphy@....com, anup@...infault.org, atish.patra@...ux.dev,
	tglx@...utronix.de, alex.williamson@...hat.com,
	paul.walmsley@...ive.com, palmer@...belt.com, alex@...ti.fr
Subject: Re: [RFC PATCH v2 08/18] iommu/riscv: Use MSI table to enable IMSIC
 access

On Sat, Sep 20, 2025 at 03:38:58PM -0500, Andrew Jones wrote:
> When setting irq affinity extract the IMSIC address the device
> needs to access and add it to the MSI table. If the device no
> longer needs access to an IMSIC then remove it from the table
> to prohibit access. This allows isolating device MSIs to a set
> of harts so we can now add the IRQ_DOMAIN_FLAG_ISOLATED_MSI IRQ
> domain flag.

IRQ_DOMAIN_FLAG_ISOLATED_MSI has nothing to do with HARTs.

 * Isolated MSI means that HW modeled by an irq_domain on the path from the
 * initiating device to the CPU will validate that the MSI message specifies an
 * interrupt number that the device is authorized to trigger. This must block
 * devices from triggering interrupts they are not authorized to trigger.
 * Currently authorization means the MSI vector is one assigned to the device.

It has to do with each PCI BDF having a unique set of
validation/mapping tables for MSIs that are granular to the interrupt
number.

As I understand the spec this is is only possible with msiptp? As
discussed previously this has to be a static property and the SW stack
doesn't expect it to change. So if the IR driver sets
IRQ_DOMAIN_FLAG_ISOLATED_MSI it has to always use misptp?

Further, since the interrupt tables have to be per BDF they cannot be
linked to an iommu_domain! Storing the msiptp in an iommu_domain is
totally wrong?? It needs to somehow be stored in the interrupt layer
per-struct device, check how AMD and Intel have stored their IR tables
programmed into their versions of DC.

It looks like there is something in here to support HW that doesn't
have msiptp? That's different, and also looks very confused. The IR
driver should never be touching the iommu domain or calling iommu_map!
Instead it probably has to use the SW_MSI mechanism to request mapping
the interrupt controller aperture. You don't get
IRQ_DOMAIN_FLAG_ISOLATED_MSI with something like this though. Look at
how ARM GIC works for this mechanism.

Finally, please split this series up, if ther are two different ways
to manage the MSI aperture then please split it into two series with a
clear description how the HW actually works.

Maybe start with the simpler case of no msiptp??

Jason