linux-kernel - Re: [PATCH] iommu/arm-smmu-v3: Restrict MMU-700 errata 2268618 and 2812531 to affected

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

Message-ID: <20260206110657.000043f7@gmail.com>
Date: Fri, 6 Feb 2026 11:06:57 +0800
From: DaiZhiyuan <jerry.zhiyuan.dai@...il.com>
To: Robin Murphy <robin.murphy@....com>
Cc: Zhiyuan Dai <daizhiyuan@...tium.com.cn>, will@...nel.org,
 joro@...tes.org, linux-arm-kernel@...ts.infradead.org,
 iommu@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iommu/arm-smmu-v3: Restrict MMU-700 errata 2268618 and
 2812531 to affected

On Thu, 5 Feb 2026 13:05:24 +0000
Robin Murphy <robin.murphy@....com> wrote:

> On 05/02/2026 9:33 am, Zhiyuan Dai wrote:
> > According to SDEN-1786925, Arm errata 2268618 and 2812531 are
> > present in r0p0, r0p1, and r1p0, and fixed in r1p1.  
> 
> This is a bit fiddly, since these workarounds also overlap some other 
> errata that IIRC were *not* fixed in r1p1 - it's been on my to-do
> list to figure this out for a while now, sorry I haven't had a chance
> to get to it.

While checking the documentation, I noticed that in SDEN-1786925, 
document version 19.0 describes the errata as fixed in r1p1.

> 
> > Introduce this patch to avoid performance degradation caused by
> > restricting features on unaffected revisions.  
> 
> I'm curious, can you clarify the performance impact? At the time I
> was pretty sure that the ARM_SMMU_OPT_CMDQ_FORCE_SYNC was just for
> safety and never likely to be hit in practice, since with range
> invalidations any unmap should never end up with anywhere near 16
> TLBIs in a single batch anyway. Is that no longer the case?
> 

Based on the mailing list, the SMMUv3 implementation now fully supports 
the Broadcast TLB Maintenance (BTM) feature as part of the Distributed 
Virtual Memory (DVM) protocol. This allows CPU TLB invalidation instructions 
to be received by the SMMUv3, which is highly beneficial when the SMMUv3 
shares page tables with the CPU (e.g., in Guest SVA use cases).

Additionally, while this aligns with the SDEN documentation, 
please note that we do not have actual benchmark data at this time.

> > Signed-off-by: Zhiyuan Dai <daizhiyuan@...tium.com.cn>
> > ---
> >   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 12 +++++++-----
> >   1 file changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index
> > d16d35c78c06..7eadb27eb9be 100644 ---
> > a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++
> > b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -4272,11 +4272,13
> > @@ static void arm_smmu_device_iidr_probe(struct arm_smmu_device
> > *smmu) smmu->features &= ~ARM_SMMU_FEAT_NESTING; break;
> >   		case IIDR_PRODUCTID_ARM_MMU_700:
> > -			/* Arm erratum 2812531 */
> > -			smmu->features &= ~ARM_SMMU_FEAT_BTM;
> > -			smmu->options |=
> > ARM_SMMU_OPT_CMDQ_FORCE_SYNC;
> > -			/* Arm errata 2268618, 2812531 */
> > -			smmu->features &= ~ARM_SMMU_FEAT_NESTING;
> > +			if (variant <= 1 && revision < 0) {  
> 
> revision is unsigned, it cannot be < 0. This just breaks the
> workarounds entirely.
> 

Logic error: if (variant <= 1 && revision < 0) should be updated to revision < 1.


> Thanks,
> Robin.
> 
> > +				/* Arm erratum 2812531 */
> > +				smmu->features &=
> > ~ARM_SMMU_FEAT_BTM;
> > +				smmu->options |=
> > ARM_SMMU_OPT_CMDQ_FORCE_SYNC;
> > +				/* Arm errata 2268618, 2812531 */
> > +				smmu->features &=
> > ~ARM_SMMU_FEAT_NESTING;
> > +			}
> >   			break;
> >   		}
> >   		break;  
> 
> 

Best regards,

JerryDai.