Re: [PATCH v1 03/20] iommu/arm-smmu-v3: Implement arm_smmu_domain_test_dev

Jason Gunthorpe
2025-10-27T23:27:09Z

On Mon, Oct 20, 2025 at 01:08:16PM -0700, Nicolin Chen wrote:

> > I don't see any reasonable way to mitigate this??
>
> Right. It can't simply go through a regular attach_dev call since
> driver wouldn't expect any inconsistency in the core.
>
> Driver would have to be aware of the reset state, and make a copy
> of the old domain's CD/STE to use for a test_dev() during a reset.

It seems convoluted :\

IDK if you want to do that some kind of "attach but really don't" flag
so all the tracking was kept, just the STE was forced to blocking.

Then since all the fake attaches are tracked and validated switching
to a real ste shouldn't fail.

For instance SMMU could continue to build the CD table and act like
the CD is active, but the STE wouldn't point to it.

Basically, this approach doesn't seem to solve all the problems, it
reduces them sure, but there are still enough gaps.

So I think we either have to live with them and call it a user bug to
change the domain improperly during FLR.. If it happens dump the
translation into blocking and move on..

Or we have to do some kind of fake attach tracking which doesn't sound
appealing..

Jason