[PATCH] iommu/io-pgtable-arm: Remove split on unmap behavior
Robin Murphy
robin.murphy at arm.com
Mon Oct 21 13:50:34 UTC 2024
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.
More information about the dri-devel
mailing list