On Mon, Oct 21, 2024 at 02:50:34PM +0100, Robin Murphy wrote:
> 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.
one or the other is mostly what atomic means in this context. CC just
doesn't want any sort of fault.
> 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.)
Hmm, my kunit does cover io-pgtable-arm-v7 but I see there is a
mistake. I can remove it and test it there too.
Exynos looks like it triggers WARN_ONs so nobody uses it there at least:
if (lv1ent_section(ent)) {
if (WARN_ON(size < SECT_SIZE)) {
err_pgsize = SECT_SIZE;
goto err;
}
We just need to delete that WARN block?
I'm not sure what to document here, I don't think we should tell
people to rely on this given we can't test every single
implementation. I'm mostly interested to ensure that nobody has
quietly started relying on split behavior.
Jason
