Re: [PATCH] iommu/io-pgtable-arm: Remove split on unmap behavior

[Robin Murphy <robin.murphy@arm.com>]

On 21/10/2024 1:17 pm, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2024 at 12:32:21PM +0100, Steven Price wrote:
> 
>>> that, we can always do it in two steps (unmap the 2M region and remap
>>> the borders). At some point it'd be good to have some kind of atomic
>>> page table updates, so we don't have this short period of time during
>>> which nothing is mapped (between the unmap and the remap), but that's a
>>> different story.
>>
>> The GPU hardware provides that. The only possible missing piece is that
>> the driver needs to know ahead of time that the unmap would unmap the 2M
>> region so it can do the correct lock before the entries are removed.
> 
> It looks like we need atomic update for some confidential compute
> scenarios, so I am working toward that with the coming generic pt
> stuff.

Beware that whatever the Mali drivers might have the option to do for 
themselves, there's still no notion of "atomic update" for SMMU and 
io-pgtable-arm in general, other than perhaps for permission changes - 
even BBML is quite explicitly non-atomic, as it's defined in terms of 
two otherwise-identical mappings existing at the same time, just 
guaranteeing that while they do, you'll still get behaviour consistent 
with one *or* the other, and not anything in-between.

As far as this patch goes, though, I would not be at all unhappy to see 
the back of split_blk_unmap... However if we are going to do this then 
I'd like even more to formally define it as the behaviour of 
iommu_unmap() and fix up all the other drivers which behave still 
differently (the statement in the commit message is incorrect - 
io-pgtable-arm-v7s still splits; at least exynos fails the unmap entirely.)

Thanks,
Robin.