Re: [PATCH v3 03/13] iommu/arm-smmu-v3: Drain in-flight fault events on domain detach

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Sep 03, 2026 at 12:18:33PM -0700, Jonathan Cameron wrote:
> > Also run the drain for every stall-capable master, even when the departing
> > attachment did not enable IOPF: such a stall event has to be aborted while
> > it still resolves to the old attach handle, 

That isn't the model for fault handling. The fault is delivered
unpredictably into either old or new domain. It doesn't matter which
one.

Domains have to conclude their fault proceessing before they are
destroyed, and attach to the a non-fault domain has to conclude faults
before completing the attach.

But there is no requirement to deliver faults to any particular thing.

> > could pick it up right after the handle swap, mistakenly resuming it as if
> > it were a valid page fault against a new domain.
> 
> Useful perhaps to call out if this has been seen in real systems or
> not. I agree with the analysis but would rather hope drivers are
> well behaved in ensuring all traffic is done, adn this is hardeninging
> / handling of naught hardware activity (all good if so!)

There is a firm API contract on the iommu drivers, they cannot
propogate faults at unexpected times because the consumers cannot deal
with it.

We don't reason about well behaved drivers at this level because vfio
cannot be trusted to be well behaved. So any nonsense vfio can trigger
has to be handled without crashing the kernel.

Jason