On 20/08/2019 11:31, Will Deacon wrote:
On Mon, Aug 19, 2019 at 07:19:30PM +0100, Robin Murphy wrote:
Although it's conceptually nice for the io_pgtable_cfg to provide a
standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU
looks exactly like an Arm CPU, and they all have various other TCR
controls which io-pgtable can't be expected to understand. Thus since
there is an expectation that drivers will have to add to the given TCR
value anyway, let's strip it down to just the essentials that are
directly relevant to io-pgatble's inner workings - namely the address
sizes, walk attributes, and where appropriate, format selection.
Signed-off-by: Robin Murphy <[email protected]>
---
drivers/iommu/arm-smmu-v3.c | 7 +------
drivers/iommu/arm-smmu.c | 1 +
drivers/iommu/arm-smmu.h | 2 ++
drivers/iommu/io-pgtable-arm-v7s.c | 6 ++----
drivers/iommu/io-pgtable-arm.c | 4 ----
drivers/iommu/qcom_iommu.c | 2 +-
6 files changed, 7 insertions(+), 15 deletions(-)
Hmm, so I'm a bit nervous about this one since I think we really should
be providing a TCR with EPD1 set if we're only giving you TTBR0. Relying
on the driver to do this worries me. See my comments on the next patch.
The whole idea is that we already know we can't provide a *complete* TCR
value (not least because anything above bit 31 is the wild west), thus
there's really no point in io-pgtable trying to provide anything other
than the parts it definitely controls. It makes sense to provide this
partial TCR value "as if" for TTBR0, since that's the most common case,
but ultimately io-pgatble doesn't know (or need to) which TTBR the
caller intends to actually use for this table. Even if the caller *is*
allocating it for TTBR0, io-pgtable doesn't know that they haven't got
something live in TTBR1 already, so it still wouldn't be in a position
to make the EPD1 call either way.
Ultimately, it's the IOMMU drivers who decide what they put in which
TTBR, so it's the IOMMU drivers which have to take responsibility for
EPD*. Sure you can worry about it, but you can equally worry about them
them misprogramming the ASID or anything else...
Robin.
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
