[PATCH v3 2/5] iommu/io-pgtable: Move Apple DART support to its own file
The pte format used by the DARTs found in the Apple M1 (t8103) is not
fully compatible with io-pgtable-arm. The 24 MSB are used for subpage
protection (mapping only parts of page) and conflict with the address
mask. In addition bit 1 is not available for tagging entries but disables
subpage protection. Subpage protection could be useful to support a CPU
granule of 4k with the fixed IOMMU page size of 16k.
The DARTs found on Apple M1 Pro/Max/Ultra use another different pte
format which is even less compatible. To support an output address size
of 42 bit the address is shifted down by 4. Subpage protection is
mandatory and bit 1 signifies uncached mappings used by the display
controller.
It would be advantageous to share code for all known Apple DART
variants to support common features. The page table allocator for DARTs
is less complex since it uses a two levels of translation table without
support for huge pages.
Signed-off-by: Janne Grunau
---
Changes in v3:
- move APPLE_DART to its own io-pgtable implementation, copied from
io-pgtable-arm and simplified
Changes in v2:
- add APPLE_DART2 io-pgtable format
MAINTAINERS | 1 +
drivers/iommu/Kconfig | 1 -
drivers/iommu/Makefile | 2 +-
drivers/iommu/io-pgtable-arm.c | 63
drivers/iommu/io-pgtable-dart.c | 580
drivers/iommu/io-pgtable.c | 2 +
6 files changed, 584 insertions(+), 65 deletions(-)
create mode 100644 drivers/iommu/io-pgtable-dart.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 1fc9ead83d2a..028b7e31e589 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1848,6 +1848,7 @@ F:drivers/clk/clk-apple-nco.c
F: drivers/i2c/busses/i2c-pasemi-core.c
F: drivers/i2c/busses/i2c-pasemi-platform.c
F: drivers/iommu/apple-dart.c
+F: drivers/iommu/io-pgtable-dart.c
F: drivers/irqchip/irq-apple-aic.c
F: drivers/mailbox/apple-mailbox.c
F: drivers/nvme/host/apple.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index c79a0df090c0..ed6d8260f330 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -294,7 +294,6 @@ config APPLE_DART
tristate "Apple DART IOMMU Support"
depends on ARCH_APPLE || (COMPILE_TEST && !GENERIC_ATOMIC64)
select IOMMU_API
- select IOMMU_IO_PGTABLE_LPAE
default ARCH_APPLE
help
Support for Apple DART (Device Address Resolution Table) IOMMUs
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 44475a9b3eea..bd68c93bbd62 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -29,4 +29,4 @@ obj-$(CONFIG_HYPERV_IOMMU) += hyperv-iommu.o
obj-$(CONFIG_VIRTIO_IOMMU) += virtio-iommu.o
obj-$(CONFIG_IOMMU_SVA) += iommu-sva-lib.o io-pgfault.o
obj-$(CONFIG_SPRD_IOMMU) += sprd-iommu.o
-obj-$(CONFIG_APPLE_DART) += apple-dart.o
+obj-$(CONFIG_APPLE_DART) += apple-dart.o io-pgtable-dart.o
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 94ff319ae8ac..d7f5e23da643 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -130,9 +130,6 @@
#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))
@@ -406,15 +403,6 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
arm_lpae_io_pgtable *data,
{
arm_lpae_iopte pte;
- if (data->iop.fmt == 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;
@@ -1107,52 +1095,6 @@ 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;
- int i;
-
- if (cfg->oas > 36)
- return NULL;
-
- data = arm_lpae_alloc_pgtable(cfg);
- if (!data)
- return NULL;
-
- /*
-* The table format itself always uses two levels, but the total VA
-* space is mapped by four separate tables, making the MMIO registers
-* an effective "level 1". For simplicity, though, we treat this
-* equivalently to LPAE stage 2 concatenation at level 2, with the
-* additional TTBRs each just pointing at consecutive pages.
-*/
- if (data->start_level < 1)
- goto out_free_data;
- if (data->start_level == 1 &am
[PATCH v3 1/5] dt-bindings: iommu: dart: add t6000 compatible
From: Sven Peter The M1 Max/Pro SoCs come with a new DART variant that is incompatible with the previous one. Add a new compatible for those. Signed-off-by: Sven Peter Acked-by: Rob Herring Signed-off-by: Janne Grunau --- (no changes since v2) Changes in v2: - added Rob's Acked-by: Documentation/devicetree/bindings/iommu/apple,dart.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/iommu/apple,dart.yaml b/Documentation/devicetree/bindings/iommu/apple,dart.yaml index 82ad669feef7..06af2bacbe97 100644 --- a/Documentation/devicetree/bindings/iommu/apple,dart.yaml +++ b/Documentation/devicetree/bindings/iommu/apple,dart.yaml @@ -22,7 +22,9 @@ description: |+ properties: compatible: -const: apple,t8103-dart +enum: + - apple,t8103-dart + - apple,t6000-dart reg: maxItems: 1 -- 2.35.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3 4/5] iommu/io-pgtable-dart: Add DART PTE support for t6000
From: Sven Peter
The DARTs present in the M1 Pro/Max/Ultra SoC use a diffent PTE format.
They support a 42bit physical address space by shifting the paddr and
extending its mask inside the PTE.
They also come with mandatory sub-page protection now which we just
configure to always allow access to the entire page. This feature is
already present but optional on the previous DARTs which allows to
unconditionally configure it.
Signed-off-by: Sven Peter
Co-developed-by: Janne Grunau
Signed-off-by: Janne Grunau
---
Changes in v3:
- apply change to io-pgtable-dart.c
- handle pte <> paddr conversion based on the pte format instead of
the output address size
Changes in v2:
- add APPLE_DART2 PTE format
drivers/iommu/io-pgtable-dart.c | 51 +++--
drivers/iommu/io-pgtable.c | 1 +
include/linux/io-pgtable.h | 1 +
3 files changed, 45 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/io-pgtable-dart.c b/drivers/iommu/io-pgtable-dart.c
index fa8025c03bb5..9c3c2505f3dc 100644
--- a/drivers/iommu/io-pgtable-dart.c
+++ b/drivers/iommu/io-pgtable-dart.c
@@ -68,12 +68,19 @@
#define APPLE_DART_PTE_SUBPAGE_END GENMASK_ULL(51, 40)
#define APPLE_DART1_PADDR_MASK GENMASK_ULL(35, 12)
+#define APPLE_DART2_PADDR_MASK GENMASK_ULL(37, 10)
+#define APPLE_DART2_PADDR_SHIFT(4)
/* Apple DART1 protection bits */
#define APPLE_DART1_PTE_PROT_NO_READ BIT(8)
#define APPLE_DART1_PTE_PROT_NO_WRITE BIT(7)
#define APPLE_DART1_PTE_PROT_SP_DISBIT(1)
+/* Apple DART2 protection bits */
+#define APPLE_DART2_PTE_PROT_NO_READ BIT(3)
+#define APPLE_DART2_PTE_PROT_NO_WRITE BIT(2)
+#define APPLE_DART2_PTE_PROT_NO_CACHE BIT(1)
+
/* marks PTE as valid */
#define APPLE_DART_PTE_VALID BIT(0)
@@ -101,13 +108,31 @@ static inline bool iopte_leaf(dart_iopte pte, int lvl,
static dart_iopte paddr_to_iopte(phys_addr_t paddr,
struct dart_io_pgtable *data)
{
- return paddr & APPLE_DART1_PADDR_MASK;
+ dart_iopte pte;
+
+ if (data->iop.fmt == APPLE_DART)
+ return paddr & APPLE_DART1_PADDR_MASK;
+
+ /* format is APPLE_DART2 */
+ pte = paddr >> APPLE_DART2_PADDR_SHIFT;
+ pte &= APPLE_DART2_PADDR_MASK;
+
+ return pte;
}
static phys_addr_t iopte_to_paddr(dart_iopte pte,
struct dart_io_pgtable *data)
{
- return pte & APPLE_DART1_PADDR_MASK;
+ u64 paddr;
+
+ if (data->iop.fmt == APPLE_DART)
+ return pte & APPLE_DART1_PADDR_MASK;
+
+ /* format is APPLE_DART2 */
+ paddr = pte & APPLE_DART2_PADDR_MASK;
+ paddr <<= APPLE_DART2_PADDR_SHIFT;
+
+ return paddr;
}
static void *__dart_alloc_pages(size_t size, gfp_t gfp,
@@ -139,7 +164,7 @@ static void __dart_init_pte(struct dart_io_pgtable *data,
size_t sz = DART_BLOCK_SIZE(lvl, data);
int i;
- if (lvl == DART_MAX_LEVELS - 1)
+ if (lvl == DART_MAX_LEVELS - 1 && data->iop.fmt == APPLE_DART)
pte |= APPLE_DART1_PTE_PROT_SP_DIS;
pte |= APPLE_DART_PTE_VALID;
@@ -251,10 +276,20 @@ static dart_iopte dart_prot_to_pte(struct dart_io_pgtable
*data,
{
dart_iopte pte = 0;
- if (!(prot & IOMMU_WRITE))
- pte |= APPLE_DART1_PTE_PROT_NO_WRITE;
- if (!(prot & IOMMU_READ))
- pte |= APPLE_DART1_PTE_PROT_NO_READ;
+ if (data->iop.fmt == APPLE_DART) {
+ if (!(prot & IOMMU_WRITE))
+ pte |= APPLE_DART1_PTE_PROT_NO_WRITE;
+ if (!(prot & IOMMU_READ))
+ pte |= APPLE_DART1_PTE_PROT_NO_READ;
+ }
+ if (data->iop.fmt == APPLE_DART2) {
+ if (!(prot & IOMMU_WRITE))
+ pte |= APPLE_DART2_PTE_PROT_NO_WRITE;
+ if (!(prot & IOMMU_READ))
+ pte |= APPLE_DART2_PTE_PROT_NO_READ;
+ if (!(prot & IOMMU_CACHE))
+ pte |= APPLE_DART2_PTE_PROT_NO_CACHE;
+ }
return pte;
}
@@ -536,7 +571,7 @@ apple_dart_alloc_pgtable(struct io_pgtable_cfg *cfg, void
*cookie)
if (!cfg->coherent_walk)
return NULL;
- if (cfg->oas > 36)
+ if (cfg->oas != 36 && cfg->oas != 42)
return NULL;
data = dart_alloc_pgtable(cfg);
diff --git a/drivers/iommu/io-pgtable.c b/drivers/iommu/io-pgtable.c
index e6edc6686859..a5d0f01afa7b 100644
--- a/drivers/iommu/io-pgtable.c
+++ b/drivers/iommu/io-pgtable.c
@@ -23,6 +23,7 @@ io_pgtable_init_table[IO_PGTABLE_NUM_FMTS] = {
#endif
#ifdef CONFIG_APPLE_DART
[APPLE_DART] = _pgtable_apple_dart_init_fns,
+ [APPLE_DART2] = _pgtable_apple_dart_init_fns,
#endif
#ifdef CONFIG_IOMMU_IO_PGTABLE_ARMV7S
[ARM_V7S] = _pgtable_arm_v7s_init_fns,
diff --git a/include/linu
[PATCH v3 5/5] iommu: dart: Support t6000 variant
From: Sven Peter
The M1 Pro/Max/Ultra SoCs come with a new variant of DART which
supports a larger physical address space with a different PTE format.
Pass through the correct paddr address space size and the PTE format
to the io-pgtable code which will take care of the rest.
Signed-off-by: Sven Peter
Co-developed-by: Janne Grunau
Signed-off-by: Janne Grunau
---
Changes in v3:
- apply change to io-pgtable-dart.c
Changes in v2:
- use APPLE_DART2 PTE format for dart-t6000
drivers/iommu/apple-dart.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/apple-dart.c b/drivers/iommu/apple-dart.c
index 8af0242a90d9..e5793c0d08b4 100644
--- a/drivers/iommu/apple-dart.c
+++ b/drivers/iommu/apple-dart.c
@@ -81,10 +81,16 @@
#define DART_TTBR_VALID BIT(31)
#define DART_TTBR_SHIFT 12
+struct apple_dart_hw {
+ u32 oas;
+ enum io_pgtable_fmt fmt;
+};
+
/*
* Private structure associated with each DART device.
*
* @dev: device struct
+ * @hw: SoC-specific hardware data
* @regs: mapped MMIO region
* @irq: interrupt number, can be shared with other DARTs
* @clks: clocks associated with this DART
@@ -98,6 +104,7 @@
*/
struct apple_dart {
struct device *dev;
+ const struct apple_dart_hw *hw;
void __iomem *regs;
@@ -421,13 +428,13 @@ static int apple_dart_finalize_domain(struct iommu_domain
*domain,
pgtbl_cfg = (struct io_pgtable_cfg){
.pgsize_bitmap = dart->pgsize,
.ias = 32,
- .oas = 36,
+ .oas = dart->hw->oas,
.coherent_walk = 1,
.iommu_dev = dart->dev,
};
dart_domain->pgtbl_ops =
- alloc_io_pgtable_ops(APPLE_DART, _cfg, domain);
+ alloc_io_pgtable_ops(dart->hw->fmt, _cfg, domain);
if (!dart_domain->pgtbl_ops) {
ret = -ENOMEM;
goto done;
@@ -858,6 +865,7 @@ static int apple_dart_probe(struct platform_device *pdev)
return -ENOMEM;
dart->dev = dev;
+ dart->hw = of_device_get_match_data(dev);
spin_lock_init(>lock);
dart->regs = devm_platform_get_and_ioremap_resource(pdev, 0, );
@@ -946,8 +954,18 @@ static int apple_dart_remove(struct platform_device *pdev)
return 0;
}
+static const struct apple_dart_hw apple_dart_hw_t8103 = {
+ .oas = 36,
+ .fmt = APPLE_DART,
+};
+static const struct apple_dart_hw apple_dart_hw_t6000 = {
+ .oas = 42,
+ .fmt = APPLE_DART2,
+};
+
static const struct of_device_id apple_dart_of_match[] = {
- { .compatible = "apple,t8103-dart", .data = NULL },
+ { .compatible = "apple,t8103-dart", .data = _dart_hw_t8103 },
+ { .compatible = "apple,t6000-dart", .data = _dart_hw_t6000 },
{},
};
MODULE_DEVICE_TABLE(of, apple_dart_of_match);
--
2.35.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3 3/5] iommu/io-pgtable: Add DART subpage protection support
From: Sven Peter DART allows to only expose a subpage to the device. While this is an optional feature on the M1 DARTs the new ones present on the Pro/Max models require this field in every PTE. Signed-off-by: Sven Peter Signed-off-by: Janne Grunau --- Changes in v3: - apply change to io-pgtable-dart.c drivers/iommu/io-pgtable-dart.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/iommu/io-pgtable-dart.c b/drivers/iommu/io-pgtable-dart.c index 0c5222942c65..fa8025c03bb5 100644 --- a/drivers/iommu/io-pgtable-dart.c +++ b/drivers/iommu/io-pgtable-dart.c @@ -14,6 +14,7 @@ #define pr_fmt(fmt)"dart io-pgtable: " fmt #include +#include #include #include #include @@ -63,6 +64,9 @@ /* Calculate the block/page mapping size at level l for pagetable in d. */ #define DART_BLOCK_SIZE(l, d) (1ULL << DART_LVL_SHIFT(l, d)) +#define APPLE_DART_PTE_SUBPAGE_START GENMASK_ULL(63, 52) +#define APPLE_DART_PTE_SUBPAGE_END GENMASK_ULL(51, 40) + #define APPLE_DART1_PADDR_MASK GENMASK_ULL(35, 12) /* Apple DART1 protection bits */ @@ -140,6 +144,10 @@ static void __dart_init_pte(struct dart_io_pgtable *data, pte |= APPLE_DART_PTE_VALID; + /* subpage protection: always allow access to the entire page */ + pte |= FIELD_PREP(APPLE_DART_PTE_SUBPAGE_START, 0); + pte |= FIELD_PREP(APPLE_DART_PTE_SUBPAGE_END, 0xfff); + for (i = 0; i < num_entries; i++) ptep[i] = pte | paddr_to_iopte(paddr + i * sz, data); } -- 2.35.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3 0/5] iommu: M1 Pro/Max DART support
Hej, this is the next attempt adding support for the DART found in Apple's M1 Pro/Max/Ultra. This adds a separate io-pgtable implementation for DART. As already mentioned in v2 the pte format is not fully compatible with io-pgtable-arm. Especially the 2nd least significant bit is used and is not available to tag tables/pages. io-pgtable-dart.c is copied from io-pgtable-arm.c and support for unused features is removed. Support for 4k IO pages is left for A7 to A11 SoCs as there's work underway to run Linux on them. The incompatibilities between both Apple DART pte seems manageable in their own io-pgtable implementation. A short list of the known differences: - the physical addresses are shifted left by 4 bits and and have 2 more bits inside the PTE entries - the read/write protection flags are at a different position - the subpage protection feature is now mandatory. For Linux we can just configure it to always allow access to the entire page. - BIT(1) tags "uncached" mappings (used for the display controller) There is second type of DART (t8110) present on M1 Pro/Max SoCs which uses the same PTE format as t6000. Changes in v3: - move APPLE_DART to its own io-pgtable implementation, copied from io-pgtable-arm and simplified Changes in v2: - added Rob's Acked-by: - add APPLE_DART2 io-pgtable format Janne Grunau (1): iommu/io-pgtable: Move Apple DART support to its own file Sven Peter (4): dt-bindings: iommu: dart: add t6000 compatible iommu/io-pgtable: Add DART subpage protection support iommu/io-pgtable-dart: Add DART PTE support for t6000 iommu: dart: Support t6000 variant .../devicetree/bindings/iommu/apple,dart.yaml | 4 +- MAINTAINERS | 1 + drivers/iommu/Kconfig | 1 - drivers/iommu/Makefile| 2 +- drivers/iommu/apple-dart.c| 24 +- drivers/iommu/io-pgtable-arm.c| 63 -- drivers/iommu/io-pgtable-dart.c | 623 ++ drivers/iommu/io-pgtable.c| 3 + include/linux/io-pgtable.h| 1 + 9 files changed, 653 insertions(+), 69 deletions(-) create mode 100644 drivers/iommu/io-pgtable-dart.c -- 2.35.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 2/5] iommu: Implement of_iommu_get_resv_regions()
On 2022-05-12 21:00:49 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> This is an implementation that IOMMU drivers can use to obtain reserved
> memory regions from a device tree node. It uses the reserved-memory DT
> bindings to find the regions associated with a given device. If these
> regions are marked accordingly, identity mappings will be created for
> them in the IOMMU domain that the devices will be attached to.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v5:
> - update for new "iommu-addresses" device tree bindings
>
> Changes in v4:
> - fix build failure on !CONFIG_OF_ADDRESS
>
> Changes in v3:
> - change "active" property to identity mapping flag that is part of the
> memory region specifier (as defined by #memory-region-cells) to allow
> per-reference flags to be used
>
> Changes in v2:
> - use "active" property to determine whether direct mappings are needed
>
> drivers/iommu/of_iommu.c | 90
> include/linux/of_iommu.h | 8
> 2 files changed, 98 insertions(+)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 5696314ae69e..9e341b5e307f 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -11,12 +11,15 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
>
> +#include
> +
> #define NO_IOMMU 1
>
> static int of_iommu_xlate(struct device *dev,
> @@ -172,3 +175,90 @@ const struct iommu_ops *of_iommu_configure(struct device
> *dev,
>
> return ops;
> }
> +
> +/**
> + * of_iommu_get_resv_regions - reserved region driver helper for device tree
> + * @dev: device for which to get reserved regions
> + * @list: reserved region list
> + *
> + * IOMMU drivers can use this to implement their .get_resv_regions() callback
> + * for memory regions attached to a device tree node. See the reserved-memory
> + * device tree bindings on how to use these:
> + *
> + * Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> + */
> +void of_iommu_get_resv_regions(struct device *dev, struct list_head *list)
> +{
> +#if IS_ENABLED(CONFIG_OF_ADDRESS)
> + struct of_phandle_iterator it;
> + int err;
> +
> + of_for_each_phandle(, err, dev->of_node, "memory-region", NULL, 0) {
> + struct iommu_resv_region *region;
> + struct resource res;
> + const __be32 *maps;
> + int size;
Adding 'if (!of_device_is_available(it.node)) continue;' here would help
backwards compatibility. My plan was to add the reserved regions with
"iommu-addresses" with all zero adresses and sizes with status =
"disabled" to the devicetree. A bootloader update is required to fill
those.
> +
> + memset(, 0, sizeof(res));
> +
> + /*
> + * The "reg" property is optional and can be omitted by
> reserved-memory regions
> + * that represent reservations in the IOVA space, which are
> regions that should
> + * not be mapped.
> + */
> + if (of_find_property(it.node, "reg", NULL)) {
> + err = of_address_to_resource(it.node, 0, );
> + if (err < 0) {
> + dev_err(dev, "failed to parse memory region
> %pOF: %d\n",
> + it.node, err);
> + continue;
> + }
> + }
> +
> + maps = of_get_property(it.node, "iommu-addresses", );
> + if (maps) {
> + const __be32 *end = maps + size / sizeof(__be32);
> + struct device_node *np;
> + unsigned int index = 0;
> + u32 phandle;
> + int na, ns;
> +
> + while (maps < end) {
> + phys_addr_t start, end;
> + size_t length;
> +
> + phandle = be32_to_cpup(maps++);
> + np = of_find_node_by_phandle(phandle);
> + na = of_n_addr_cells(np);
> + ns = of_n_size_cells(np);
> +
> + start = of_translate_dma_address(np, maps);
> + length = of_read_number(maps + na, ns);
alternatively we could handle mappings/reservations with length 0 as
error and skip them.
> + end = start + length - 1;
> +
> + if (np == dev->of_node) {
> + int prot = IOMMU_READ | IOMMU_WRITE;
> + enum iommu_resv_type type;
> +
> + /*
> + * IOMMU regions without an associated
> physical region
> + * cannot be mapped and are simply
>
Re: [PATCH v5 1/5] dt-bindings: reserved-memory: Document iommu-addresses
On 2022-05-12 21:00:48 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> This adds the "iommu-addresses" property to reserved-memory nodes, which
> allow describing the interaction of memory regions with IOMMUs. Two use-
> cases are supported:
>
> 1. Static mappings can be described by pairing the "iommu-addresses"
> property with a "reg" property. This is mostly useful for adopting
> firmware-allocated buffers via identity mappings. One common use-
> case where this is required is if early firmware or bootloaders
> have set up a bootsplash framebuffer that a display controller is
> actively scanning out from during the operating system boot
> process.
>
> 2. If an "iommu-addresses" property exists without a "reg" property,
> the reserved-memory node describes an IOVA reservation. Such memory
> regions are excluded from the IOVA space available to operating
> system drivers and can be used for regions that must not be used to
> map arbitrary buffers.
>
> Each mapping or reservation is tied to a specific device via a phandle
> to the device's device tree node. This allows a reserved-memory region
> to be reused across multiple devices.
>
> Signed-off-by: Thierry Reding
> ---
> .../reserved-memory/reserved-memory.txt | 1 -
> .../reserved-memory/reserved-memory.yaml | 62 +++
> include/dt-bindings/reserved-memory.h | 8 +++
> 3 files changed, 70 insertions(+), 1 deletion(-)
> delete mode 100644
> Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> create mode 100644 include/dt-bindings/reserved-memory.h
>
> diff --git
> a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> deleted file mode 100644
> index 1810701a8509..
> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> +++ /dev/null
> @@ -1 +0,0 @@
> -This file has been moved to reserved-memory.yaml.
> diff --git
> a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
> b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
> index 7a0744052ff6..3a769aa66e1c 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
> @@ -52,6 +52,30 @@ properties:
>Address and Length pairs. Specifies regions of memory that are
>acceptable to allocate from.
>
> + iommu-addresses:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +description: >
> + A list of phandle and specifier pairs that describe static IO virtual
> + address space mappings and carveouts associated with a given reserved
> + memory region. The phandle in the first cell refers to the device for
> + which the mapping or carveout is to be created.
> +
> + The specifier consists of an address/size pair and denotes the IO
> + virtual address range of the region for the given device. The exact
> + format depends on the values of the "#address-cells" and "#size-cells"
> + properties of the device referenced via the phandle.
> +
> + When used in combination with a "reg" property, an IOVA mapping is to
> + be established for this memory region. One example where this can be
> + useful is to create an identity mapping for physical memory that the
> + firmware has configured some hardware to access (such as a bootsplash
> + framebuffer).
> +
> + If no "reg" property is specified, the "iommu-addresses" property
> + defines carveout regions in the IOVA space for the given device. This
> + can be useful if a certain memory region should not be mapped through
> + the IOMMU.
> +
>no-map:
> type: boolean
> description: >
> @@ -97,4 +121,42 @@ oneOf:
>
> additionalProperties: true
>
> +examples:
> + - |
> +reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + adsp: reservation-adsp {
> +/*
> + * Restrict IOVA mappings for ADSP buffers to the 512 MiB region
> + * from 0x4000 - 0x5fff. Anything outside is reserved by
> + * the ADSP for I/O memory and private memory allocations.
> + */
> +iommu-addresses = <0x0 0x 0x00 0x4000>,
> + <0x0 0x6000 0xff 0xa000>;
This misses the device's phandle. One could argue it's not necessary for
reservations but it will complicate the parsing code and the current
parsing code is not prepared for it.
> + };
> +
> + fb: framebuffer@9000 {
> +reg = <0x0 0x9000 0x0 0x0080>;
> +iommu-addresses = < 0x0 0x9000 0x0 0x0080>;
> + };
> +};
> +
> +bus@0 {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + adsp@299 {
> +
Re: [PATCH v5 0/5] iommu: Support mappings/reservations in reserved-memory regions
Hej,
I'm working on the display controller for Apple silicon SoCs and will
add some comments with support for it in mind.
added as...@lists.linux.dev to CC for the Apple silicon related aspects
On 2022-05-12 21:00:47 +0200, Thierry Reding wrote:
>
> this is another attempt at solving the problem of passing IOMMU
> configuration via device tree. It has significantly evolved since the
> last attempt, based on the discussion that followed. The discussion can
> be found here:
>
>
> https://lore.kernel.org/all/20210423163234.3651547-1-thierry.red...@gmail.com/
>
> Rather than using a memory-region specifier, this new version introduces
> a new "iommu-addresses" property for the reserved-memory regions
> themselves.
If experimented with both proposed bindings for dcp and I think this
binding is easer to understand and to work with.
> These are used to describe either a static mapping or
> reservation that should be created for a given device. If both "reg" and
> "iommu-addresses" properties are given, a mapping will be created
> (typically this would be an identity mapping)
dcp on Apple silicon will not use identity mappings. The IOMMU supports
identity mapping but the pre-configured mappings setup by Apple's system
firmware will not work with identity mapping. It maps multiple regions
which are incompatible with a linear identity mapping. In addition the
embbeded aarch64 micro controllers used in the display subsystem appears
to use a heap mapped at low IOVA space starting at 0.
> whereas if only an "iommu-addresses" property is specified, a
> reservation for the specified range will be installed.
>
> An example is included in the DT bindings, but here is an extract of
> what I've used to test this:
>
> reserved-memory {
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
>
> /*
>* Creates an identity mapping for the framebuffer that
>* the firmware has setup to scan out a bootsplash from.
>*/
> fb: framebuffer@92cb2000 {
> reg = <0x0 0x92cb2000 0x0 0x0080>;
> iommu-addresses = < 0x0 0x92cb2000 0x0 0x0080>;
> };
The binding supports mapping the same region to multiple devices. The
code supports that and it will be used on Apple silicon. Not necessary
to extend and complicate the example for I wanted to mention it
explicitly.
>
> /*
>* Creates a reservation in the IOVA space to prevent
>* any buffers from being mapped to that region. Note
>* that on Tegra the range is actually quite different
>* from this, but it would conflict with the display
>* driver that I tested this against, so this is just
>* a dummy region for testing.
>*/
> adsp: reservation-adsp {
> iommu-addresses = < 0x0 0x9000 0x0 0x0001>;
> };
> };
>
> host1x@5000 {
> dc@5420 {
> memory-region = <>, <>;
> };
> };
>
> This is abbreviated a little to focus on the essentials. Note also that
> the ADSP reservation is not actually used on this device and the driver
> for this doesn't exist yet, but I wanted to include this variant for
> testing, because we'll want to use these bindings for the reservation
> use-case as well at some point.
>
> Adding Alyssa and Janne who have in the past tried to make these
> bindings work on Apple M1. Also adding Sameer from the Tegra audio team
> to look at the ADSP reservation and double-check that this is suitable
> for our needs.
The binding itself is sufficient for the needs of the display subsystem
on Apple silicon. The device tree parsing code for reserved regions is
of limited use in it's current form. We will have either to extend or
duplicate it to retrieve the non-identity mappings. That's our problem
to solve.
Janne
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 4/4] iommu: dart: Support t6000 variant
From: Sven Peter
The M1 Pro/Max/Ultra SoCs come with a new variant of DART which
supports a larger physical address space with a different PTE format.
Pass through the correct paddr address space size and the PTE format
to the io-pgtable code which will take care of the rest.
Signed-off-by: Sven Peter
Co-developed-by: Janne Grunau
Signed-off-by: Janne Grunau
---
Changes since v1:
- use APPLE_DART PTE format for dart-t6000
---
drivers/iommu/apple-dart.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/apple-dart.c b/drivers/iommu/apple-dart.c
index decafb07ad08..fe0dedd67fd8 100644
--- a/drivers/iommu/apple-dart.c
+++ b/drivers/iommu/apple-dart.c
@@ -81,10 +81,16 @@
#define DART_TTBR_VALID BIT(31)
#define DART_TTBR_SHIFT 12
+struct apple_dart_hw {
+ u32 oas;
+ enum io_pgtable_fmt fmt;
+};
+
/*
* Private structure associated with each DART device.
*
* @dev: device struct
+ * @hw: SoC-specific hardware data
* @regs: mapped MMIO region
* @irq: interrupt number, can be shared with other DARTs
* @clks: clocks associated with this DART
@@ -98,6 +104,7 @@
*/
struct apple_dart {
struct device *dev;
+ const struct apple_dart_hw *hw;
void __iomem *regs;
@@ -421,13 +428,13 @@ static int apple_dart_finalize_domain(struct iommu_domain
*domain,
pgtbl_cfg = (struct io_pgtable_cfg){
.pgsize_bitmap = dart->pgsize,
.ias = 32,
- .oas = 36,
+ .oas = dart->hw->oas,
.coherent_walk = 1,
.iommu_dev = dart->dev,
};
dart_domain->pgtbl_ops =
- alloc_io_pgtable_ops(APPLE_DART, _cfg, domain);
+ alloc_io_pgtable_ops(dart->hw->fmt, _cfg, domain);
if (!dart_domain->pgtbl_ops) {
ret = -ENOMEM;
goto done;
@@ -857,6 +864,7 @@ static int apple_dart_probe(struct platform_device *pdev)
return -ENOMEM;
dart->dev = dev;
+ dart->hw = of_device_get_match_data(dev);
spin_lock_init(>lock);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -946,8 +954,18 @@ static int apple_dart_remove(struct platform_device *pdev)
return 0;
}
+static const struct apple_dart_hw apple_dart_hw_t8103 = {
+ .oas = 36,
+ .fmt = APPLE_DART,
+};
+static const struct apple_dart_hw apple_dart_hw_t6000 = {
+ .oas = 42,
+ .fmt = APPLE_DART2,
+};
+
static const struct of_device_id apple_dart_of_match[] = {
- { .compatible = "apple,t8103-dart", .data = NULL },
+ { .compatible = "apple,t8103-dart", .data = _dart_hw_t8103 },
+ { .compatible = "apple,t6000-dart", .data = _dart_hw_t6000 },
{},
};
MODULE_DEVICE_TABLE(of, apple_dart_of_match);
--
2.35.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 1/4] dt-bindings: iommu: dart: add t6000 compatible
From: Sven Peter The M1 Max/Pro SoCs come with a new DART variant that is incompatible with the previous one. Add a new compatible for those. Signed-off-by: Sven Peter Acked-by: Rob Herring --- v2 changes: - added Rob's Acked-by: --- Documentation/devicetree/bindings/iommu/apple,dart.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/iommu/apple,dart.yaml b/Documentation/devicetree/bindings/iommu/apple,dart.yaml index 82ad669feef7..06af2bacbe97 100644 --- a/Documentation/devicetree/bindings/iommu/apple,dart.yaml +++ b/Documentation/devicetree/bindings/iommu/apple,dart.yaml @@ -22,7 +22,9 @@ description: |+ properties: compatible: -const: apple,t8103-dart +enum: + - apple,t8103-dart + - apple,t6000-dart reg: maxItems: 1 -- 2.35.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 0/4] iommu: M1 Pro/Max DART support
Hej, I've taken over this series to add support for DART on M1 Pro/Max from Sven. Since v1 we have discovered further differences in the PTE format. It has four differences which makes it incompatible with the one in the M1: - the physical addresses are shifted left by 4 bits and and have 2 more bits inside the PTE entries - the read/write protection flags are at a different position - the subpage protection feature is now mandatory. For Linux we can just configure it to always allow access to the entire page. - BIT(1) tags "uncached" mappings (used for the display controller) The last difference is the most troublesome since it makes the PTE format incomaptible with iopte_type(). Handling this inside io-pgtable-arm.c seems manageable since DART supports just a single block size. It opens the question at which point we decide that DART uses its own io_pgtable_ops. There is second type of DART (t8110) present on M1 Pro/Max SoCs which uses the same PTE format as t6000. Janne Sven Peter (4): dt-bindings: iommu: dart: add t6000 compatible iommu/io-pgtable: Add DART subpage protection support iommu/io-pgtable: Add DART PTE support for t6000 iommu: dart: Support t6000 variant .../devicetree/bindings/iommu/apple,dart.yaml | 4 +- drivers/iommu/apple-dart.c| 24 +- drivers/iommu/io-pgtable-arm.c| 76 ++- drivers/iommu/io-pgtable.c| 1 + include/linux/io-pgtable.h| 3 + 5 files changed, 101 insertions(+), 7 deletions(-) base-commit: 3123109284176b1532874591f7c81f3837bbdc17 -- 2.35.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 3/4] iommu/io-pgtable: Add DART PTE support for t6000
From: Sven Peter
The DARTs present in the M1 Pro/Max/Ultra SoC use a diffent PTE format.
They support a 42bit physical address space by shifting the paddr and
extending its mask inside the PTE.
PTE flags are incompatible with iopte_type() since BIT(1) in the PTE
tags "uncached" mappings.
They also come with mandatory sub-page protection now which we just
configure to always allow access to the entire page. This feature is
already present but optional on the previous DARTs which allows to
unconditionally configure it.
Signed-off-by: Sven Peter
Co-developed-by: Janne Grunau
Signed-off-by: Janne Grunau
---
Changes since v1:
- add APPLE_DART2 PTE format
---
drivers/iommu/io-pgtable-arm.c | 68 --
drivers/iommu/io-pgtable.c | 1 +
include/linux/io-pgtable.h | 3 ++
3 files changed, 68 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 71570bbc9096..f9121251fb57 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -134,9 +134,20 @@
#define APPLE_DART_PTE_PROT_NO_WRITE (1<<7)
#define APPLE_DART_PTE_PROT_NO_READ (1<<8)
+#define APPLE_DART_PTE_VALID BIT(0) // identical to ARM_LPAE_PTE_TYPE_BLOCK
+
+#define APPLE_DART2_PTE_PROT_NO_CACHE BIT(1)
+#define APPLE_DART2_PTE_PROT_NO_WRITE BIT(2)
+#define APPLE_DART2_PTE_PROT_NO_READ BIT(3)
+
#define APPLE_DART_PTE_SUBPAGE_START GENMASK_ULL(63, 52)
#define APPLE_DART_PTE_SUBPAGE_END GENMASK_ULL(51, 40)
+#define APPLE_DART_PADDR_MASK_PS_36BIT GENMASK_ULL(35, 12)
+#define APPLE_DART_PADDR_SHIFT_PS_36BIT(0)
+#define APPLE_DART_PADDR_MASK_PS_42BIT GENMASK_ULL(37, 10)
+#define APPLE_DART_PADDR_SHIFT_PS_42BIT(4)
+
/* IOPTE accessors */
#define iopte_deref(pte,d) __va(iopte_to_paddr(pte, d))
@@ -160,6 +171,10 @@ typedef u64 arm_lpae_iopte;
static inline bool iopte_leaf(arm_lpae_iopte pte, int lvl,
enum io_pgtable_fmt fmt)
{
+ if (fmt == APPLE_DART2)
+ return lvl == (ARM_LPAE_MAX_LEVELS - 1) &&
+ FIELD_GET(APPLE_DART_PTE_VALID, pte);
+
if (lvl == (ARM_LPAE_MAX_LEVELS - 1) && fmt != ARM_MALI_LPAE)
return iopte_type(pte) == ARM_LPAE_PTE_TYPE_PAGE;
@@ -171,6 +186,13 @@ static arm_lpae_iopte paddr_to_iopte(phys_addr_t paddr,
{
arm_lpae_iopte pte = paddr;
+ if (data->iop.fmt == APPLE_DART || data->iop.fmt == APPLE_DART2) {
+ pte = paddr >> data->iop.cfg.apple_dart_cfg.paddr_shift;
+ pte &= data->iop.cfg.apple_dart_cfg.paddr_mask;
+
+ return pte;
+ }
+
/* Of the bits which overlap, either 51:48 or 15:12 are always RES0 */
return (pte | (pte >> (48 - 12))) & ARM_LPAE_PTE_ADDR_MASK;
}
@@ -180,6 +202,12 @@ static phys_addr_t iopte_to_paddr(arm_lpae_iopte pte,
{
u64 paddr = pte & ARM_LPAE_PTE_ADDR_MASK;
+ if (data->iop.fmt == APPLE_DART || data->iop.fmt == APPLE_DART2) {
+ paddr = pte & data->iop.cfg.apple_dart_cfg.paddr_mask;
+ paddr <<= data->iop.cfg.apple_dart_cfg.paddr_shift;
+ return paddr;
+ }
+
if (ARM_LPAE_GRANULE(data) < SZ_64K)
return paddr;
@@ -272,12 +300,13 @@ static void __arm_lpae_init_pte(struct
arm_lpae_io_pgtable *data,
size_t sz = ARM_LPAE_BLOCK_SIZE(lvl, data);
int i;
- if (data->iop.fmt != ARM_MALI_LPAE && lvl == ARM_LPAE_MAX_LEVELS - 1)
+ if ((data->iop.fmt != ARM_MALI_LPAE && data->iop.fmt != APPLE_DART2) &&
+ lvl == ARM_LPAE_MAX_LEVELS - 1)
pte |= ARM_LPAE_PTE_TYPE_PAGE;
else
pte |= ARM_LPAE_PTE_TYPE_BLOCK;
- if (data->iop.fmt == APPLE_DART) {
+ if (data->iop.fmt == APPLE_DART || data->iop.fmt == APPLE_DART2) {
/* subpage protection: always allow access to the entire page */
pte |= FIELD_PREP(APPLE_DART_PTE_SUBPAGE_START, 0);
pte |= FIELD_PREP(APPLE_DART_PTE_SUBPAGE_END, 0xfff);
@@ -330,7 +359,18 @@ static arm_lpae_iopte
arm_lpae_install_table(arm_lpae_iopte *table,
arm_lpae_iopte old, new;
struct io_pgtable_cfg *cfg = >iop.cfg;
- new = paddr_to_iopte(__pa(table), data) | ARM_LPAE_PTE_TYPE_TABLE;
+ new = paddr_to_iopte(__pa(table), data);
+ /*
+* The APPLE_DART2 PTE format is incompatible with ARM_LPAE_PTE_TYPE_*
+* since BIT(1) is used to tag "uncached" mappings.
+* This is the only place where ARM_LPAE_PTE_TYPE_TABLE has to be
+* taken into account since APPLE_DART2 supports only a single block
+* size.
+*/
+ if (data->iop.fmt == APPLE_DART2)
+ new |= APPLE_DART_PTE_VALID;
+ else
+ new |= ARM_LPAE
[PATCH v2 2/4] iommu/io-pgtable: Add DART subpage protection support
From: Sven Peter
DART allows to only expose a subpage to the device. While this is an
optional feature on the M1 DARTs the new ones present on the Pro/Max
models require this field in every PTE.
Signed-off-by: Sven Peter
---
drivers/iommu/io-pgtable-arm.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 94ff319ae8ac..71570bbc9096 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -10,6 +10,7 @@
#define pr_fmt(fmt)"arm-lpae io-pgtable: " fmt
#include
+#include
#include
#include
#include
@@ -133,6 +134,9 @@
#define APPLE_DART_PTE_PROT_NO_WRITE (1<<7)
#define APPLE_DART_PTE_PROT_NO_READ (1<<8)
+#define APPLE_DART_PTE_SUBPAGE_START GENMASK_ULL(63, 52)
+#define APPLE_DART_PTE_SUBPAGE_END GENMASK_ULL(51, 40)
+
/* IOPTE accessors */
#define iopte_deref(pte,d) __va(iopte_to_paddr(pte, d))
@@ -273,6 +277,12 @@ static void __arm_lpae_init_pte(struct arm_lpae_io_pgtable
*data,
else
pte |= ARM_LPAE_PTE_TYPE_BLOCK;
+ if (data->iop.fmt == APPLE_DART) {
+ /* subpage protection: always allow access to the entire page */
+ pte |= FIELD_PREP(APPLE_DART_PTE_SUBPAGE_START, 0);
+ pte |= FIELD_PREP(APPLE_DART_PTE_SUBPAGE_END, 0xfff);
+ }
+
for (i = 0; i < num_entries; i++)
ptep[i] = pte | paddr_to_iopte(paddr + i * sz, data);
--
2.35.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier
On 2022-03-31 18:25:05 +0200, Thierry Reding wrote: > On Fri, Feb 11, 2022 at 12:15:44AM +0100, Janne Grunau wrote: > > On 2022-02-09 17:31:16 +0100, Thierry Reding wrote: > > > On Sun, Feb 06, 2022 at 11:27:00PM +0100, Janne Grunau wrote: > > > > On 2021-09-15 17:19:39 +0200, Thierry Reding wrote: > > > > > On Tue, Sep 07, 2021 at 07:44:44PM +0200, Thierry Reding wrote: > > > > > > On Tue, Sep 07, 2021 at 10:33:24AM -0500, Rob Herring wrote: > > > > > > > On Fri, Sep 3, 2021 at 10:36 AM Thierry Reding > > > > > > > wrote: > > > > > > > > > > > > > > > > On Fri, Sep 03, 2021 at 09:36:33AM -0500, Rob Herring wrote: > > > > > > > > > On Fri, Sep 3, 2021 at 8:52 AM Thierry Reding > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Fri, Sep 03, 2021 at 08:20:55AM -0500, Rob Herring wrote: > > > > > > > > > > > > > > > > > > > > > > Couldn't we keep this all in /reserved-memory? Just add > > > > > > > > > > > an iova > > > > > > > > > > > version of reg. Perhaps abuse 'assigned-address' for this > > > > > > > > > > > purpose. The > > > > > > > > > > > issue I see would be handling reserved iova areas without > > > > > > > > > > > a physical > > > > > > > > > > > area. That can be handled with just a iova and no reg. We > > > > > > > > > > > already have > > > > > > > > > > > a no reg case. > > > > > > > > > > > > > > > > > > > > I had thought about that initially. One thing I'm worried > > > > > > > > > > about is that > > > > > > > > > > every child node in /reserved-memory will effectively cause > > > > > > > > > > the memory > > > > > > > > > > that it described to be reserved. But we don't want that > > > > > > > > > > for regions > > > > > > > > > > that are "virtual only" (i.e. IOMMU reservations). > > > > > > > > > > > > > > > > > > By virtual only, you mean no physical mapping, just a region > > > > > > > > > of > > > > > > > > > virtual space, right? For that we'd have no 'reg' and > > > > > > > > > therefore no > > > > > > > > > (physical) reservation by the OS. It's similar to non-static > > > > > > > > > regions. > > > > > > > > > You need a specific handler for them. We'd probably want a > > > > > > > > > compatible > > > > > > > > > as well for these virtual reservations. > > > > > > > > > > > > > > > > Yeah, these would be purely used for reserving regions in the > > > > > > > > IOVA so > > > > > > > > that they won't be used by the IOVA allocator. Typically these > > > > > > > > would be > > > > > > > > used for cases where those addresses have some special meaning. > > > > > > > > > > > > > > > > Do we want something like: > > > > > > > > > > > > > > > > compatible = "iommu-reserved"; > > > > > > > > > > > > > > > > for these? Or would that need to be: > > > > > > > > > > > > > > > > compatible = "linux,iommu-reserved"; > > > > > > > > > > > > > > > > ? There seems to be a mix of vendor-prefix vs. non-vendor-prefix > > > > > > > > compatible strings in the reserved-memory DT bindings directory. > > > > > > > > > > > > > > I would not use 'linux,' here. > > > > > > > > > > > > > > > > > > > > > > > On the other hand, do we actually need the compatible string? > > > > > > > > Because we > > > > > > > > don't really want to associate much extra information
Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier
On 2022-02-09 17:31:16 +0100, Thierry Reding wrote: > On Sun, Feb 06, 2022 at 11:27:00PM +0100, Janne Grunau wrote: > > On 2021-09-15 17:19:39 +0200, Thierry Reding wrote: > > > On Tue, Sep 07, 2021 at 07:44:44PM +0200, Thierry Reding wrote: > > > > On Tue, Sep 07, 2021 at 10:33:24AM -0500, Rob Herring wrote: > > > > > On Fri, Sep 3, 2021 at 10:36 AM Thierry Reding > > > > > wrote: > > > > > > > > > > > > On Fri, Sep 03, 2021 at 09:36:33AM -0500, Rob Herring wrote: > > > > > > > On Fri, Sep 3, 2021 at 8:52 AM Thierry Reding > > > > > > > wrote: > > > > > > > > > > > > > > > > On Fri, Sep 03, 2021 at 08:20:55AM -0500, Rob Herring wrote: > > > > > > > > > > > > > > > > > > Couldn't we keep this all in /reserved-memory? Just add an > > > > > > > > > iova > > > > > > > > > version of reg. Perhaps abuse 'assigned-address' for this > > > > > > > > > purpose. The > > > > > > > > > issue I see would be handling reserved iova areas without a > > > > > > > > > physical > > > > > > > > > area. That can be handled with just a iova and no reg. We > > > > > > > > > already have > > > > > > > > > a no reg case. > > > > > > > > > > > > > > > > I had thought about that initially. One thing I'm worried about > > > > > > > > is that > > > > > > > > every child node in /reserved-memory will effectively cause the > > > > > > > > memory > > > > > > > > that it described to be reserved. But we don't want that for > > > > > > > > regions > > > > > > > > that are "virtual only" (i.e. IOMMU reservations). > > > > > > > > > > > > > > By virtual only, you mean no physical mapping, just a region of > > > > > > > virtual space, right? For that we'd have no 'reg' and therefore no > > > > > > > (physical) reservation by the OS. It's similar to non-static > > > > > > > regions. > > > > > > > You need a specific handler for them. We'd probably want a > > > > > > > compatible > > > > > > > as well for these virtual reservations. > > > > > > > > > > > > Yeah, these would be purely used for reserving regions in the IOVA > > > > > > so > > > > > > that they won't be used by the IOVA allocator. Typically these > > > > > > would be > > > > > > used for cases where those addresses have some special meaning. > > > > > > > > > > > > Do we want something like: > > > > > > > > > > > > compatible = "iommu-reserved"; > > > > > > > > > > > > for these? Or would that need to be: > > > > > > > > > > > > compatible = "linux,iommu-reserved"; > > > > > > > > > > > > ? There seems to be a mix of vendor-prefix vs. non-vendor-prefix > > > > > > compatible strings in the reserved-memory DT bindings directory. > > > > > > > > > > I would not use 'linux,' here. > > > > > > > > > > > > > > > > > On the other hand, do we actually need the compatible string? > > > > > > Because we > > > > > > don't really want to associate much extra information with this > > > > > > like we > > > > > > do for example with "shared-dma-pool". The logic to handle this > > > > > > would > > > > > > all be within the IOMMU framework. All we really need is for the > > > > > > standard reservation code to skip nodes that don't have a reg > > > > > > property > > > > > > so we don't reserve memory for "virtual-only" allocations. > > > > > > > > > > It doesn't hurt to have one and I can imagine we might want to iterate > > > > > over all the nodes. It's slightly easier and more common to iterate > > > > > over compatible nodes rather than nodes with some property. > > > > > > > &
Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier
On 2021-09-15 17:19:39 +0200, Thierry Reding wrote:
> On Tue, Sep 07, 2021 at 07:44:44PM +0200, Thierry Reding wrote:
> > On Tue, Sep 07, 2021 at 10:33:24AM -0500, Rob Herring wrote:
> > > On Fri, Sep 3, 2021 at 10:36 AM Thierry Reding
> > > wrote:
> > > >
> > > > On Fri, Sep 03, 2021 at 09:36:33AM -0500, Rob Herring wrote:
> > > > > On Fri, Sep 3, 2021 at 8:52 AM Thierry Reding
> > > > > wrote:
> > > > > >
> > > > > > On Fri, Sep 03, 2021 at 08:20:55AM -0500, Rob Herring wrote:
> > > > > > >
> > > > > > > Couldn't we keep this all in /reserved-memory? Just add an iova
> > > > > > > version of reg. Perhaps abuse 'assigned-address' for this
> > > > > > > purpose. The
> > > > > > > issue I see would be handling reserved iova areas without a
> > > > > > > physical
> > > > > > > area. That can be handled with just a iova and no reg. We already
> > > > > > > have
> > > > > > > a no reg case.
> > > > > >
> > > > > > I had thought about that initially. One thing I'm worried about is
> > > > > > that
> > > > > > every child node in /reserved-memory will effectively cause the
> > > > > > memory
> > > > > > that it described to be reserved. But we don't want that for regions
> > > > > > that are "virtual only" (i.e. IOMMU reservations).
> > > > >
> > > > > By virtual only, you mean no physical mapping, just a region of
> > > > > virtual space, right? For that we'd have no 'reg' and therefore no
> > > > > (physical) reservation by the OS. It's similar to non-static regions.
> > > > > You need a specific handler for them. We'd probably want a compatible
> > > > > as well for these virtual reservations.
> > > >
> > > > Yeah, these would be purely used for reserving regions in the IOVA so
> > > > that they won't be used by the IOVA allocator. Typically these would be
> > > > used for cases where those addresses have some special meaning.
> > > >
> > > > Do we want something like:
> > > >
> > > > compatible = "iommu-reserved";
> > > >
> > > > for these? Or would that need to be:
> > > >
> > > > compatible = "linux,iommu-reserved";
> > > >
> > > > ? There seems to be a mix of vendor-prefix vs. non-vendor-prefix
> > > > compatible strings in the reserved-memory DT bindings directory.
> > >
> > > I would not use 'linux,' here.
> > >
> > > >
> > > > On the other hand, do we actually need the compatible string? Because we
> > > > don't really want to associate much extra information with this like we
> > > > do for example with "shared-dma-pool". The logic to handle this would
> > > > all be within the IOMMU framework. All we really need is for the
> > > > standard reservation code to skip nodes that don't have a reg property
> > > > so we don't reserve memory for "virtual-only" allocations.
> > >
> > > It doesn't hurt to have one and I can imagine we might want to iterate
> > > over all the nodes. It's slightly easier and more common to iterate
> > > over compatible nodes rather than nodes with some property.
> > >
> > > > > Are these being global in DT going to be a problem? Presumably we have
> > > > > a virtual space per IOMMU. We'd know which IOMMU based on a device's
> > > > > 'iommus' and 'memory-region' properties, but within /reserved-memory
> > > > > we wouldn't be able to distinguish overlapping addresses from separate
> > > > > address spaces. Or we could have 2 different IOVAs for 1 physical
> > > > > space. That could be solved with something like this:
> > > > >
> > > > > iommu-addresses = < >;
> > > >
> > > > The only case that would be problematic would be if we have overlapping
> > > > physical regions, because that will probably trip up the standard code.
> > > >
> > > > But this could also be worked around by looking at iommu-addresses. For
> > > > example, if we had something like this:
> > > >
> > > > reserved-memory {
> > > > fb_dc0: fb@8000 {
> > > > reg = <0x8000 0x0100>;
> > > > iommu-addresses = <0xa000 0x0100>;
> > > > };
> > > >
> > > > fb_dc1: fb@8000 {
> > >
> > > You can't have 2 nodes with the same name (actually, you can, they
> > > just get merged together). Different names with the same unit-address
> > > is a dtc warning. I'd really like to make that a full blown
> > > overlapping region check.
> >
> > Right... so this would be a lot easier to deal with using that earlier
> > proposal where the IOMMU regions were a separate thing and referencing
> > the reserved-memory nodes. In those cases we could just have the
> > physical reservation for the framebuffer once (so we don't get any
> > duplicates or overlaps) and then have each IOVA reservation reference
> > that to create the mapping.
> >
> > >
> > > > reg = <0x8000 0x0100>;
> > > > iommu-addresses = <0xb000 0x0100>;
> > > > };
> > > > };
> > > >
> > > > We could make the code identify that
Re: [PATCH 0/4] iommu: M1 Pro/Max DART support
Hej, On 2021-11-17 22:15:05 +0100, Sven Peter wrote: > > This is a fairly brief series to add support for the DARTs present in the > M1 Pro/Max. They have two differences that make them incompatible with > those in the M1: > > - the physical addresses are shifted left by 4 bits and and have 2 more > bits inside the PTE entries > - the subpage protection feature is now mandatory. For Linux we can > just configure it to always allow access to the entire page. > > Note that this needs a fix to the core pagetable code. Hector already > sent a first version separately to the mailing list since the problem > is (at least in theory) also present on other SoCs using the LPAE format > with a large physical address space [1]. > > Sven > > [1] > https://lore.kernel.org/linux-iommu/a2b45243-7e0a-a2ac-4e14-5256a3e7a...@arm.com/T/#t > > Sven Peter (4): > dt-bindings: iommu: dart: add t6000 compatible > iommu/io-pgtable: Add DART subpage protection support > iommu/io-pgtable: Add DART PTE support for t6000 > iommu: dart: Support t6000 variant > > .../devicetree/bindings/iommu/apple,dart.yaml | 4 +- > drivers/iommu/apple-dart.c| 19 - > drivers/iommu/io-pgtable-arm.c| 40 ++- > include/linux/io-pgtable.h| 2 + > 4 files changed, 61 insertions(+), 4 deletions(-) Whole series tested on M1 Max. Feel free to add Tested-by: Janne Grunau best Janne ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
