Re: [PATCH v2 1/3] iommu: io-pgtable: add DART pagetable format
From: Will Deacon <will@kernel.org>
Date: 2021-04-07 10:44:38
Also in:
linux-arm-kernel, linux-iommu, lkml
On Sun, Mar 28, 2021 at 09:40:07AM +0200, Sven Peter wrote:
quoted hunk ↗ jump to hunk
Apple's DART iommu uses a pagetable format that shares some similarities with the ones already implemented by io-pgtable.c. Add a new format variant to support the required differences so that we don't have to duplicate the pagetable handling code. Signed-off-by: Sven Peter <redacted> --- drivers/iommu/io-pgtable-arm.c | 59 ++++++++++++++++++++++++++++++++++ drivers/iommu/io-pgtable.c | 1 + include/linux/io-pgtable.h | 6 ++++ 3 files changed, 66 insertions(+)diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c index 87def58e79b5..2f63443fd115 100644 --- a/drivers/iommu/io-pgtable-arm.c +++ b/drivers/iommu/io-pgtable-arm.c@@ -127,6 +127,9 @@ #define ARM_MALI_LPAE_MEMATTR_IMP_DEF 0x88ULL #define ARM_MALI_LPAE_MEMATTR_WRITE_ALLOC 0x8DULL +#define APPLE_DART_PTE_PROT_NO_WRITE (1<<7) +#define APPLE_DART_PTE_PROT_NO_READ (1<<8) + /* IOPTE accessors */ #define iopte_deref(pte,d) __va(iopte_to_paddr(pte, d))@@ -381,6 +384,15 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data, { arm_lpae_iopte pte; + if (data->iop.fmt == ARM_APPLE_DART) { + pte = 0; + if (!(prot & IOMMU_WRITE)) + pte |= APPLE_DART_PTE_PROT_NO_WRITE; + if (!(prot & IOMMU_READ)) + pte |= APPLE_DART_PTE_PROT_NO_READ; + return pte; + } + if (data->iop.fmt == ARM_64_LPAE_S1 || data->iop.fmt == ARM_32_LPAE_S1) { pte = ARM_LPAE_PTE_nG;@@ -1043,6 +1055,48 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie) return NULL; } +static struct io_pgtable * +apple_dart_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie) +{ + struct arm_lpae_io_pgtable *data; + + if (cfg->ias > 36) + return NULL; + if (cfg->oas > 36) + return NULL; + + if (!cfg->coherent_walk) + return NULL;
This all feels like IOMMU-specific limitations leaking into the page-table code here; it doesn't feel so unlikely that future implementations of this IP might have greater addressing capabilities, for example, and so I don't see why the page-table code needs to police this.
+ cfg->pgsize_bitmap &= SZ_16K; + if (!cfg->pgsize_bitmap) + return NULL;
This is worrying (and again, I don't think this belongs here). How is this thing supposed to work if the CPU is using 4k pages? Will