linux-kernel - SMMUv3 interrupt handling via custom logic

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-next>] [day] [month] [year] [list]

Message-ID: <0482d84e-871b-4522-b94b-29a97c87ff66@amd.com>
Date: Fri, 27 Jun 2025 09:19:05 +0200
From: Michal Simek <michal.simek@....com>
To: Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
 "Stabellini, Stefano" <stefano.stabellini@....com>
Cc: linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
 iommu@...ts.linux.dev,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 "Sarangi, Anirudha" <anirudha.sarangi@....com>
Subject: SMMUv3 interrupt handling via custom logic

Hi Will and Robin, (+Stefano, Anirudha)

We are using smmu-v3 in our SOC and I would like to ask you for recommendation 
how to handle our interrupt cases.

here is description which we are using

smmu: iommu@...00000 {
	compatible = "arm,smmu-v3";
	reg = <...>;
	#iommu-cells = <1>;
	interrupt-names = "combined";
	interrupts = <0 169 4>;
};

but it is missing one important detail which just arise that actually there is 
additional HW logic which deals with SMMU interrupts separately.
There is a secure part (global, cmd, event - gerror, cmdq-sync, eventq in DT)
and non secure part (pri, global, cmd, event - priq, gerror, cmdq-sync, eventq 
in DT).
Based on my information all these interrupts should be acked once handled to be 
able to get another one.
The driver itself is able to handle them separately but we didn't create any 
solution to reach custom HW to do it.

I looked at f935448acf46 ("iommu/arm-smmu-v3: Add workaround for Cavium 
ThunderX2 erratum #126") which introduced combined IRQs but it looks like that 
there is no need for additional ACK of that IRQs.

The HW logic itself is handling secure and non secure settings for SMMU that's 
why would be the best to avoid directly mapping it in Linux.

One way to go is to create secondary interrupt controller driver
a) ioremap one with notice about secure part because we are using SMMU only with 
NS world
b) firmware based to tunnel accesses via SMCs and allow only access to limited 
amount of registers

The second way is likely create any hooks in the driver to be able to provide 
additional SOC specific hooks.

I am not quite sure which way would be the best that's why I would like to get 
some recommendation from you.

Stefano: please correct me if any of my description is not accurate.

Thanks,
Michal