[PATCH v2] arm64: errata: Workaround for SI L1 downstream coherency issue

[Will Deacon]

On Wed, Jan 07, 2026 at 05:55:40PM +0000, Robin Murphy wrote:
> On 2026-01-07 4:33 pm, Will Deacon wrote:
> > On Thu, Jan 01, 2026 at 06:55:05PM +0000, Marc Zyngier wrote:
> > > The other elephant in the room is virtualisation: how does a guest
> > > performing CMOs deals with this? How does it discover the that the
> > > host is broken? I also don't see any attempt to make KVM handle the
> > > erratum on behalf of the guest...
> > 
> > A guest shouldn't have to worry about the problem, as it only affects
> > clean to PoC for non-coherent DMA agents that reside downstream of the
> > SLC in the interconnect. Since VFIO doesn't permit assigning
> > non-coherent devices to a guest, guests shouldn't ever need to push
> > writes that far (and FWB would cause bigger problems if that was
> > something we wanted to support)
> > 
> > +Mostafa to keep me honest on the VFIO front.
> 
> I don't think we actually prevent non-coherent devices being assigned, we
> just rely on the IOMMU supporting IOMMU_CAP_CACHE_COHERENCY. Thus if there's
> an I/O-coherent SMMU then it could end up being permitted, however I would
> hope that either the affected devices are not behind such an SMMU, or at
> least that if the SMMU imposes cacheable attributes then that prevents
> traffic from taking the back-door path to RAM.

I think IOMMU_CAP_CACHE_COHERENCY is supposed to indicate whether or not
the endpoint devices are coherent (i.e. whether IOMMU_CACHE makes sense)
but it's true that, for the SMMU, we tie this to the coherency of the
SMMU itself so it is a bit sketchy. There's an interesting thread between
Mostafa and Jason about it:

https://lore.kernel.org/all/ZtHhdj6RAKACBCUG@google.com/

But, that aside, FWB throws a pretty big spanner in the works if we want
to assign non-coherent devices.

Will