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.
