* [PATCH v7 1/8] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit
2025-04-18 7:30 ` [PATCH v7 0/8] " huaqian.li
@ 2025-04-18 7:30 ` huaqian.li
2025-04-18 7:30 ` [PATCH v7 2/8] dt-bindings: PCI: ti,am65: Extend for use with PVU huaqian.li
` (8 subsequent siblings)
9 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-04-18 7:30 UTC (permalink / raw)
To: helgaas, m.szyprowski, robin.murphy
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr, iommu, Krzysztof Kozlowski
From: Jan Kiszka <jan.kiszka@siemens.com>
The PVU allows to define a limited set of mappings for incoming DMA
requests to the system memory. It is not a real IOMMU, thus hooked up
under the TI SoC bindings.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
.../bindings/soc/ti/ti,am654-pvu.yaml | 51 +++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml b/Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
new file mode 100644
index 000000000000..e4a5fc47d674
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) Siemens AG, 2024
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/ti/ti,am654-pvu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI AM654 Peripheral Virtualization Unit
+
+maintainers:
+ - Jan Kiszka <jan.kiszka@siemens.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,am654-pvu
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: cfg
+ - const: tlbif
+
+ interrupts:
+ items:
+ - description: fault interrupt
+
+ interrupt-names:
+ items:
+ - const: pvu
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+ iommu@30f80000 {
+ compatible = "ti,am654-pvu";
+ reg = <0x30f80000 0x1000>,
+ <0x36000000 0x100000>;
+ reg-names = "cfg", "tlbif";
+ interrupts-extended = <&intr_main_navss 390>;
+ interrupt-names = "pvu";
+ };
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v7 2/8] dt-bindings: PCI: ti,am65: Extend for use with PVU
2025-04-18 7:30 ` [PATCH v7 0/8] " huaqian.li
2025-04-18 7:30 ` [PATCH v7 1/8] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit huaqian.li
@ 2025-04-18 7:30 ` huaqian.li
2025-04-18 8:24 ` Rob Herring (Arm)
2025-04-18 7:30 ` [PATCH v7 3/8] soc: ti: Add IOMMU-like PVU driver huaqian.li
` (7 subsequent siblings)
9 siblings, 1 reply; 58+ messages in thread
From: huaqian.li @ 2025-04-18 7:30 UTC (permalink / raw)
To: helgaas, m.szyprowski, robin.murphy
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr, iommu, Krzysztof Kozlowski
From: Jan Kiszka <jan.kiszka@siemens.com>
The PVU on the AM65 SoC is capable of restricting DMA from PCIe devices
to specific regions of host memory. Add the optional property
"memory-regions" to point to such regions of memory when PVU is used.
Since the PVU deals with system physical addresses, utilizing the PVU
with PCIe devices also requires setting up the VMAP registers to map the
Requester ID of the PCIe device to the CBA Virtual ID, which in turn is
mapped to the system physical address. Hence, describe the VMAP
registers which are optional unless the PVU shall be used for PCIe.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
.../bindings/pci/ti,am65-pci-host.yaml | 34 +++++++++++++++++--
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
index 0a9d10532cc8..7916325e0b39 100644
--- a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
@@ -20,14 +20,18 @@ properties:
- ti,keystone-pcie
reg:
- maxItems: 4
+ minItems: 4
+ maxItems: 6
reg-names:
+ minItems: 4
items:
- const: app
- const: dbics
- const: config
- const: atu
+ - const: vmap_lp
+ - const: vmap_hp
interrupts:
maxItems: 1
@@ -69,6 +73,15 @@ properties:
items:
pattern: '^pcie-phy[0-1]$'
+ memory-region:
+ maxItems: 1
+ description: |
+ phandle to a restricted DMA pool to be used for all devices behind
+ this controller. The regions should be defined according to
+ reserved-memory/shared-dma-pool.yaml.
+ Note that enforcement via the PVU will only be available to
+ ti,am654-pcie-rc devices.
+
required:
- compatible
- reg
@@ -89,6 +102,19 @@ then:
- power-domains
- msi-map
- num-viewport
+ - memory-region
+ properties:
+ reg:
+ minItems: 6
+ reg-names:
+ minItems: 6
+else:
+ properties:
+ reg:
+ maxItems: 4
+
+ reg-names:
+ maxItems: 4
unevaluatedProperties: false
@@ -104,8 +130,10 @@ examples:
reg = <0x5500000 0x1000>,
<0x5501000 0x1000>,
<0x10000000 0x2000>,
- <0x5506000 0x1000>;
- reg-names = "app", "dbics", "config", "atu";
+ <0x5506000 0x1000>,
+ <0x2900000 0x1000>,
+ <0x2908000 0x1000>;
+ reg-names = "app", "dbics", "config", "atu", "vmap_lp", "vmap_hp";
power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <3>;
#size-cells = <2>;
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v7 2/8] dt-bindings: PCI: ti,am65: Extend for use with PVU
2025-04-18 7:30 ` [PATCH v7 2/8] dt-bindings: PCI: ti,am65: Extend for use with PVU huaqian.li
@ 2025-04-18 8:24 ` Rob Herring (Arm)
0 siblings, 0 replies; 58+ messages in thread
From: Rob Herring (Arm) @ 2025-04-18 8:24 UTC (permalink / raw)
To: huaqian.li
Cc: nm, baocheng.su, linux-pci, diogo.ivo, krzk+dt,
Krzysztof Kozlowski, kw, robin.murphy, jan.kiszka, kristo,
s-vadapalli, linux-arm-kernel, lpieralisi, vigneshr, iommu,
linux-kernel, bhelgaas, helgaas, m.szyprowski, devicetree,
conor+dt, ssantosh
On Fri, 18 Apr 2025 15:30:20 +0800, huaqian.li@siemens.com wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> The PVU on the AM65 SoC is capable of restricting DMA from PCIe devices
> to specific regions of host memory. Add the optional property
> "memory-regions" to point to such regions of memory when PVU is used.
>
> Since the PVU deals with system physical addresses, utilizing the PVU
> with PCIe devices also requires setting up the VMAP registers to map the
> Requester ID of the PCIe device to the CBA Virtual ID, which in turn is
> mapped to the system physical address. Hence, describe the VMAP
> registers which are optional unless the PVU shall be used for PCIe.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
> ---
> .../bindings/pci/ti,am65-pci-host.yaml | 34 +++++++++++++++++--
> 1 file changed, 31 insertions(+), 3 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pci/ti,am65-pci-host.example.dtb: pcie@5500000 (ti,am654-pcie-rc): 'memory-region' is a required property
from schema $id: http://devicetree.org/schemas/pci/ti,am65-pci-host.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250418073026.2418728-3-huaqian.li@siemens.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v7 3/8] soc: ti: Add IOMMU-like PVU driver
2025-04-18 7:30 ` [PATCH v7 0/8] " huaqian.li
2025-04-18 7:30 ` [PATCH v7 1/8] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit huaqian.li
2025-04-18 7:30 ` [PATCH v7 2/8] dt-bindings: PCI: ti,am65: Extend for use with PVU huaqian.li
@ 2025-04-18 7:30 ` huaqian.li
2025-04-18 7:30 ` [PATCH v7 4/8] PCI: keystone: Add support for PVU-based DMA isolation on AM654 huaqian.li
` (6 subsequent siblings)
9 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-04-18 7:30 UTC (permalink / raw)
To: helgaas, m.szyprowski, robin.murphy
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr, iommu
From: Jan Kiszka <jan.kiszka@siemens.com>
The TI Peripheral Virtualization Unit (PVU) permits to define a limited
set of mappings for DMA requests on the system memory. Unlike with an
IOMMU, there is no fallback to a memory-backed page table, only a fixed
set of register-backed TLBs. Emulating an IOMMU behavior appears to be
the more fragile the more fragmentation of pending requests occur.
Therefore, this driver does not expose the PVU as an IOMMU. It rather
introduces a simple, static interface to devices that are under
restricted-dma-pool constraints. They can register their pools with the
PVUs, enabling only those pools to work for DMA. As also MSI is issued
as DMA, the PVU already register the related translator region of the
AM654 as valid DMA target.
This driver is the essential building block for limiting DMA from
untrusted devices to clearly defined memory regions in the absence of a
real IOMMU (SMMU).
Co-developed-by: Diogo Ivo <diogo.ivo@siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
drivers/soc/ti/Kconfig | 4 +
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti-pvu.c | 500 ++++++++++++++++++++++++++++++++++++++++
include/linux/ti-pvu.h | 32 +++
4 files changed, 537 insertions(+)
create mode 100644 drivers/soc/ti/ti-pvu.c
create mode 100644 include/linux/ti-pvu.h
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 1a93001c9e36..af7173ad84de 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -82,6 +82,10 @@ config TI_PRUSS
processors on various TI SoCs. It's safe to say N here if you're
not interested in the PRU or if you are unsure.
+config TI_PVU
+ bool "TI Peripheral Virtualization Unit driver"
+ depends on ARCH_K3 && DMA_RESTRICTED_POOL
+
endif # SOC_TI
config TI_SCI_INTA_MSI_DOMAIN
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index cb800a745e66..ecff3fd8c433 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_TI_K3_RINGACC) += k3-ringacc.o
obj-$(CONFIG_TI_K3_SOCINFO) += k3-socinfo.o
obj-$(CONFIG_TI_PRUSS) += pruss.o
obj-$(CONFIG_POWER_AVS_OMAP) += smartreflex.o
+obj-$(CONFIG_TI_PVU) += ti-pvu.o
diff --git a/drivers/soc/ti/ti-pvu.c b/drivers/soc/ti/ti-pvu.c
new file mode 100644
index 000000000000..38996c74cce7
--- /dev/null
+++ b/drivers/soc/ti/ti-pvu.c
@@ -0,0 +1,500 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI Peripheral Virtualization Unit driver for static DMA isolation
+ *
+ * Copyright (c) 2024, Siemens AG
+ */
+
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/ti-pvu.h>
+
+#define PVU_CONFIG 0x4
+#define PVU_ENABLE 0x10
+#define PVU_VIRTID_MAP1 0x14
+#define PVU_VIRTID_MAP2 0x18
+#define PVU_EXCEPTION_LOGGING_CONTROL 0x120
+#define PVU_EXCEPTION_LOGGING_HEADER0 0x124
+#define PVU_EXCEPTION_LOGGING_HEADER1 0x128
+#define PVU_EXCEPTION_LOGGING_DATA0 0x12c
+#define PVU_EXCEPTION_LOGGING_DATA1 0x130
+#define PVU_EXCEPTION_LOGGING_DATA2 0x134
+#define PVU_EXCEPTION_LOGGING_DATA2_SECURE BIT(0)
+#define PVU_EXCEPTION_LOGGING_DATA2_PRIV BIT(1)
+#define PVU_EXCEPTION_LOGGING_DATA2_CACHEABLE BIT(2)
+#define PVU_EXCEPTION_LOGGING_DATA2_DEBUG BIT(3)
+#define PVU_EXCEPTION_LOGGING_DATA2_READ BIT(4)
+#define PVU_EXCEPTION_LOGGING_DATA2_WRITE BIT(5)
+#define PVU_EXCEPTION_LOGGING_DATA3 0x138
+#define PVU_EXCEPTION_ENABLE_SET 0x148
+#define PVU_EOI_REG 0x150
+
+#define PVU_CHAIN 0x0
+#define PVU_CHAIN_EN BIT(31)
+#define PVU_CHAIN_LOG_DIS BIT(30)
+#define PVU_CHAIN_FAULT BIT(29)
+#define PVU_CHAIN_MASK 0xfff
+#define PVU_ENTRY0 0x20
+#define PVU_ENTRY1 0x24
+#define PVU_ENTRY1_RESERVED_MASK 0xffff0000
+#define PVU_ENTRY1_VBASE_H_MASK 0xffff
+#define PVU_ENTRY2 0x28
+#define PVU_ENTRY2_RESERVED_MASK 0x1fd00080
+#define PVU_ENTRY2_INVALID (0U << 30)
+#define PVU_ENTRY2_VALID (2U << 30)
+#define PVU_ENTRY2_MODE_MASK 0xc0000000
+#define PVU_ENTRY2_PSIZE_SHIFT 16
+#define PVU_ENTRY2_PSIZE_MASK 0xf
+#define PVU_ENTRY2_PERM_SX BIT(15)
+#define PVU_ENTRY2_PERM_SW BIT(14)
+#define PVU_ENTRY2_PERM_SR BIT(13)
+#define PVU_ENTRY2_PERM_UX BIT(12)
+#define PVU_ENTRY2_PERM_UW BIT(11)
+#define PVU_ENTRY2_PERM_UR BIT(10)
+#define PVU_ENTRY2_MEM_WRITETHROUGH (2 << 8)
+#define PVU_ENTRY2_OUTER_SHARABLE BIT(4)
+#define PVU_ENTRY2_IS_NOALLOC (0 << 2)
+#define PVU_ENTRY2_OS_NOALLOC (0 << 0)
+#define PVU_ENTRY4 0x30
+#define PVU_ENTRY5 0x34
+#define PVU_ENTRY5_RESERVED_MASK 0xffff0000
+#define PVU_ENTRY5_PBASE_H_MASK 0xffff
+#define PVU_ENTRY6 0x38
+#define PVU_ENTRY6_RESERVED_MASK 0xffffffe0
+
+#define NUM_VIRTIDS 1
+
+static const struct regmap_config pvu_cfg_regmap_cfg = {
+ .name = "pvu-cfg",
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = PVU_EOI_REG,
+};
+
+enum pvu_cfg_regfields {
+ PVU_TLBS,
+ PVU_TLB_ENTRIES,
+ PVU_ENABLED,
+ PVU_DMA_CNT,
+ PVU_DMA_CL0,
+ PVU_DMA_CL1,
+ PVU_DMA_CL2,
+ PVU_DMA_CL3,
+ PVU_MAX_VIRTID,
+ PVU_EXC_SRC_ID,
+ PVU_EXC_CODE,
+ PVU_EXC_ADDR_L,
+ PVU_EXC_ADDR_H,
+ PVU_EXC_PRIV_ID,
+ PVU_EXC_PROPS,
+ PVU_EXC_ROUTE_ID,
+ PVU_EXC_BYTE_CNT,
+ PVU_EXC_ENABLE,
+ PVU_EOI,
+ PVU_MAX_CFG_FIELDS,
+};
+
+static const struct reg_field pvu_cfg_reg_fields[] = {
+ [PVU_TLBS] = REG_FIELD(PVU_CONFIG, 0, 15),
+ [PVU_TLB_ENTRIES] = REG_FIELD(PVU_CONFIG, 16, 23),
+ [PVU_ENABLED] = REG_FIELD(PVU_ENABLE, 0, 0),
+ [PVU_DMA_CNT] = REG_FIELD(PVU_VIRTID_MAP1, 0, 11),
+ [PVU_DMA_CL0] = REG_FIELD(PVU_VIRTID_MAP1, 16, 17),
+ [PVU_DMA_CL1] = REG_FIELD(PVU_VIRTID_MAP1, 18, 19),
+ [PVU_DMA_CL2] = REG_FIELD(PVU_VIRTID_MAP1, 20, 21),
+ [PVU_DMA_CL3] = REG_FIELD(PVU_VIRTID_MAP1, 22, 23),
+ [PVU_MAX_VIRTID] = REG_FIELD(PVU_VIRTID_MAP2, 0, 11),
+ [PVU_EXC_SRC_ID] = REG_FIELD(PVU_EXCEPTION_LOGGING_HEADER0, 8, 23),
+ [PVU_EXC_CODE] = REG_FIELD(PVU_EXCEPTION_LOGGING_HEADER1, 16, 23),
+ [PVU_EXC_ADDR_L] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA0, 0, 31),
+ [PVU_EXC_ADDR_H] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA1, 0, 15),
+ [PVU_EXC_PRIV_ID] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA2, 0, 7),
+ [PVU_EXC_PROPS] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA2, 8, 13),
+ [PVU_EXC_ROUTE_ID] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA2, 16, 27),
+ [PVU_EXC_BYTE_CNT] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA3, 0, 9),
+ [PVU_EXC_ENABLE] = REG_FIELD(PVU_EXCEPTION_ENABLE_SET, 0, 0),
+ [PVU_EOI] = REG_FIELD(PVU_EOI_REG, 0, 15),
+};
+
+struct ti_pvu {
+ struct list_head entry;
+ struct platform_device *pdev;
+ struct regmap *cfg;
+ struct regmap_field *cfg_fields[PVU_MAX_CFG_FIELDS];
+ void __iomem *tlbif_base;
+ unsigned int num_tlbs;
+ unsigned int num_entries;
+};
+
+static const char *pvu_excp_code_string[] = {
+ "PVU miss",
+ "maximum VirtID violation",
+ "<reserved>",
+ "read permission violation",
+ "write permission violation",
+ "execute permission violation",
+ "prefetch permission violation",
+ "<unknown>",
+};
+
+static const u64 pvu_page_size[] = {
+ 4 * 1024ULL,
+ 16 * 1024ULL,
+ 64 * 1024ULL,
+ 2 * 1024 * 1024ULL,
+ 32 * 1024 * 1024ULL,
+ 512 * 1024 * 1024ULL,
+ 1 * 1024 * 1024 * 1024ULL,
+ 16 * 1024 * 1024 * 1024ULL
+};
+
+static DEFINE_MUTEX(ti_pvu_lock);
+static LIST_HEAD(ti_pvu_list);
+
+static unsigned int pvu_field_read(struct ti_pvu *pvu, enum pvu_cfg_regfields f)
+{
+ int ret;
+ unsigned int val;
+
+ ret = regmap_field_read(pvu->cfg_fields[f], &val);
+ if (ret)
+ dev_err(&pvu->pdev->dev, "failed to read field\n");
+
+ return val;
+}
+
+static void pvu_field_write(struct ti_pvu *pvu, enum pvu_cfg_regfields f,
+ unsigned int val)
+{
+ int ret;
+
+ ret = regmap_field_write(pvu->cfg_fields[f], val);
+ if (ret)
+ dev_err(&pvu->pdev->dev, "failed to write field\n");
+}
+
+static irqreturn_t pvu_fault_isr(int irq, void *dev_id)
+{
+ u32 code, bytes, route_id, priv_id, props;
+ struct ti_pvu *pvu = dev_id;
+ const char *code_str;
+ u64 address;
+
+ code = pvu_field_read(pvu, PVU_EXC_CODE);
+ code_str = pvu_excp_code_string[
+ min(code, (u32)ARRAY_SIZE(pvu_excp_code_string) - 1)];
+
+ dev_err(&pvu->pdev->dev, "fault detected, code %d (%s)\n",
+ code, code_str);
+
+ address = pvu_field_read(pvu, PVU_EXC_ADDR_L);
+ address |= (u64)pvu_field_read(pvu, PVU_EXC_ADDR_H) << 32;
+
+ bytes = pvu_field_read(pvu, PVU_EXC_BYTE_CNT);
+
+ route_id = pvu_field_read(pvu, PVU_EXC_ROUTE_ID);
+ priv_id = pvu_field_read(pvu, PVU_EXC_PRIV_ID);
+ props = pvu_field_read(pvu, PVU_EXC_PROPS);
+
+ dev_err(&pvu->pdev->dev,
+ " address 0x%016llx size %d route-ID %d priv-ID %d flags %c%c%c%c%c%c\n",
+ address, bytes, route_id, priv_id,
+ (props & PVU_EXCEPTION_LOGGING_DATA2_WRITE) ? 'W' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_READ) ? 'R' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_DEBUG) ? 'D' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_CACHEABLE) ? 'C' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_PRIV) ? 'P' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_SECURE) ? 'S' : '-');
+
+ pvu_field_write(pvu, PVU_EOI, 0);
+
+ return IRQ_HANDLED;
+}
+
+static void __iomem *pvu_get_entry_base(struct ti_pvu *pvu, unsigned int entry)
+{
+ return pvu->tlbif_base + (entry / pvu->num_entries) * 0x1000 +
+ (entry % pvu->num_entries) * 0x20;
+}
+
+static int pvu_get_free_entry(struct ti_pvu *pvu)
+{
+ unsigned int n;
+ u32 val;
+
+ /* We use up to 2 TLBs via chainging */
+ for (n = 0; n < pvu->num_entries * 2; n++) {
+ val = readl(pvu_get_entry_base(pvu, n) + PVU_ENTRY2);
+ if ((val & PVU_ENTRY2_MODE_MASK) == PVU_ENTRY2_INVALID)
+ return n;
+ }
+ return -ENOSPC;
+}
+
+static void pvu_write_entry(struct ti_pvu *pvu, unsigned int entry,
+ u64 addr, u32 psize)
+{
+ void __iomem *entry_base = pvu_get_entry_base(pvu, entry);
+ u32 val;
+
+ writel((u32)addr, entry_base + PVU_ENTRY0);
+
+ val = readl(entry_base + PVU_ENTRY1);
+ val &= PVU_ENTRY1_RESERVED_MASK;
+ val |= (addr >> 32) & PVU_ENTRY1_VBASE_H_MASK;
+ writel(val, entry_base + PVU_ENTRY1);
+
+ writel((u32)addr, entry_base + PVU_ENTRY4);
+
+ val = readl(entry_base + PVU_ENTRY5);
+ val &= PVU_ENTRY5_RESERVED_MASK;
+ val |= (addr >> 32) & PVU_ENTRY5_PBASE_H_MASK;
+ writel(val, entry_base + PVU_ENTRY5);
+
+ val = readl(entry_base + PVU_ENTRY6);
+ val &= PVU_ENTRY6_RESERVED_MASK;
+ writel(val, entry_base + PVU_ENTRY6);
+
+ val = readl(entry_base + PVU_ENTRY2);
+ val &= PVU_ENTRY2_RESERVED_MASK;
+ val |= psize << PVU_ENTRY2_PSIZE_SHIFT;
+ val |= PVU_ENTRY2_VALID |
+ PVU_ENTRY2_PERM_UR | PVU_ENTRY2_PERM_SR |
+ PVU_ENTRY2_PERM_UW | PVU_ENTRY2_PERM_SW |
+ PVU_ENTRY2_PERM_UX | PVU_ENTRY2_PERM_SX |
+ PVU_ENTRY2_MEM_WRITETHROUGH | PVU_ENTRY2_OUTER_SHARABLE |
+ PVU_ENTRY2_IS_NOALLOC | PVU_ENTRY2_OS_NOALLOC;
+ writel(val, entry_base + PVU_ENTRY2);
+}
+
+static int pvu_create_region(struct ti_pvu *pvu, u64 addr, u64 size)
+{
+ u64 page_size;
+ int psize;
+ int entry;
+
+ while (size > 0) {
+ entry = pvu_get_free_entry(pvu);
+ if (entry < 0) {
+ dev_err(&pvu->pdev->dev, "ran out of TLB entries\n");
+ return -ENOSPC;
+ }
+
+ for (psize = ARRAY_SIZE(pvu_page_size) - 1; psize >= 0; psize--) {
+ page_size = pvu_page_size[psize];
+ if (size >= page_size && (addr & (page_size - 1)) == 0)
+ break;
+ }
+ if (psize < 0) {
+ dev_err(&pvu->pdev->dev, "unaligned region provided\n");
+ return -EINVAL;
+ }
+
+ pvu_write_entry(pvu, entry, addr, psize);
+ dev_info(&pvu->pdev->dev,
+ "created TLB entry %d.%d: 0x%08llx, psize %d (0x%08llx)\n",
+ entry / pvu->num_entries, entry % pvu->num_entries,
+ addr, psize, page_size);
+
+ size -= page_size;
+ addr += page_size;
+ }
+
+ return 0;
+}
+
+static void pvu_remove_region(struct ti_pvu *pvu, u64 addr, u64 size)
+{
+ void __iomem *entry_base;
+ unsigned int n, psize;
+ u64 entry_addr;
+ u32 entry2;
+
+ for (n = 0; n < pvu->num_entries * 2; n++) {
+ entry_base = pvu_get_entry_base(pvu, n);
+ entry2 = readl(entry_base + PVU_ENTRY2);
+ if ((entry2 & PVU_ENTRY2_MODE_MASK) != PVU_ENTRY2_VALID)
+ continue;
+
+ entry_addr = readl(entry_base + PVU_ENTRY0);
+ entry_addr |= (u64)(readl(entry_base + PVU_ENTRY1) &
+ PVU_ENTRY1_VBASE_H_MASK) << 32;
+
+ psize = (entry2 >> PVU_ENTRY2_PSIZE_SHIFT) &
+ PVU_ENTRY2_PSIZE_MASK;
+ if (psize >= ARRAY_SIZE(pvu_page_size))
+ continue;
+
+ if (entry_addr >= addr &&
+ (entry_addr + pvu_page_size[psize]) <= (addr + size)) {
+ entry2 &= ~PVU_ENTRY2_MODE_MASK;
+ entry2 |= PVU_ENTRY2_INVALID;
+ writel(entry2, entry_base + PVU_ENTRY2);
+
+ dev_info(&pvu->pdev->dev, "removed TLB entry %d.%d\n",
+ n / pvu->num_entries, n % pvu->num_entries);
+ }
+ }
+}
+
+int ti_pvu_create_region(unsigned int virt_id, const struct resource *region)
+{
+ struct ti_pvu *pvu;
+ int err = 0;
+
+ if (virt_id >= NUM_VIRTIDS)
+ return -EINVAL;
+
+ mutex_lock(&ti_pvu_lock);
+
+ list_for_each_entry(pvu, &ti_pvu_list, entry) {
+ err = pvu_create_region(pvu, region->start,
+ region->end + 1 - region->start);
+ if (err)
+ break;
+ }
+
+ mutex_unlock(&ti_pvu_lock);
+
+ return err;
+}
+
+int ti_pvu_remove_region(unsigned int virt_id, const struct resource *region)
+{
+ struct ti_pvu *pvu;
+
+ if (virt_id >= NUM_VIRTIDS)
+ return -EINVAL;
+
+ mutex_lock(&ti_pvu_lock);
+
+ list_for_each_entry(pvu, &ti_pvu_list, entry) {
+ pvu_remove_region(pvu, region->start,
+ region->end + 1 - region->start);
+ }
+
+ mutex_unlock(&ti_pvu_lock);
+
+ return 0;
+}
+
+static int ti_pvu_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *its_node;
+ void __iomem *base;
+ struct ti_pvu *pvu;
+ u32 val;
+ int ret;
+
+ pvu = devm_kzalloc(dev, sizeof(*pvu), GFP_KERNEL);
+ if (!pvu)
+ return -ENOMEM;
+
+ pvu->pdev = pdev;
+
+ base = devm_platform_ioremap_resource_byname(pdev, "cfg");
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ pvu->cfg = devm_regmap_init_mmio(dev, base, &pvu_cfg_regmap_cfg);
+ if (IS_ERR(pvu->cfg))
+ return dev_err_probe(dev, PTR_ERR(pvu->cfg), "failed to init cfg regmap");
+
+ ret = devm_regmap_field_bulk_alloc(dev, pvu->cfg, pvu->cfg_fields,
+ pvu_cfg_reg_fields, PVU_MAX_CFG_FIELDS);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to alloc cfg regmap fields");
+
+ pvu->num_tlbs = pvu_field_read(pvu, PVU_TLBS);
+ pvu->num_entries = pvu_field_read(pvu, PVU_TLB_ENTRIES);
+ dev_info(dev, "TLBs: %d, entries per TLB: %d\n", pvu->num_tlbs,
+ pvu->num_entries);
+
+ pvu->tlbif_base = devm_platform_ioremap_resource_byname(pdev, "tlbif");
+ if (IS_ERR(pvu->tlbif_base))
+ return PTR_ERR(pvu->tlbif_base);
+
+ its_node = of_find_compatible_node(0, 0, "arm,gic-v3-its");
+ if (its_node) {
+ u32 pre_its_window[2];
+
+ ret = of_property_read_u32_array(its_node,
+ "socionext,synquacer-pre-its",
+ pre_its_window,
+ ARRAY_SIZE(pre_its_window));
+ if (ret) {
+ dev_err(dev, "failed to read pre-its property\n");
+ return ret;
+ }
+
+ ret = pvu_create_region(pvu, pre_its_window[0],
+ pre_its_window[1]);
+ if (ret)
+ return ret;
+ }
+
+ /* Enable the first two TLBs, chaining from 0 to 1 */
+ val = readl(pvu->tlbif_base + PVU_CHAIN);
+ val |= PVU_CHAIN_EN | 1;
+ writel(val, pvu->tlbif_base + PVU_CHAIN);
+
+ val = readl(pvu->tlbif_base + PVU_CHAIN + 0x1000);
+ val |= PVU_CHAIN_EN;
+ writel(val, pvu->tlbif_base + PVU_CHAIN + 0x1000);
+
+ pvu_field_write(pvu, PVU_DMA_CNT, 0);
+ pvu_field_write(pvu, PVU_DMA_CL0, 0);
+ pvu_field_write(pvu, PVU_DMA_CL1, 0);
+ pvu_field_write(pvu, PVU_DMA_CL2, 0);
+ pvu_field_write(pvu, PVU_DMA_CL3, 0);
+ pvu_field_write(pvu, PVU_MAX_VIRTID, NUM_VIRTIDS);
+
+ ret = platform_get_irq(pdev, 0);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to get irq\n");
+
+ ret = devm_request_irq(dev, ret, pvu_fault_isr, 0, dev_name(dev), pvu);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to request irq\n");
+
+ pvu_field_write(pvu, PVU_EXC_ENABLE, 1);
+ pvu_field_write(pvu, PVU_ENABLED, 1);
+
+ dev_set_drvdata(dev, pvu);
+
+ mutex_lock(&ti_pvu_lock);
+ list_add(&pvu->entry, &ti_pvu_list);
+ mutex_unlock(&ti_pvu_lock);
+
+ return 0;
+}
+
+static void ti_pvu_remove(struct platform_device *pdev)
+{
+ struct ti_pvu *pvu = dev_get_drvdata(&pdev->dev);
+
+ mutex_lock(&ti_pvu_lock);
+ list_del(&pvu->entry);
+ mutex_unlock(&ti_pvu_lock);
+}
+
+static const struct of_device_id ti_pvu_of_match[] = {
+ { .compatible = "ti,am654-pvu", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ti_pvu_of_match);
+
+static struct platform_driver ti_pvu_driver = {
+ .driver = {
+ .name = "ti-pvu",
+ .of_match_table = ti_pvu_of_match,
+ },
+ .probe = ti_pvu_probe,
+ .remove = ti_pvu_remove,
+};
+module_platform_driver(ti_pvu_driver);
diff --git a/include/linux/ti-pvu.h b/include/linux/ti-pvu.h
new file mode 100644
index 000000000000..7088da8dad9a
--- /dev/null
+++ b/include/linux/ti-pvu.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * TI Peripheral Virtualization Unit driver for static DMA isolation
+ *
+ * Copyright (c) 2024, Siemens AG
+ */
+
+#ifndef _LINUX_TI_PVU_H
+#define _LINUX_TI_PVU_H
+
+#include <linux/ioport.h>
+
+#if IS_ENABLED(CONFIG_TI_PVU)
+int ti_pvu_create_region(unsigned int virt_id,
+ const struct resource *region);
+int ti_pvu_remove_region(unsigned int virt_id,
+ const struct resource *region);
+#else
+static inline int ti_pvu_create_region(unsigned int virt_id,
+ const struct resource *region)
+{
+ return 0;
+}
+
+static inline int ti_pvu_remove_region(unsigned int virt_id,
+ const struct resource *region)
+{
+ return 0;
+}
+#endif
+
+#endif /* _LINUX_TI_PVU_H */
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v7 4/8] PCI: keystone: Add support for PVU-based DMA isolation on AM654
2025-04-18 7:30 ` [PATCH v7 0/8] " huaqian.li
` (2 preceding siblings ...)
2025-04-18 7:30 ` [PATCH v7 3/8] soc: ti: Add IOMMU-like PVU driver huaqian.li
@ 2025-04-18 7:30 ` huaqian.li
2025-04-18 7:30 ` [PATCH v7 5/8] arm64: dts: ti: k3-am65-main: Add PVU nodes huaqian.li
` (5 subsequent siblings)
9 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-04-18 7:30 UTC (permalink / raw)
To: helgaas, m.szyprowski, robin.murphy
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr, iommu
From: Jan Kiszka <jan.kiszka@siemens.com>
The AM654 lacks an IOMMU, thus does not support isolating DMA requests
from untrusted PCI devices to selected memory regions this way. Use
static PVU-based protection instead. The PVU, when enabled, will only
accept DMA requests that address previously configured regions.
Use the availability of a restricted-dma-pool memory region as trigger
and register it as valid DMA target with the PVU. In addition, enable
the mapping of requester IDs to VirtIDs in the PCI RC. Use only a single
VirtID so far, catching all devices. This may be extended later on.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
drivers/pci/controller/dwc/pci-keystone.c | 106 ++++++++++++++++++++++
1 file changed, 106 insertions(+)
diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
index 76a37368ae4f..30aaaf28d6a4 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -19,6 +19,7 @@
#include <linux/mfd/syscon.h>
#include <linux/msi.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_pci.h>
#include <linux/phy/phy.h>
@@ -26,6 +27,7 @@
#include <linux/regmap.h>
#include <linux/resource.h>
#include <linux/signal.h>
+#include <linux/ti-pvu.h>
#include "../../pci.h"
#include "pcie-designware.h"
@@ -111,6 +113,16 @@
#define PCI_DEVICE_ID_TI_AM654X 0xb00c
+#define KS_PCI_VIRTID 0
+
+#define PCIE_VMAP_xP_CTRL 0x0
+#define PCIE_VMAP_xP_REQID 0x4
+#define PCIE_VMAP_xP_VIRTID 0x8
+
+#define PCIE_VMAP_xP_CTRL_EN BIT(0)
+
+#define PCIE_VMAP_xP_VIRTID_VID_MASK 0xfff
+
struct ks_pcie_of_data {
enum dw_pcie_device_mode mode;
const struct dw_pcie_host_ops *host_ops;
@@ -1137,6 +1149,94 @@ static const struct of_device_id ks_pcie_of_match[] = {
{ },
};
+static int ks_init_vmap(struct platform_device *pdev, const char *vmap_name)
+{
+ struct resource *res;
+ void __iomem *base;
+ u32 val;
+
+ if (!IS_ENABLED(CONFIG_TI_PVU))
+ return 0;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, vmap_name);
+ base = devm_pci_remap_cfg_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ writel(0, base + PCIE_VMAP_xP_REQID);
+
+ val = readl(base + PCIE_VMAP_xP_VIRTID);
+ val &= ~PCIE_VMAP_xP_VIRTID_VID_MASK;
+ val |= KS_PCI_VIRTID;
+ writel(val, base + PCIE_VMAP_xP_VIRTID);
+
+ val = readl(base + PCIE_VMAP_xP_CTRL);
+ val |= PCIE_VMAP_xP_CTRL_EN;
+ writel(val, base + PCIE_VMAP_xP_CTRL);
+
+ return 0;
+}
+
+static int ks_init_restricted_dma(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct of_phandle_iterator it;
+ struct resource phys;
+ int err;
+
+ if (!IS_ENABLED(CONFIG_TI_PVU))
+ return 0;
+
+ /* Only process the first restricted DMA pool, more are not allowed */
+ of_for_each_phandle(&it, err, dev->of_node, "memory-region",
+ NULL, 0) {
+ if (of_device_is_compatible(it.node, "restricted-dma-pool"))
+ break;
+ }
+ if (err)
+ return err == -ENOENT ? 0 : err;
+
+ err = of_address_to_resource(it.node, 0, &phys);
+ if (err < 0) {
+ dev_err(dev, "failed to parse memory region %pOF: %d\n",
+ it.node, err);
+ return 0;
+ }
+
+ /* Map all incoming requests on low and high prio port to virtID 0 */
+ err = ks_init_vmap(pdev, "vmap_lp");
+ if (err)
+ return err;
+ err = ks_init_vmap(pdev, "vmap_hp");
+ if (err)
+ return err;
+
+ /*
+ * Enforce DMA pool usage with the help of the PVU.
+ * Any request outside will be dropped and raise an error at the PVU.
+ */
+ return ti_pvu_create_region(KS_PCI_VIRTID, &phys);
+}
+
+static void ks_release_restricted_dma(struct platform_device *pdev)
+{
+ struct of_phandle_iterator it;
+ struct resource phys;
+ int err;
+
+ if (!IS_ENABLED(CONFIG_TI_PVU))
+ return;
+
+ of_for_each_phandle(&it, err, pdev->dev.of_node, "memory-region",
+ NULL, 0) {
+ if (of_device_is_compatible(it.node, "restricted-dma-pool") &&
+ of_address_to_resource(it.node, 0, &phys) == 0) {
+ ti_pvu_remove_region(KS_PCI_VIRTID, &phys);
+ break;
+ }
+ }
+}
+
static int ks_pcie_probe(struct platform_device *pdev)
{
const struct dw_pcie_host_ops *host_ops;
@@ -1285,6 +1385,10 @@ static int ks_pcie_probe(struct platform_device *pdev)
if (ret < 0)
goto err_get_sync;
+ ret = ks_init_restricted_dma(pdev);
+ if (ret < 0)
+ goto err_get_sync;
+
switch (mode) {
case DW_PCIE_RC_TYPE:
if (!IS_ENABLED(CONFIG_PCI_KEYSTONE_HOST)) {
@@ -1366,6 +1470,8 @@ static void ks_pcie_remove(struct platform_device *pdev)
int num_lanes = ks_pcie->num_lanes;
struct device *dev = &pdev->dev;
+ ks_release_restricted_dma(pdev);
+
pm_runtime_put(dev);
pm_runtime_disable(dev);
ks_pcie_disable_phy(ks_pcie);
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v7 5/8] arm64: dts: ti: k3-am65-main: Add PVU nodes
2025-04-18 7:30 ` [PATCH v7 0/8] " huaqian.li
` (3 preceding siblings ...)
2025-04-18 7:30 ` [PATCH v7 4/8] PCI: keystone: Add support for PVU-based DMA isolation on AM654 huaqian.li
@ 2025-04-18 7:30 ` huaqian.li
2025-04-18 7:30 ` [PATCH v7 6/8] arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes huaqian.li
` (4 subsequent siblings)
9 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-04-18 7:30 UTC (permalink / raw)
To: helgaas, m.szyprowski, robin.murphy
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr, iommu
From: Jan Kiszka <jan.kiszka@siemens.com>
Add nodes for the two PVUs of the AM65. Keep them disabled, though,
because the board has to additionally define DMA pools and the devices
to be isolated.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 94a812a1355b..977c66a3a7c7 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -841,6 +841,26 @@ main_cpts_mux: refclk-mux {
assigned-clock-parents = <&k3_clks 118 5>;
};
};
+
+ ti_pvu0: iommu@30f80000 {
+ compatible = "ti,am654-pvu";
+ reg = <0 0x30f80000 0 0x1000>,
+ <0 0x36000000 0 0x100000>;
+ reg-names = "cfg", "tlbif";
+ interrupts-extended = <&intr_main_navss 390>;
+ interrupt-names = "pvu";
+ status = "disabled";
+ };
+
+ ti_pvu1: iommu@30f81000 {
+ compatible = "ti,am654-pvu";
+ reg = <0 0x30f81000 0 0x1000>,
+ <0 0x36100000 0 0x100000>;
+ reg-names = "cfg", "tlbif";
+ interrupts-extended = <&intr_main_navss 389>;
+ interrupt-names = "pvu";
+ status = "disabled";
+ };
};
main_gpio0: gpio@600000 {
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v7 6/8] arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes
2025-04-18 7:30 ` [PATCH v7 0/8] " huaqian.li
` (4 preceding siblings ...)
2025-04-18 7:30 ` [PATCH v7 5/8] arm64: dts: ti: k3-am65-main: Add PVU nodes huaqian.li
@ 2025-04-18 7:30 ` huaqian.li
2025-04-18 7:30 ` [PATCH v7 7/8] arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices behind PCI RC huaqian.li
` (3 subsequent siblings)
9 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-04-18 7:30 UTC (permalink / raw)
To: helgaas, m.szyprowski, robin.murphy
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr, iommu
From: Jan Kiszka <jan.kiszka@siemens.com>
Rewrap the long lines at this chance.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 977c66a3a7c7..e816c03569ff 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -895,8 +895,13 @@ main_gpio1: gpio@601000 {
pcie0_rc: pcie@5500000 {
compatible = "ti,am654-pcie-rc";
- reg = <0x0 0x5500000 0x0 0x1000>, <0x0 0x5501000 0x0 0x1000>, <0x0 0x10000000 0x0 0x2000>, <0x0 0x5506000 0x0 0x1000>;
- reg-names = "app", "dbics", "config", "atu";
+ reg = <0x0 0x5500000 0x0 0x1000>,
+ <0x0 0x5501000 0x0 0x1000>,
+ <0x0 0x10000000 0x0 0x2000>,
+ <0x0 0x5506000 0x0 0x1000>,
+ <0x0 0x2900000 0x0 0x1000>,
+ <0x0 0x2908000 0x0 0x1000>;
+ reg-names = "app", "dbics", "config", "atu", "vmap_lp", "vmap_hp";
power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <3>;
#size-cells = <2>;
@@ -916,8 +921,13 @@ pcie0_rc: pcie@5500000 {
pcie1_rc: pcie@5600000 {
compatible = "ti,am654-pcie-rc";
- reg = <0x0 0x5600000 0x0 0x1000>, <0x0 0x5601000 0x0 0x1000>, <0x0 0x18000000 0x0 0x2000>, <0x0 0x5606000 0x0 0x1000>;
- reg-names = "app", "dbics", "config", "atu";
+ reg = <0x0 0x5600000 0x0 0x1000>,
+ <0x0 0x5601000 0x0 0x1000>,
+ <0x0 0x18000000 0x0 0x2000>,
+ <0x0 0x5606000 0x0 0x1000>,
+ <0x0 0x2910000 0x0 0x1000>,
+ <0x0 0x2918000 0x0 0x1000>;
+ reg-names = "app", "dbics", "config", "atu", "vmap_lp", "vmap_hp";
power-domains = <&k3_pds 121 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <3>;
#size-cells = <2>;
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v7 7/8] arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices behind PCI RC
2025-04-18 7:30 ` [PATCH v7 0/8] " huaqian.li
` (5 preceding siblings ...)
2025-04-18 7:30 ` [PATCH v7 6/8] arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes huaqian.li
@ 2025-04-18 7:30 ` huaqian.li
2025-04-18 7:30 ` [PATCH v7 8/8] swiotlb: Make IO_TLB_SEGSIZE configurable huaqian.li
` (2 subsequent siblings)
9 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-04-18 7:30 UTC (permalink / raw)
To: helgaas, m.szyprowski, robin.murphy
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr, iommu
From: Jan Kiszka <jan.kiszka@siemens.com>
Reserve a 64M memory region and ensure that all PCI devices do their DMA
only inside that region. This is configured via a restricted-dma-pool
and enforced with the help of the first PVU.
Applying this isolation is not totally free in terms of overhead and
memory consumption. It makes only sense for variants that support
secure booting, and generally only when this is actually enable.
Therefore model it as overlay that can be activated on demand. The
firmware will take care of this via DT fixup during boot and will also
provide a way to adjust the pool size.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
arch/arm64/boot/dts/ti/Makefile | 5 +++
...am6548-iot2050-advanced-dma-isolation.dtso | 33 +++++++++++++++++++
2 files changed, 38 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 03d4cecfc001..12c2cee955f2 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -73,8 +73,10 @@ k3-am654-gp-evm-dtbs := k3-am654-base-board.dtb \
k3-am654-evm-dtbs := k3-am654-base-board.dtb k3-am654-icssg2.dtbo
k3-am654-idk-dtbs := k3-am654-evm.dtb k3-am654-idk.dtbo k3-am654-pcie-usb2.dtbo
k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-dtbs := k3-am6548-iot2050-advanced-m2.dtb \
+ k3-am6548-iot2050-advanced-dma-isolation.dtbo \
k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie.dtbo
k3-am6548-iot2050-advanced-m2-bkey-usb3-dtbs := k3-am6548-iot2050-advanced-m2.dtb \
+ k3-am6548-iot2050-advanced-dma-isolation.dtbo \
k3-am6548-iot2050-advanced-m2-bkey-usb3.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic-pg2.dtb
@@ -261,7 +263,10 @@ DTC_FLAGS_k3-am62p5-sk += -@
DTC_FLAGS_k3-am642-evm += -@
DTC_FLAGS_k3-am642-phyboard-electra-rdk += -@
DTC_FLAGS_k3-am642-tqma64xxl-mbax4xxl += -@
+DTC_FLAGS_k3-am6548-iot2050-advanced += -@
DTC_FLAGS_k3-am6548-iot2050-advanced-m2 += -@
+DTC_FLAGS_k3-am6548-iot2050-advanced-pg2 += -@
+DTC_FLAGS_k3-am6548-iot2050-advanced-sm += -@
DTC_FLAGS_k3-am68-sk-base-board += -@
DTC_FLAGS_k3-am69-sk += -@
DTC_FLAGS_k3-j7200-common-proc-board += -@
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
new file mode 100644
index 000000000000..dfd75d2dc245
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * IOT2050, overlay for isolating DMA requests via PVU
+ * Copyright (c) Siemens AG, 2024
+ *
+ * Authors:
+ * Jan Kiszka <jan.kiszka@siemens.com>
+ */
+
+/dts-v1/;
+/plugin/;
+
+&{/reserved-memory} {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pci_restricted_dma_region: restricted-dma@c0000000 {
+ compatible = "restricted-dma-pool";
+ reg = <0 0xc0000000 0 0x4000000>;
+ };
+};
+
+&pcie0_rc {
+ memory-region = <&pci_restricted_dma_region>;
+};
+
+&pcie1_rc {
+ memory-region = <&pci_restricted_dma_region>;
+};
+
+&ti_pvu0 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v7 8/8] swiotlb: Make IO_TLB_SEGSIZE configurable
2025-04-18 7:30 ` [PATCH v7 0/8] " huaqian.li
` (6 preceding siblings ...)
2025-04-18 7:30 ` [PATCH v7 7/8] arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices behind PCI RC huaqian.li
@ 2025-04-18 7:30 ` huaqian.li
2025-04-18 13:43 ` [PATCH v7 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation Nishanth Menon
2025-04-21 15:07 ` [PATCH v7 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation Rob Herring (Arm)
9 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-04-18 7:30 UTC (permalink / raw)
To: helgaas, m.szyprowski, robin.murphy
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr, iommu
From: Li Hua Qian <huaqian.li@siemens.com>
In some applications, the default value of 128 is not sufficient for
memory allocation and can cause runtime errors. This change makes
IO_TLB_SEGSIZE configurable, allowing it to be increased if needed.
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
include/linux/swiotlb.h | 2 +-
kernel/dma/Kconfig | 7 +++++++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 3dae0f592063..145c71f8329d 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -23,7 +23,7 @@ struct scatterlist;
* must be a power of 2. What is the appropriate value ?
* The complexity of {map,unmap}_single is linearly dependent on this value.
*/
-#define IO_TLB_SEGSIZE 128
+#define IO_TLB_SEGSIZE CONFIG_SWIOTLB_SEGSIZE
/*
* log of the size of each IO TLB slab. The number of slabs is command line
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 31cfdb6b4bc3..38bfa84b96b6 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -102,6 +102,13 @@ config SWIOTLB_DYNAMIC
If unsure, say N.
+config SWIOTLB_SEGSIZE
+ int "SWIOTLB segment size"
+ default 128
+ help
+ Set the maximum allowable number of contiguous slabs to map.
+ Must be a power of 2.
+
config DMA_BOUNCE_UNALIGNED_KMALLOC
bool
depends on SWIOTLB
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v7 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation
2025-04-18 7:30 ` [PATCH v7 0/8] " huaqian.li
` (7 preceding siblings ...)
2025-04-18 7:30 ` [PATCH v7 8/8] swiotlb: Make IO_TLB_SEGSIZE configurable huaqian.li
@ 2025-04-18 13:43 ` Nishanth Menon
2025-04-18 16:34 ` Bjorn Helgaas
2025-04-21 15:07 ` [PATCH v7 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation Rob Herring (Arm)
9 siblings, 1 reply; 58+ messages in thread
From: Nishanth Menon @ 2025-04-18 13:43 UTC (permalink / raw)
To: huaqian.li
Cc: helgaas, m.szyprowski, robin.murphy, baocheng.su, bhelgaas,
conor+dt, devicetree, diogo.ivo, jan.kiszka, kristo, krzk+dt, kw,
linux-arm-kernel, linux-kernel, linux-pci, lpieralisi, robh,
s-vadapalli, ssantosh, vigneshr, iommu
On 15:30-20250418, huaqian.li@siemens.com wrote:
>
> Jan Kiszka (7):
> dt-bindings: soc: ti: Add AM65 peripheral virtualization unit
> dt-bindings: PCI: ti,am65: Extend for use with PVU
> soc: ti: Add IOMMU-like PVU driver
> PCI: keystone: Add support for PVU-based DMA isolation on AM654
> arm64: dts: ti: k3-am65-main: Add PVU nodes
> arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes
> arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices
> behind PCI RC
>
> Li Hua Qian (1):
> swiotlb: Make IO_TLB_SEGSIZE configurable
I see at least 3 or 4 maintainers needing to co-ordinate, gets
complicated as I am not sure which maintainer needs to pick up what
patches in what dependency order. This looks like a mixed bag. Can
we split this patch into independent series for each maintainer with
clear indication of dependencies that is spread around a couple of
kernel windows (maybe dts comes in last?)
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v7 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation
2025-04-18 13:43 ` [PATCH v7 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation Nishanth Menon
@ 2025-04-18 16:34 ` Bjorn Helgaas
2025-04-18 19:04 ` Nishanth Menon
0 siblings, 1 reply; 58+ messages in thread
From: Bjorn Helgaas @ 2025-04-18 16:34 UTC (permalink / raw)
To: Nishanth Menon
Cc: huaqian.li, m.szyprowski, robin.murphy, baocheng.su, bhelgaas,
conor+dt, devicetree, diogo.ivo, jan.kiszka, kristo, krzk+dt, kw,
linux-arm-kernel, linux-kernel, linux-pci, lpieralisi, robh,
s-vadapalli, ssantosh, vigneshr, iommu
On Fri, Apr 18, 2025 at 08:43:24AM -0500, Nishanth Menon wrote:
> On 15:30-20250418, huaqian.li@siemens.com wrote:
> >
> > Jan Kiszka (7):
> > dt-bindings: soc: ti: Add AM65 peripheral virtualization unit
> > dt-bindings: PCI: ti,am65: Extend for use with PVU
> > soc: ti: Add IOMMU-like PVU driver
> > PCI: keystone: Add support for PVU-based DMA isolation on AM654
> > arm64: dts: ti: k3-am65-main: Add PVU nodes
> > arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes
> > arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices
> > behind PCI RC
> >
> > Li Hua Qian (1):
> > swiotlb: Make IO_TLB_SEGSIZE configurable
>
> I see at least 3 or 4 maintainers needing to co-ordinate, gets
> complicated as I am not sure which maintainer needs to pick up what
> patches in what dependency order. This looks like a mixed bag. Can
> we split this patch into independent series for each maintainer with
> clear indication of dependencies that is spread around a couple of
> kernel windows (maybe dts comes in last?)
The keystone patch ("[4/8] PCI: keystone: Add support for PVU-based
DMA isolation on AM654") depends on interfaces added by "[3/8] soc:
ti: Add IOMMU-like PVU driver", so I can't really take 4/8 by itself.
But I've acked 4/8, so it can be merged along with the rest of the
series. I assumed the easiest would be via the drivers/soc/ti/
maintainer, i.e., you, Nisanth :)
Let me know if I can do anything.
Bjorn
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v7 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation
2025-04-18 16:34 ` Bjorn Helgaas
@ 2025-04-18 19:04 ` Nishanth Menon
2025-04-22 5:16 ` Li, Hua Qian
0 siblings, 1 reply; 58+ messages in thread
From: Nishanth Menon @ 2025-04-18 19:04 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: huaqian.li, m.szyprowski, robin.murphy, baocheng.su, bhelgaas,
conor+dt, devicetree, diogo.ivo, jan.kiszka, kristo, krzk+dt, kw,
linux-arm-kernel, linux-kernel, linux-pci, lpieralisi, robh,
s-vadapalli, ssantosh, vigneshr, iommu
On 11:34-20250418, Bjorn Helgaas wrote:
> On Fri, Apr 18, 2025 at 08:43:24AM -0500, Nishanth Menon wrote:
> > On 15:30-20250418, huaqian.li@siemens.com wrote:
> > >
> > > Jan Kiszka (7):
> > > dt-bindings: soc: ti: Add AM65 peripheral virtualization unit
> > > dt-bindings: PCI: ti,am65: Extend for use with PVU
> > > soc: ti: Add IOMMU-like PVU driver
> > > PCI: keystone: Add support for PVU-based DMA isolation on AM654
> > > arm64: dts: ti: k3-am65-main: Add PVU nodes
> > > arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes
> > > arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices
> > > behind PCI RC
> > >
> > > Li Hua Qian (1):
> > > swiotlb: Make IO_TLB_SEGSIZE configurable
> >
> > I see at least 3 or 4 maintainers needing to co-ordinate, gets
> > complicated as I am not sure which maintainer needs to pick up what
> > patches in what dependency order. This looks like a mixed bag. Can
> > we split this patch into independent series for each maintainer with
> > clear indication of dependencies that is spread around a couple of
> > kernel windows (maybe dts comes in last?)
>
> The keystone patch ("[4/8] PCI: keystone: Add support for PVU-based
> DMA isolation on AM654") depends on interfaces added by "[3/8] soc:
> ti: Add IOMMU-like PVU driver", so I can't really take 4/8 by itself.
>
> But I've acked 4/8, so it can be merged along with the rest of the
> series. I assumed the easiest would be via the drivers/soc/ti/
> maintainer, i.e., you, Nisanth :)
>
> Let me know if I can do anything.
Thanks Bjorn, the swiotlb probably is one of the first to go in, I
guess.. I will let Li Hua/Jan suggest how they'd like to queue this.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v7 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation
2025-04-18 19:04 ` Nishanth Menon
@ 2025-04-22 5:16 ` Li, Hua Qian
2025-04-22 6:13 ` [PATCH v8 " huaqian.li
0 siblings, 1 reply; 58+ messages in thread
From: Li, Hua Qian @ 2025-04-22 5:16 UTC (permalink / raw)
To: nm@ti.com, helgaas@kernel.org
Cc: ssantosh@kernel.org, kw@linux.com, robh@kernel.org,
iommu@lists.linux.dev, kristo@kernel.org, robin.murphy@arm.com,
Kiszka, Jan, linux-kernel@vger.kernel.org, conor+dt@kernel.org,
s-vadapalli@ti.com, devicetree@vger.kernel.org,
lpieralisi@kernel.org, m.szyprowski@samsung.com,
krzk+dt@kernel.org, Su, Bao Cheng,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
bhelgaas@google.com, vigneshr@ti.com, Lopes Ivo, Diogo Miguel
On Fri, 2025-04-18 at 14:04 -0500, Nishanth Menon wrote:
> On 11:34-20250418, Bjorn Helgaas wrote:
> > On Fri, Apr 18, 2025 at 08:43:24AM -0500, Nishanth Menon wrote:
> > > On 15:30-20250418, huaqian.li@siemens.com wrote:
> > > >
> > > > Jan Kiszka (7):
> > > > dt-bindings: soc: ti: Add AM65 peripheral virtualization unit
> > > > dt-bindings: PCI: ti,am65: Extend for use with PVU
> > > > soc: ti: Add IOMMU-like PVU driver
> > > > PCI: keystone: Add support for PVU-based DMA isolation on
> > > > AM654
> > > > arm64: dts: ti: k3-am65-main: Add PVU nodes
> > > > arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root
> > > > complexes
> > > > arm64: dts: ti: iot2050: Add overlay for DMA isolation for
> > > > devices
> > > > behind PCI RC
> > > >
> > > > Li Hua Qian (1):
> > > > swiotlb: Make IO_TLB_SEGSIZE configurable
> > >
> > > I see at least 3 or 4 maintainers needing to co-ordinate, gets
> > > complicated as I am not sure which maintainer needs to pick up
> > > what
> > > patches in what dependency order. This looks like a mixed bag.
> > > Can
> > > we split this patch into independent series for each maintainer
> > > with
> > > clear indication of dependencies that is spread around a couple
> > > of
> > > kernel windows (maybe dts comes in last?)
> >
> > The keystone patch ("[4/8] PCI: keystone: Add support for PVU-based
> > DMA isolation on AM654") depends on interfaces added by "[3/8] soc:
> > ti: Add IOMMU-like PVU driver", so I can't really take 4/8 by
> > itself.
> >
> > But I've acked 4/8, so it can be merged along with the rest of the
> > series. I assumed the easiest would be via the drivers/soc/ti/
> > maintainer, i.e., you, Nisanth :)
> >
> > Let me know if I can do anything.
>
> Thanks Bjorn, the swiotlb probably is one of the first to go in, I
> guess.. I will let Li Hua/Jan suggest how they'd like to queue this.
>
Hi Nisanth,
Apologies for making this series more complicated, and thank you,
Bjorn, for the explanation. I will take patch 8 and submit it as a new
upstreaming series separately.
--
Hua Qian Li
Siemens AG
www.siemens.com
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH v8 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation
2025-04-22 5:16 ` Li, Hua Qian
@ 2025-04-22 6:13 ` huaqian.li
2025-04-22 6:14 ` [PATCH v8 1/7] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit huaqian.li
` (6 more replies)
0 siblings, 7 replies; 58+ messages in thread
From: huaqian.li @ 2025-04-22 6:13 UTC (permalink / raw)
To: helgaas
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr
From: Li Hua Qian <huaqian.li@siemens.com>
Changes in v8:
- remove patch 8 from this series to simplify the patchset
- fix dt_bindings_check warnings (patch 2), 'memory-region' must
not be a required property
Changes in v7:
- add schema expressing dependency as suggested on pci-host bindings
- resolve review comments on pci-keystone driver
- add a new patch to make IO_TLB_SEGSIZE configurable
- improve patches based on checkpath.pl
Changes in v6:
- make restricted DMA memory-region available to all pci-keystone
devices, moving property to unconditional section (patch 2)
Changes in v5:
- resolve review comments on pci-host bindings
- reduce DMA memory regions to 1 - swiotlb does not support more
- move activation into overlay (controlled via firmware)
- use ks_init_vmap helper instead of loop in
rework ks_init_restricted_dma
- add more comments to pci-keystone
- use 2 chained TLBs of PVU to support maximum of swiotlb (320 MB)
Changes in v4:
- reorder patch queue, moving all DTS changes to the back
- limit activation to IOT2050 Advanced variants
- move DMA pool to allow firmware-based expansion it up to 512M
Changes in v3:
- fix ti,am654-pvu.yaml according to review comments
- address review comments on ti,am65-pci-host.yaml
- differentiate between different compatibles in ti,am65-pci-host.yaml
- move pvu nodes to k3-am65-main.dtsi
- reorder patch series, pulling bindings and generic DT bits to the front
Changes in v2:
- fix dt_bindings_check issues (patch 1)
- address first review comments (patch 2)
- extend ti,am65-pci-host bindings for PVU (new patch 3)
Only few of the K3 SoCs have an IOMMU and, thus, can isolate the system
against DMA-based attacks of external PCI devices. The AM65 is without
an IOMMU, but it comes with something close to it: the Peripheral
Virtualization Unit (PVU).
The PVU was originally designed to establish static compartments via a
hypervisor, isolate those DMA-wise against each other and the host and
even allow remapping of guest-physical addresses. But it only provides
a static translation region, not page-granular mappings. Thus, it cannot
be handled transparently like an IOMMU.
Now, to use the PVU for the purpose of isolated PCI devices from the
Linux host, this series takes a different approach. It defines a
restricted-dma-pool for the PCI host, using swiotlb to map all DMA
buffers from a static memory carve-out. And to enforce that the devices
actually follow this, a special PVU soc driver is introduced. The driver
permits access to the GIC ITS and otherwise waits for other drivers that
detect devices with constrained DMA to register pools with the PVU.
For the AM65, the first (and possibly only) driver where this is
introduced is the pci-keystone host controller. Finally, this series
provides a DT overlay for the IOT2050 Advanced devices (all have
MiniPCIe or M.2 extension slots) to make use of this protection scheme.
Application of this overlay will be handled by firmware.
Due to the cross-cutting nature of these changes, multiple subsystems
are affected. However, I wanted to present the whole thing in one series
to allow everyone to review with the complete picture in hands. If
preferred, I can also split the series up, of course.
Jan
Jan Kiszka (7):
dt-bindings: soc: ti: Add AM65 peripheral virtualization unit
dt-bindings: PCI: ti,am65: Extend for use with PVU
soc: ti: Add IOMMU-like PVU driver
PCI: keystone: Add support for PVU-based DMA isolation on AM654
arm64: dts: ti: k3-am65-main: Add PVU nodes
arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes
arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices
behind PCI RC
.../bindings/pci/ti,am65-pci-host.yaml | 28 +-
.../bindings/soc/ti/ti,am654-pvu.yaml | 51 ++
arch/arm64/boot/dts/ti/Makefile | 5 +
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 38 +-
...am6548-iot2050-advanced-dma-isolation.dtso | 33 ++
drivers/pci/controller/dwc/pci-keystone.c | 106 ++++
drivers/soc/ti/Kconfig | 4 +
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti-pvu.c | 500 ++++++++++++++++++
include/linux/ti-pvu.h | 32 ++
10 files changed, 791 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
create mode 100644 drivers/soc/ti/ti-pvu.c
create mode 100644 include/linux/ti-pvu.h
--
2.34.1
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH v8 1/7] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit
2025-04-22 6:13 ` [PATCH v8 " huaqian.li
@ 2025-04-22 6:14 ` huaqian.li
2025-04-22 6:14 ` [PATCH v8 2/7] dt-bindings: PCI: ti,am65: Extend for use with PVU huaqian.li
` (5 subsequent siblings)
6 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-04-22 6:14 UTC (permalink / raw)
To: helgaas
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr, Krzysztof Kozlowski
From: Jan Kiszka <jan.kiszka@siemens.com>
The PVU allows to define a limited set of mappings for incoming DMA
requests to the system memory. It is not a real IOMMU, thus hooked up
under the TI SoC bindings.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
.../bindings/soc/ti/ti,am654-pvu.yaml | 51 +++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml b/Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
new file mode 100644
index 000000000000..e4a5fc47d674
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) Siemens AG, 2024
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/ti/ti,am654-pvu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI AM654 Peripheral Virtualization Unit
+
+maintainers:
+ - Jan Kiszka <jan.kiszka@siemens.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,am654-pvu
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: cfg
+ - const: tlbif
+
+ interrupts:
+ items:
+ - description: fault interrupt
+
+ interrupt-names:
+ items:
+ - const: pvu
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+ iommu@30f80000 {
+ compatible = "ti,am654-pvu";
+ reg = <0x30f80000 0x1000>,
+ <0x36000000 0x100000>;
+ reg-names = "cfg", "tlbif";
+ interrupts-extended = <&intr_main_navss 390>;
+ interrupt-names = "pvu";
+ };
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v8 2/7] dt-bindings: PCI: ti,am65: Extend for use with PVU
2025-04-22 6:13 ` [PATCH v8 " huaqian.li
2025-04-22 6:14 ` [PATCH v8 1/7] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit huaqian.li
@ 2025-04-22 6:14 ` huaqian.li
2025-04-22 6:14 ` [PATCH v8 3/7] soc: ti: Add IOMMU-like PVU driver huaqian.li
` (4 subsequent siblings)
6 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-04-22 6:14 UTC (permalink / raw)
To: helgaas
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr, Krzysztof Kozlowski
From: Jan Kiszka <jan.kiszka@siemens.com>
The PVU on the AM65 SoC is capable of restricting DMA from PCIe devices
to specific regions of host memory. Add the optional property
"memory-regions" to point to such regions of memory when PVU is used.
Since the PVU deals with system physical addresses, utilizing the PVU
with PCIe devices also requires setting up the VMAP registers to map the
Requester ID of the PCIe device to the CBA Virtual ID, which in turn is
mapped to the system physical address. Hence, describe the VMAP
registers which are optional unless the PVU shall be used for PCIe.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
.../bindings/pci/ti,am65-pci-host.yaml | 28 +++++++++++++++++--
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
index 0a9d10532cc8..98f6c7f1b1a6 100644
--- a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
@@ -20,14 +20,18 @@ properties:
- ti,keystone-pcie
reg:
- maxItems: 4
+ minItems: 4
+ maxItems: 6
reg-names:
+ minItems: 4
items:
- const: app
- const: dbics
- const: config
- const: atu
+ - const: vmap_lp
+ - const: vmap_hp
interrupts:
maxItems: 1
@@ -69,6 +73,15 @@ properties:
items:
pattern: '^pcie-phy[0-1]$'
+ memory-region:
+ maxItems: 1
+ description: |
+ phandle to a restricted DMA pool to be used for all devices behind
+ this controller. The regions should be defined according to
+ reserved-memory/shared-dma-pool.yaml.
+ Note that enforcement via the PVU will only be available to
+ ti,am654-pcie-rc devices.
+
required:
- compatible
- reg
@@ -89,6 +102,13 @@ then:
- power-domains
- msi-map
- num-viewport
+else:
+ properties:
+ reg:
+ maxItems: 4
+
+ reg-names:
+ maxItems: 4
unevaluatedProperties: false
@@ -104,8 +124,10 @@ examples:
reg = <0x5500000 0x1000>,
<0x5501000 0x1000>,
<0x10000000 0x2000>,
- <0x5506000 0x1000>;
- reg-names = "app", "dbics", "config", "atu";
+ <0x5506000 0x1000>,
+ <0x2900000 0x1000>,
+ <0x2908000 0x1000>;
+ reg-names = "app", "dbics", "config", "atu", "vmap_lp", "vmap_hp";
power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <3>;
#size-cells = <2>;
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v8 3/7] soc: ti: Add IOMMU-like PVU driver
2025-04-22 6:13 ` [PATCH v8 " huaqian.li
2025-04-22 6:14 ` [PATCH v8 1/7] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit huaqian.li
2025-04-22 6:14 ` [PATCH v8 2/7] dt-bindings: PCI: ti,am65: Extend for use with PVU huaqian.li
@ 2025-04-22 6:14 ` huaqian.li
2025-04-22 6:14 ` [PATCH v8 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654 huaqian.li
` (3 subsequent siblings)
6 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-04-22 6:14 UTC (permalink / raw)
To: helgaas
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
The TI Peripheral Virtualization Unit (PVU) permits to define a limited
set of mappings for DMA requests on the system memory. Unlike with an
IOMMU, there is no fallback to a memory-backed page table, only a fixed
set of register-backed TLBs. Emulating an IOMMU behavior appears to be
the more fragile the more fragmentation of pending requests occur.
Therefore, this driver does not expose the PVU as an IOMMU. It rather
introduces a simple, static interface to devices that are under
restricted-dma-pool constraints. They can register their pools with the
PVUs, enabling only those pools to work for DMA. As also MSI is issued
as DMA, the PVU already register the related translator region of the
AM654 as valid DMA target.
This driver is the essential building block for limiting DMA from
untrusted devices to clearly defined memory regions in the absence of a
real IOMMU (SMMU).
Co-developed-by: Diogo Ivo <diogo.ivo@siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
drivers/soc/ti/Kconfig | 4 +
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti-pvu.c | 500 ++++++++++++++++++++++++++++++++++++++++
include/linux/ti-pvu.h | 32 +++
4 files changed, 537 insertions(+)
create mode 100644 drivers/soc/ti/ti-pvu.c
create mode 100644 include/linux/ti-pvu.h
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 1a93001c9e36..af7173ad84de 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -82,6 +82,10 @@ config TI_PRUSS
processors on various TI SoCs. It's safe to say N here if you're
not interested in the PRU or if you are unsure.
+config TI_PVU
+ bool "TI Peripheral Virtualization Unit driver"
+ depends on ARCH_K3 && DMA_RESTRICTED_POOL
+
endif # SOC_TI
config TI_SCI_INTA_MSI_DOMAIN
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index cb800a745e66..ecff3fd8c433 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_TI_K3_RINGACC) += k3-ringacc.o
obj-$(CONFIG_TI_K3_SOCINFO) += k3-socinfo.o
obj-$(CONFIG_TI_PRUSS) += pruss.o
obj-$(CONFIG_POWER_AVS_OMAP) += smartreflex.o
+obj-$(CONFIG_TI_PVU) += ti-pvu.o
diff --git a/drivers/soc/ti/ti-pvu.c b/drivers/soc/ti/ti-pvu.c
new file mode 100644
index 000000000000..38996c74cce7
--- /dev/null
+++ b/drivers/soc/ti/ti-pvu.c
@@ -0,0 +1,500 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI Peripheral Virtualization Unit driver for static DMA isolation
+ *
+ * Copyright (c) 2024, Siemens AG
+ */
+
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/ti-pvu.h>
+
+#define PVU_CONFIG 0x4
+#define PVU_ENABLE 0x10
+#define PVU_VIRTID_MAP1 0x14
+#define PVU_VIRTID_MAP2 0x18
+#define PVU_EXCEPTION_LOGGING_CONTROL 0x120
+#define PVU_EXCEPTION_LOGGING_HEADER0 0x124
+#define PVU_EXCEPTION_LOGGING_HEADER1 0x128
+#define PVU_EXCEPTION_LOGGING_DATA0 0x12c
+#define PVU_EXCEPTION_LOGGING_DATA1 0x130
+#define PVU_EXCEPTION_LOGGING_DATA2 0x134
+#define PVU_EXCEPTION_LOGGING_DATA2_SECURE BIT(0)
+#define PVU_EXCEPTION_LOGGING_DATA2_PRIV BIT(1)
+#define PVU_EXCEPTION_LOGGING_DATA2_CACHEABLE BIT(2)
+#define PVU_EXCEPTION_LOGGING_DATA2_DEBUG BIT(3)
+#define PVU_EXCEPTION_LOGGING_DATA2_READ BIT(4)
+#define PVU_EXCEPTION_LOGGING_DATA2_WRITE BIT(5)
+#define PVU_EXCEPTION_LOGGING_DATA3 0x138
+#define PVU_EXCEPTION_ENABLE_SET 0x148
+#define PVU_EOI_REG 0x150
+
+#define PVU_CHAIN 0x0
+#define PVU_CHAIN_EN BIT(31)
+#define PVU_CHAIN_LOG_DIS BIT(30)
+#define PVU_CHAIN_FAULT BIT(29)
+#define PVU_CHAIN_MASK 0xfff
+#define PVU_ENTRY0 0x20
+#define PVU_ENTRY1 0x24
+#define PVU_ENTRY1_RESERVED_MASK 0xffff0000
+#define PVU_ENTRY1_VBASE_H_MASK 0xffff
+#define PVU_ENTRY2 0x28
+#define PVU_ENTRY2_RESERVED_MASK 0x1fd00080
+#define PVU_ENTRY2_INVALID (0U << 30)
+#define PVU_ENTRY2_VALID (2U << 30)
+#define PVU_ENTRY2_MODE_MASK 0xc0000000
+#define PVU_ENTRY2_PSIZE_SHIFT 16
+#define PVU_ENTRY2_PSIZE_MASK 0xf
+#define PVU_ENTRY2_PERM_SX BIT(15)
+#define PVU_ENTRY2_PERM_SW BIT(14)
+#define PVU_ENTRY2_PERM_SR BIT(13)
+#define PVU_ENTRY2_PERM_UX BIT(12)
+#define PVU_ENTRY2_PERM_UW BIT(11)
+#define PVU_ENTRY2_PERM_UR BIT(10)
+#define PVU_ENTRY2_MEM_WRITETHROUGH (2 << 8)
+#define PVU_ENTRY2_OUTER_SHARABLE BIT(4)
+#define PVU_ENTRY2_IS_NOALLOC (0 << 2)
+#define PVU_ENTRY2_OS_NOALLOC (0 << 0)
+#define PVU_ENTRY4 0x30
+#define PVU_ENTRY5 0x34
+#define PVU_ENTRY5_RESERVED_MASK 0xffff0000
+#define PVU_ENTRY5_PBASE_H_MASK 0xffff
+#define PVU_ENTRY6 0x38
+#define PVU_ENTRY6_RESERVED_MASK 0xffffffe0
+
+#define NUM_VIRTIDS 1
+
+static const struct regmap_config pvu_cfg_regmap_cfg = {
+ .name = "pvu-cfg",
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = PVU_EOI_REG,
+};
+
+enum pvu_cfg_regfields {
+ PVU_TLBS,
+ PVU_TLB_ENTRIES,
+ PVU_ENABLED,
+ PVU_DMA_CNT,
+ PVU_DMA_CL0,
+ PVU_DMA_CL1,
+ PVU_DMA_CL2,
+ PVU_DMA_CL3,
+ PVU_MAX_VIRTID,
+ PVU_EXC_SRC_ID,
+ PVU_EXC_CODE,
+ PVU_EXC_ADDR_L,
+ PVU_EXC_ADDR_H,
+ PVU_EXC_PRIV_ID,
+ PVU_EXC_PROPS,
+ PVU_EXC_ROUTE_ID,
+ PVU_EXC_BYTE_CNT,
+ PVU_EXC_ENABLE,
+ PVU_EOI,
+ PVU_MAX_CFG_FIELDS,
+};
+
+static const struct reg_field pvu_cfg_reg_fields[] = {
+ [PVU_TLBS] = REG_FIELD(PVU_CONFIG, 0, 15),
+ [PVU_TLB_ENTRIES] = REG_FIELD(PVU_CONFIG, 16, 23),
+ [PVU_ENABLED] = REG_FIELD(PVU_ENABLE, 0, 0),
+ [PVU_DMA_CNT] = REG_FIELD(PVU_VIRTID_MAP1, 0, 11),
+ [PVU_DMA_CL0] = REG_FIELD(PVU_VIRTID_MAP1, 16, 17),
+ [PVU_DMA_CL1] = REG_FIELD(PVU_VIRTID_MAP1, 18, 19),
+ [PVU_DMA_CL2] = REG_FIELD(PVU_VIRTID_MAP1, 20, 21),
+ [PVU_DMA_CL3] = REG_FIELD(PVU_VIRTID_MAP1, 22, 23),
+ [PVU_MAX_VIRTID] = REG_FIELD(PVU_VIRTID_MAP2, 0, 11),
+ [PVU_EXC_SRC_ID] = REG_FIELD(PVU_EXCEPTION_LOGGING_HEADER0, 8, 23),
+ [PVU_EXC_CODE] = REG_FIELD(PVU_EXCEPTION_LOGGING_HEADER1, 16, 23),
+ [PVU_EXC_ADDR_L] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA0, 0, 31),
+ [PVU_EXC_ADDR_H] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA1, 0, 15),
+ [PVU_EXC_PRIV_ID] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA2, 0, 7),
+ [PVU_EXC_PROPS] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA2, 8, 13),
+ [PVU_EXC_ROUTE_ID] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA2, 16, 27),
+ [PVU_EXC_BYTE_CNT] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA3, 0, 9),
+ [PVU_EXC_ENABLE] = REG_FIELD(PVU_EXCEPTION_ENABLE_SET, 0, 0),
+ [PVU_EOI] = REG_FIELD(PVU_EOI_REG, 0, 15),
+};
+
+struct ti_pvu {
+ struct list_head entry;
+ struct platform_device *pdev;
+ struct regmap *cfg;
+ struct regmap_field *cfg_fields[PVU_MAX_CFG_FIELDS];
+ void __iomem *tlbif_base;
+ unsigned int num_tlbs;
+ unsigned int num_entries;
+};
+
+static const char *pvu_excp_code_string[] = {
+ "PVU miss",
+ "maximum VirtID violation",
+ "<reserved>",
+ "read permission violation",
+ "write permission violation",
+ "execute permission violation",
+ "prefetch permission violation",
+ "<unknown>",
+};
+
+static const u64 pvu_page_size[] = {
+ 4 * 1024ULL,
+ 16 * 1024ULL,
+ 64 * 1024ULL,
+ 2 * 1024 * 1024ULL,
+ 32 * 1024 * 1024ULL,
+ 512 * 1024 * 1024ULL,
+ 1 * 1024 * 1024 * 1024ULL,
+ 16 * 1024 * 1024 * 1024ULL
+};
+
+static DEFINE_MUTEX(ti_pvu_lock);
+static LIST_HEAD(ti_pvu_list);
+
+static unsigned int pvu_field_read(struct ti_pvu *pvu, enum pvu_cfg_regfields f)
+{
+ int ret;
+ unsigned int val;
+
+ ret = regmap_field_read(pvu->cfg_fields[f], &val);
+ if (ret)
+ dev_err(&pvu->pdev->dev, "failed to read field\n");
+
+ return val;
+}
+
+static void pvu_field_write(struct ti_pvu *pvu, enum pvu_cfg_regfields f,
+ unsigned int val)
+{
+ int ret;
+
+ ret = regmap_field_write(pvu->cfg_fields[f], val);
+ if (ret)
+ dev_err(&pvu->pdev->dev, "failed to write field\n");
+}
+
+static irqreturn_t pvu_fault_isr(int irq, void *dev_id)
+{
+ u32 code, bytes, route_id, priv_id, props;
+ struct ti_pvu *pvu = dev_id;
+ const char *code_str;
+ u64 address;
+
+ code = pvu_field_read(pvu, PVU_EXC_CODE);
+ code_str = pvu_excp_code_string[
+ min(code, (u32)ARRAY_SIZE(pvu_excp_code_string) - 1)];
+
+ dev_err(&pvu->pdev->dev, "fault detected, code %d (%s)\n",
+ code, code_str);
+
+ address = pvu_field_read(pvu, PVU_EXC_ADDR_L);
+ address |= (u64)pvu_field_read(pvu, PVU_EXC_ADDR_H) << 32;
+
+ bytes = pvu_field_read(pvu, PVU_EXC_BYTE_CNT);
+
+ route_id = pvu_field_read(pvu, PVU_EXC_ROUTE_ID);
+ priv_id = pvu_field_read(pvu, PVU_EXC_PRIV_ID);
+ props = pvu_field_read(pvu, PVU_EXC_PROPS);
+
+ dev_err(&pvu->pdev->dev,
+ " address 0x%016llx size %d route-ID %d priv-ID %d flags %c%c%c%c%c%c\n",
+ address, bytes, route_id, priv_id,
+ (props & PVU_EXCEPTION_LOGGING_DATA2_WRITE) ? 'W' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_READ) ? 'R' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_DEBUG) ? 'D' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_CACHEABLE) ? 'C' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_PRIV) ? 'P' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_SECURE) ? 'S' : '-');
+
+ pvu_field_write(pvu, PVU_EOI, 0);
+
+ return IRQ_HANDLED;
+}
+
+static void __iomem *pvu_get_entry_base(struct ti_pvu *pvu, unsigned int entry)
+{
+ return pvu->tlbif_base + (entry / pvu->num_entries) * 0x1000 +
+ (entry % pvu->num_entries) * 0x20;
+}
+
+static int pvu_get_free_entry(struct ti_pvu *pvu)
+{
+ unsigned int n;
+ u32 val;
+
+ /* We use up to 2 TLBs via chainging */
+ for (n = 0; n < pvu->num_entries * 2; n++) {
+ val = readl(pvu_get_entry_base(pvu, n) + PVU_ENTRY2);
+ if ((val & PVU_ENTRY2_MODE_MASK) == PVU_ENTRY2_INVALID)
+ return n;
+ }
+ return -ENOSPC;
+}
+
+static void pvu_write_entry(struct ti_pvu *pvu, unsigned int entry,
+ u64 addr, u32 psize)
+{
+ void __iomem *entry_base = pvu_get_entry_base(pvu, entry);
+ u32 val;
+
+ writel((u32)addr, entry_base + PVU_ENTRY0);
+
+ val = readl(entry_base + PVU_ENTRY1);
+ val &= PVU_ENTRY1_RESERVED_MASK;
+ val |= (addr >> 32) & PVU_ENTRY1_VBASE_H_MASK;
+ writel(val, entry_base + PVU_ENTRY1);
+
+ writel((u32)addr, entry_base + PVU_ENTRY4);
+
+ val = readl(entry_base + PVU_ENTRY5);
+ val &= PVU_ENTRY5_RESERVED_MASK;
+ val |= (addr >> 32) & PVU_ENTRY5_PBASE_H_MASK;
+ writel(val, entry_base + PVU_ENTRY5);
+
+ val = readl(entry_base + PVU_ENTRY6);
+ val &= PVU_ENTRY6_RESERVED_MASK;
+ writel(val, entry_base + PVU_ENTRY6);
+
+ val = readl(entry_base + PVU_ENTRY2);
+ val &= PVU_ENTRY2_RESERVED_MASK;
+ val |= psize << PVU_ENTRY2_PSIZE_SHIFT;
+ val |= PVU_ENTRY2_VALID |
+ PVU_ENTRY2_PERM_UR | PVU_ENTRY2_PERM_SR |
+ PVU_ENTRY2_PERM_UW | PVU_ENTRY2_PERM_SW |
+ PVU_ENTRY2_PERM_UX | PVU_ENTRY2_PERM_SX |
+ PVU_ENTRY2_MEM_WRITETHROUGH | PVU_ENTRY2_OUTER_SHARABLE |
+ PVU_ENTRY2_IS_NOALLOC | PVU_ENTRY2_OS_NOALLOC;
+ writel(val, entry_base + PVU_ENTRY2);
+}
+
+static int pvu_create_region(struct ti_pvu *pvu, u64 addr, u64 size)
+{
+ u64 page_size;
+ int psize;
+ int entry;
+
+ while (size > 0) {
+ entry = pvu_get_free_entry(pvu);
+ if (entry < 0) {
+ dev_err(&pvu->pdev->dev, "ran out of TLB entries\n");
+ return -ENOSPC;
+ }
+
+ for (psize = ARRAY_SIZE(pvu_page_size) - 1; psize >= 0; psize--) {
+ page_size = pvu_page_size[psize];
+ if (size >= page_size && (addr & (page_size - 1)) == 0)
+ break;
+ }
+ if (psize < 0) {
+ dev_err(&pvu->pdev->dev, "unaligned region provided\n");
+ return -EINVAL;
+ }
+
+ pvu_write_entry(pvu, entry, addr, psize);
+ dev_info(&pvu->pdev->dev,
+ "created TLB entry %d.%d: 0x%08llx, psize %d (0x%08llx)\n",
+ entry / pvu->num_entries, entry % pvu->num_entries,
+ addr, psize, page_size);
+
+ size -= page_size;
+ addr += page_size;
+ }
+
+ return 0;
+}
+
+static void pvu_remove_region(struct ti_pvu *pvu, u64 addr, u64 size)
+{
+ void __iomem *entry_base;
+ unsigned int n, psize;
+ u64 entry_addr;
+ u32 entry2;
+
+ for (n = 0; n < pvu->num_entries * 2; n++) {
+ entry_base = pvu_get_entry_base(pvu, n);
+ entry2 = readl(entry_base + PVU_ENTRY2);
+ if ((entry2 & PVU_ENTRY2_MODE_MASK) != PVU_ENTRY2_VALID)
+ continue;
+
+ entry_addr = readl(entry_base + PVU_ENTRY0);
+ entry_addr |= (u64)(readl(entry_base + PVU_ENTRY1) &
+ PVU_ENTRY1_VBASE_H_MASK) << 32;
+
+ psize = (entry2 >> PVU_ENTRY2_PSIZE_SHIFT) &
+ PVU_ENTRY2_PSIZE_MASK;
+ if (psize >= ARRAY_SIZE(pvu_page_size))
+ continue;
+
+ if (entry_addr >= addr &&
+ (entry_addr + pvu_page_size[psize]) <= (addr + size)) {
+ entry2 &= ~PVU_ENTRY2_MODE_MASK;
+ entry2 |= PVU_ENTRY2_INVALID;
+ writel(entry2, entry_base + PVU_ENTRY2);
+
+ dev_info(&pvu->pdev->dev, "removed TLB entry %d.%d\n",
+ n / pvu->num_entries, n % pvu->num_entries);
+ }
+ }
+}
+
+int ti_pvu_create_region(unsigned int virt_id, const struct resource *region)
+{
+ struct ti_pvu *pvu;
+ int err = 0;
+
+ if (virt_id >= NUM_VIRTIDS)
+ return -EINVAL;
+
+ mutex_lock(&ti_pvu_lock);
+
+ list_for_each_entry(pvu, &ti_pvu_list, entry) {
+ err = pvu_create_region(pvu, region->start,
+ region->end + 1 - region->start);
+ if (err)
+ break;
+ }
+
+ mutex_unlock(&ti_pvu_lock);
+
+ return err;
+}
+
+int ti_pvu_remove_region(unsigned int virt_id, const struct resource *region)
+{
+ struct ti_pvu *pvu;
+
+ if (virt_id >= NUM_VIRTIDS)
+ return -EINVAL;
+
+ mutex_lock(&ti_pvu_lock);
+
+ list_for_each_entry(pvu, &ti_pvu_list, entry) {
+ pvu_remove_region(pvu, region->start,
+ region->end + 1 - region->start);
+ }
+
+ mutex_unlock(&ti_pvu_lock);
+
+ return 0;
+}
+
+static int ti_pvu_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *its_node;
+ void __iomem *base;
+ struct ti_pvu *pvu;
+ u32 val;
+ int ret;
+
+ pvu = devm_kzalloc(dev, sizeof(*pvu), GFP_KERNEL);
+ if (!pvu)
+ return -ENOMEM;
+
+ pvu->pdev = pdev;
+
+ base = devm_platform_ioremap_resource_byname(pdev, "cfg");
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ pvu->cfg = devm_regmap_init_mmio(dev, base, &pvu_cfg_regmap_cfg);
+ if (IS_ERR(pvu->cfg))
+ return dev_err_probe(dev, PTR_ERR(pvu->cfg), "failed to init cfg regmap");
+
+ ret = devm_regmap_field_bulk_alloc(dev, pvu->cfg, pvu->cfg_fields,
+ pvu_cfg_reg_fields, PVU_MAX_CFG_FIELDS);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to alloc cfg regmap fields");
+
+ pvu->num_tlbs = pvu_field_read(pvu, PVU_TLBS);
+ pvu->num_entries = pvu_field_read(pvu, PVU_TLB_ENTRIES);
+ dev_info(dev, "TLBs: %d, entries per TLB: %d\n", pvu->num_tlbs,
+ pvu->num_entries);
+
+ pvu->tlbif_base = devm_platform_ioremap_resource_byname(pdev, "tlbif");
+ if (IS_ERR(pvu->tlbif_base))
+ return PTR_ERR(pvu->tlbif_base);
+
+ its_node = of_find_compatible_node(0, 0, "arm,gic-v3-its");
+ if (its_node) {
+ u32 pre_its_window[2];
+
+ ret = of_property_read_u32_array(its_node,
+ "socionext,synquacer-pre-its",
+ pre_its_window,
+ ARRAY_SIZE(pre_its_window));
+ if (ret) {
+ dev_err(dev, "failed to read pre-its property\n");
+ return ret;
+ }
+
+ ret = pvu_create_region(pvu, pre_its_window[0],
+ pre_its_window[1]);
+ if (ret)
+ return ret;
+ }
+
+ /* Enable the first two TLBs, chaining from 0 to 1 */
+ val = readl(pvu->tlbif_base + PVU_CHAIN);
+ val |= PVU_CHAIN_EN | 1;
+ writel(val, pvu->tlbif_base + PVU_CHAIN);
+
+ val = readl(pvu->tlbif_base + PVU_CHAIN + 0x1000);
+ val |= PVU_CHAIN_EN;
+ writel(val, pvu->tlbif_base + PVU_CHAIN + 0x1000);
+
+ pvu_field_write(pvu, PVU_DMA_CNT, 0);
+ pvu_field_write(pvu, PVU_DMA_CL0, 0);
+ pvu_field_write(pvu, PVU_DMA_CL1, 0);
+ pvu_field_write(pvu, PVU_DMA_CL2, 0);
+ pvu_field_write(pvu, PVU_DMA_CL3, 0);
+ pvu_field_write(pvu, PVU_MAX_VIRTID, NUM_VIRTIDS);
+
+ ret = platform_get_irq(pdev, 0);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to get irq\n");
+
+ ret = devm_request_irq(dev, ret, pvu_fault_isr, 0, dev_name(dev), pvu);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to request irq\n");
+
+ pvu_field_write(pvu, PVU_EXC_ENABLE, 1);
+ pvu_field_write(pvu, PVU_ENABLED, 1);
+
+ dev_set_drvdata(dev, pvu);
+
+ mutex_lock(&ti_pvu_lock);
+ list_add(&pvu->entry, &ti_pvu_list);
+ mutex_unlock(&ti_pvu_lock);
+
+ return 0;
+}
+
+static void ti_pvu_remove(struct platform_device *pdev)
+{
+ struct ti_pvu *pvu = dev_get_drvdata(&pdev->dev);
+
+ mutex_lock(&ti_pvu_lock);
+ list_del(&pvu->entry);
+ mutex_unlock(&ti_pvu_lock);
+}
+
+static const struct of_device_id ti_pvu_of_match[] = {
+ { .compatible = "ti,am654-pvu", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ti_pvu_of_match);
+
+static struct platform_driver ti_pvu_driver = {
+ .driver = {
+ .name = "ti-pvu",
+ .of_match_table = ti_pvu_of_match,
+ },
+ .probe = ti_pvu_probe,
+ .remove = ti_pvu_remove,
+};
+module_platform_driver(ti_pvu_driver);
diff --git a/include/linux/ti-pvu.h b/include/linux/ti-pvu.h
new file mode 100644
index 000000000000..7088da8dad9a
--- /dev/null
+++ b/include/linux/ti-pvu.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * TI Peripheral Virtualization Unit driver for static DMA isolation
+ *
+ * Copyright (c) 2024, Siemens AG
+ */
+
+#ifndef _LINUX_TI_PVU_H
+#define _LINUX_TI_PVU_H
+
+#include <linux/ioport.h>
+
+#if IS_ENABLED(CONFIG_TI_PVU)
+int ti_pvu_create_region(unsigned int virt_id,
+ const struct resource *region);
+int ti_pvu_remove_region(unsigned int virt_id,
+ const struct resource *region);
+#else
+static inline int ti_pvu_create_region(unsigned int virt_id,
+ const struct resource *region)
+{
+ return 0;
+}
+
+static inline int ti_pvu_remove_region(unsigned int virt_id,
+ const struct resource *region)
+{
+ return 0;
+}
+#endif
+
+#endif /* _LINUX_TI_PVU_H */
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v8 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654
2025-04-22 6:13 ` [PATCH v8 " huaqian.li
` (2 preceding siblings ...)
2025-04-22 6:14 ` [PATCH v8 3/7] soc: ti: Add IOMMU-like PVU driver huaqian.li
@ 2025-04-22 6:14 ` huaqian.li
2025-04-25 16:48 ` Siddharth Vadapalli
2025-04-22 6:14 ` [PATCH v8 5/7] arm64: dts: ti: k3-am65-main: Add PVU nodes huaqian.li
` (2 subsequent siblings)
6 siblings, 1 reply; 58+ messages in thread
From: huaqian.li @ 2025-04-22 6:14 UTC (permalink / raw)
To: helgaas
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
The AM654 lacks an IOMMU, thus does not support isolating DMA requests
from untrusted PCI devices to selected memory regions this way. Use
static PVU-based protection instead. The PVU, when enabled, will only
accept DMA requests that address previously configured regions.
Use the availability of a restricted-dma-pool memory region as trigger
and register it as valid DMA target with the PVU. In addition, enable
the mapping of requester IDs to VirtIDs in the PCI RC. Use only a single
VirtID so far, catching all devices. This may be extended later on.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
drivers/pci/controller/dwc/pci-keystone.c | 106 ++++++++++++++++++++++
1 file changed, 106 insertions(+)
diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
index 76a37368ae4f..ea2d8768e333 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -19,6 +19,7 @@
#include <linux/mfd/syscon.h>
#include <linux/msi.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_pci.h>
#include <linux/phy/phy.h>
@@ -26,6 +27,7 @@
#include <linux/regmap.h>
#include <linux/resource.h>
#include <linux/signal.h>
+#include <linux/ti-pvu.h>
#include "../../pci.h"
#include "pcie-designware.h"
@@ -111,6 +113,16 @@
#define PCI_DEVICE_ID_TI_AM654X 0xb00c
+#define KS_PCI_VIRTID 0
+
+#define PCIE_VMAP_xP_CTRL 0x0
+#define PCIE_VMAP_xP_REQID 0x4
+#define PCIE_VMAP_xP_VIRTID 0x8
+
+#define PCIE_VMAP_xP_CTRL_EN BIT(0)
+
+#define PCIE_VMAP_xP_VIRTID_VID_MASK 0xfff
+
struct ks_pcie_of_data {
enum dw_pcie_device_mode mode;
const struct dw_pcie_host_ops *host_ops;
@@ -1137,6 +1149,94 @@ static const struct of_device_id ks_pcie_of_match[] = {
{ },
};
+static int ks_init_vmap(struct platform_device *pdev, const char *vmap_name)
+{
+ struct resource *res;
+ void __iomem *base;
+ u32 val;
+
+ if (!IS_ENABLED(CONFIG_TI_PVU))
+ return 0;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, vmap_name);
+ base = devm_pci_remap_cfg_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ writel(0, base + PCIE_VMAP_xP_REQID);
+
+ val = readl(base + PCIE_VMAP_xP_VIRTID);
+ val &= ~PCIE_VMAP_xP_VIRTID_VID_MASK;
+ val |= KS_PCI_VIRTID;
+ writel(val, base + PCIE_VMAP_xP_VIRTID);
+
+ val = readl(base + PCIE_VMAP_xP_CTRL);
+ val |= PCIE_VMAP_xP_CTRL_EN;
+ writel(val, base + PCIE_VMAP_xP_CTRL);
+
+ return 0;
+}
+
+static int ks_init_restricted_dma(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct of_phandle_iterator it;
+ struct resource phys;
+ int err;
+
+ if (!IS_ENABLED(CONFIG_TI_PVU))
+ return 0;
+
+ /* Only process the first restricted DMA pool, more are not allowed */
+ of_for_each_phandle(&it, err, dev->of_node, "memory-region",
+ NULL, 0) {
+ if (of_device_is_compatible(it.node, "restricted-dma-pool"))
+ break;
+ }
+ if (err)
+ return err == -ENOENT ? 0 : err;
+
+ err = of_address_to_resource(it.node, 0, &phys);
+ if (err < 0) {
+ dev_err(dev, "failed to parse memory region %pOF: %d\n",
+ it.node, err);
+ return 0;
+ }
+
+ /* Map all incoming requests on low and high prio port to virtID 0 */
+ err = ks_init_vmap(pdev, "vmap_lp");
+ if (err)
+ return err;
+ err = ks_init_vmap(pdev, "vmap_hp");
+ if (err)
+ return err;
+
+ /*
+ * Enforce DMA pool usage with the help of the PVU.
+ * Any request outside will be dropped and raise an error at the PVU.
+ */
+ return ti_pvu_create_region(KS_PCI_VIRTID, &phys);
+}
+
+static void ks_release_restricted_dma(struct platform_device *pdev)
+{
+ struct of_phandle_iterator it;
+ struct resource phys;
+ int err;
+
+ if (!IS_ENABLED(CONFIG_TI_PVU))
+ return;
+
+ of_for_each_phandle(&it, err, pdev->dev.of_node, "memory-region",
+ NULL, 0) {
+ if (of_device_is_compatible(it.node, "restricted-dma-pool") &&
+ of_address_to_resource(it.node, 0, &phys) == 0) {
+ ti_pvu_remove_region(KS_PCI_VIRTID, &phys);
+ break;
+ }
+ }
+}
+
static int ks_pcie_probe(struct platform_device *pdev)
{
const struct dw_pcie_host_ops *host_ops;
@@ -1285,6 +1385,10 @@ static int ks_pcie_probe(struct platform_device *pdev)
if (ret < 0)
goto err_get_sync;
+ ret = ks_init_restricted_dma(pdev);
+ if (ret < 0)
+ goto err_get_sync;
+
switch (mode) {
case DW_PCIE_RC_TYPE:
if (!IS_ENABLED(CONFIG_PCI_KEYSTONE_HOST)) {
@@ -1366,6 +1470,8 @@ static void ks_pcie_remove(struct platform_device *pdev)
int num_lanes = ks_pcie->num_lanes;
struct device *dev = &pdev->dev;
+ ks_release_restricted_dma(pdev);
+
pm_runtime_put(dev);
pm_runtime_disable(dev);
ks_pcie_disable_phy(ks_pcie);
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v8 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654
2025-04-22 6:14 ` [PATCH v8 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654 huaqian.li
@ 2025-04-25 16:48 ` Siddharth Vadapalli
2025-07-15 8:55 ` Jan Kiszka
0 siblings, 1 reply; 58+ messages in thread
From: Siddharth Vadapalli @ 2025-04-25 16:48 UTC (permalink / raw)
To: huaqian.li
Cc: helgaas, baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel, linux-kernel,
linux-pci, lpieralisi, nm, robh, s-vadapalli, ssantosh, vigneshr
On Tue, Apr 22, 2025 at 02:14:03PM +0800, huaqian.li@siemens.com wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> The AM654 lacks an IOMMU, thus does not support isolating DMA requests
> from untrusted PCI devices to selected memory regions this way. Use
> static PVU-based protection instead. The PVU, when enabled, will only
> accept DMA requests that address previously configured regions.
>
> Use the availability of a restricted-dma-pool memory region as trigger
> and register it as valid DMA target with the PVU. In addition, enable
> the mapping of requester IDs to VirtIDs in the PCI RC. Use only a single
> VirtID so far, catching all devices. This may be extended later on.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
> ---
> drivers/pci/controller/dwc/pci-keystone.c | 106 ++++++++++++++++++++++
> 1 file changed, 106 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
> index 76a37368ae4f..ea2d8768e333 100644
> --- a/drivers/pci/controller/dwc/pci-keystone.c
> +++ b/drivers/pci/controller/dwc/pci-keystone.c
> @@ -19,6 +19,7 @@
> #include <linux/mfd/syscon.h>
> #include <linux/msi.h>
> #include <linux/of.h>
> +#include <linux/of_address.h>
> #include <linux/of_irq.h>
> #include <linux/of_pci.h>
> #include <linux/phy/phy.h>
> @@ -26,6 +27,7 @@
> #include <linux/regmap.h>
> #include <linux/resource.h>
> #include <linux/signal.h>
> +#include <linux/ti-pvu.h>
>
> #include "../../pci.h"
> #include "pcie-designware.h"
> @@ -111,6 +113,16 @@
>
> #define PCI_DEVICE_ID_TI_AM654X 0xb00c
>
> +#define KS_PCI_VIRTID 0
> +
> +#define PCIE_VMAP_xP_CTRL 0x0
> +#define PCIE_VMAP_xP_REQID 0x4
> +#define PCIE_VMAP_xP_VIRTID 0x8
> +
> +#define PCIE_VMAP_xP_CTRL_EN BIT(0)
> +
> +#define PCIE_VMAP_xP_VIRTID_VID_MASK 0xfff
> +
> struct ks_pcie_of_data {
> enum dw_pcie_device_mode mode;
> const struct dw_pcie_host_ops *host_ops;
> @@ -1137,6 +1149,94 @@ static const struct of_device_id ks_pcie_of_match[] = {
> { },
> };
>
> +static int ks_init_vmap(struct platform_device *pdev, const char *vmap_name)
> +{
> + struct resource *res;
> + void __iomem *base;
> + u32 val;
> +
> + if (!IS_ENABLED(CONFIG_TI_PVU))
> + return 0;
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, vmap_name);
> + base = devm_pci_remap_cfg_resource(&pdev->dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + writel(0, base + PCIE_VMAP_xP_REQID);
> +
> + val = readl(base + PCIE_VMAP_xP_VIRTID);
> + val &= ~PCIE_VMAP_xP_VIRTID_VID_MASK;
> + val |= KS_PCI_VIRTID;
While it has been stated that we are going to start off with a single
VirtID for now and extend it later on, is there an example for how it may
be extended? The only option I see is that of associating one VirtID for
Low-Priority (LP) traffic and another for High-Priority (HP) traffic, in
which case, it might be better to define them upfront and use them like:
#define KS_PCI_LP_VIRTID 0
#define KS_PCI_HP_VIRTID 1
> + writel(val, base + PCIE_VMAP_xP_VIRTID);
> +
> + val = readl(base + PCIE_VMAP_xP_CTRL);
> + val |= PCIE_VMAP_xP_CTRL_EN;
> + writel(val, base + PCIE_VMAP_xP_CTRL);
> +
> + return 0;
> +}
> +
> +static int ks_init_restricted_dma(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct of_phandle_iterator it;
> + struct resource phys;
> + int err;
> +
> + if (!IS_ENABLED(CONFIG_TI_PVU))
> + return 0;
> +
> + /* Only process the first restricted DMA pool, more are not allowed */
> + of_for_each_phandle(&it, err, dev->of_node, "memory-region",
> + NULL, 0) {
> + if (of_device_is_compatible(it.node, "restricted-dma-pool"))
> + break;
> + }
> + if (err)
> + return err == -ENOENT ? 0 : err;
> +
> + err = of_address_to_resource(it.node, 0, &phys);
> + if (err < 0) {
> + dev_err(dev, "failed to parse memory region %pOF: %d\n",
> + it.node, err);
> + return 0;
> + }
> +
> + /* Map all incoming requests on low and high prio port to virtID 0 */
The question I asked above applies here too. How is it planned to extend
support for multiple VirtIDs, if not on the basis of assigining one
VirtID to LP traffic and another to HP traffic? Since we have an option
of using different VirtIDs for LP and HP traffic, why not use it? Is
there going to be an issue with using VirtID 0 for LP traffic and VirtID 1
for HP traffic?
> + err = ks_init_vmap(pdev, "vmap_lp");
> + if (err)
> + return err;
> + err = ks_init_vmap(pdev, "vmap_hp");
> + if (err)
> + return err;
> +
> + /*
> + * Enforce DMA pool usage with the help of the PVU.
> + * Any request outside will be dropped and raise an error at the PVU.
> + */
> + return ti_pvu_create_region(KS_PCI_VIRTID, &phys);
Same as above, we are passing a single VIRTID and not an array, so it
isn't clear to me as to how it will be extended in the future.
> +}
> +
> +static void ks_release_restricted_dma(struct platform_device *pdev)
> +{
> + struct of_phandle_iterator it;
> + struct resource phys;
> + int err;
> +
> + if (!IS_ENABLED(CONFIG_TI_PVU))
> + return;
> +
> + of_for_each_phandle(&it, err, pdev->dev.of_node, "memory-region",
> + NULL, 0) {
> + if (of_device_is_compatible(it.node, "restricted-dma-pool") &&
> + of_address_to_resource(it.node, 0, &phys) == 0) {
> + ti_pvu_remove_region(KS_PCI_VIRTID, &phys);
> + break;
> + }
> + }
> +}
> +
> static int ks_pcie_probe(struct platform_device *pdev)
> {
> const struct dw_pcie_host_ops *host_ops;
> @@ -1285,6 +1385,10 @@ static int ks_pcie_probe(struct platform_device *pdev)
> if (ret < 0)
> goto err_get_sync;
>
> + ret = ks_init_restricted_dma(pdev);
> + if (ret < 0)
> + goto err_get_sync;
> +
Shouldn't the above be moved into the case for "DW_PCIE_RC_TYPE" below? Or
is this valid even when the SoC is configured to act as an Endpoint?
> switch (mode) {
> case DW_PCIE_RC_TYPE:
> if (!IS_ENABLED(CONFIG_PCI_KEYSTONE_HOST)) {
> @@ -1366,6 +1470,8 @@ static void ks_pcie_remove(struct platform_device *pdev)
> int num_lanes = ks_pcie->num_lanes;
> struct device *dev = &pdev->dev;
>
> + ks_release_restricted_dma(pdev);
> +
> pm_runtime_put(dev);
> pm_runtime_disable(dev);
> ks_pcie_disable_phy(ks_pcie);
Regards,
Siddharth.
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v8 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654
2025-04-25 16:48 ` Siddharth Vadapalli
@ 2025-07-15 8:55 ` Jan Kiszka
2025-07-15 9:15 ` Siddharth Vadapalli
0 siblings, 1 reply; 58+ messages in thread
From: Jan Kiszka @ 2025-07-15 8:55 UTC (permalink / raw)
To: Siddharth Vadapalli, huaqian.li
Cc: helgaas, baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
kristo, krzk+dt, kw, linux-arm-kernel, linux-kernel, linux-pci,
lpieralisi, nm, robh, ssantosh, vigneshr
On 25.04.25 18:48, Siddharth Vadapalli wrote:
> On Tue, Apr 22, 2025 at 02:14:03PM +0800, huaqian.li@siemens.com wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> The AM654 lacks an IOMMU, thus does not support isolating DMA requests
>> from untrusted PCI devices to selected memory regions this way. Use
>> static PVU-based protection instead. The PVU, when enabled, will only
>> accept DMA requests that address previously configured regions.
>>
>> Use the availability of a restricted-dma-pool memory region as trigger
>> and register it as valid DMA target with the PVU. In addition, enable
>> the mapping of requester IDs to VirtIDs in the PCI RC. Use only a single
>> VirtID so far, catching all devices. This may be extended later on.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>> Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
>> ---
>> drivers/pci/controller/dwc/pci-keystone.c | 106 ++++++++++++++++++++++
>> 1 file changed, 106 insertions(+)
>>
>> diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
>> index 76a37368ae4f..ea2d8768e333 100644
>> --- a/drivers/pci/controller/dwc/pci-keystone.c
>> +++ b/drivers/pci/controller/dwc/pci-keystone.c
>> @@ -19,6 +19,7 @@
>> #include <linux/mfd/syscon.h>
>> #include <linux/msi.h>
>> #include <linux/of.h>
>> +#include <linux/of_address.h>
>> #include <linux/of_irq.h>
>> #include <linux/of_pci.h>
>> #include <linux/phy/phy.h>
>> @@ -26,6 +27,7 @@
>> #include <linux/regmap.h>
>> #include <linux/resource.h>
>> #include <linux/signal.h>
>> +#include <linux/ti-pvu.h>
>>
>> #include "../../pci.h"
>> #include "pcie-designware.h"
>> @@ -111,6 +113,16 @@
>>
>> #define PCI_DEVICE_ID_TI_AM654X 0xb00c
>>
>> +#define KS_PCI_VIRTID 0
>> +
>> +#define PCIE_VMAP_xP_CTRL 0x0
>> +#define PCIE_VMAP_xP_REQID 0x4
>> +#define PCIE_VMAP_xP_VIRTID 0x8
>> +
>> +#define PCIE_VMAP_xP_CTRL_EN BIT(0)
>> +
>> +#define PCIE_VMAP_xP_VIRTID_VID_MASK 0xfff
>> +
>> struct ks_pcie_of_data {
>> enum dw_pcie_device_mode mode;
>> const struct dw_pcie_host_ops *host_ops;
>> @@ -1137,6 +1149,94 @@ static const struct of_device_id ks_pcie_of_match[] = {
>> { },
>> };
>>
>> +static int ks_init_vmap(struct platform_device *pdev, const char *vmap_name)
>> +{
>> + struct resource *res;
>> + void __iomem *base;
>> + u32 val;
>> +
>> + if (!IS_ENABLED(CONFIG_TI_PVU))
>> + return 0;
>> +
>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, vmap_name);
>> + base = devm_pci_remap_cfg_resource(&pdev->dev, res);
>> + if (IS_ERR(base))
>> + return PTR_ERR(base);
>> +
>> + writel(0, base + PCIE_VMAP_xP_REQID);
>> +
>> + val = readl(base + PCIE_VMAP_xP_VIRTID);
>> + val &= ~PCIE_VMAP_xP_VIRTID_VID_MASK;
>> + val |= KS_PCI_VIRTID;
>
> While it has been stated that we are going to start off with a single
> VirtID for now and extend it later on, is there an example for how it may
> be extended? The only option I see is that of associating one VirtID for
> Low-Priority (LP) traffic and another for High-Priority (HP) traffic, in
> which case, it might be better to define them upfront and use them like:
> #define KS_PCI_LP_VIRTID 0
> #define KS_PCI_HP_VIRTID 1
Sorry for the late reply, was just reminded of this question:
When trying to design anything beyond the current use case, I would be
struggling right now with the how, simply because we would have no user
of extended APIs around to make sure that the result would be useful.
Can you envision such use cases? If not, I would rather suggest to
postpone any attempts to broaden the API until we have such users.
>
>> + writel(val, base + PCIE_VMAP_xP_VIRTID);
>> +
>> + val = readl(base + PCIE_VMAP_xP_CTRL);
>> + val |= PCIE_VMAP_xP_CTRL_EN;
>> + writel(val, base + PCIE_VMAP_xP_CTRL);
>> +
>> + return 0;
>> +}
>> +
>> +static int ks_init_restricted_dma(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct of_phandle_iterator it;
>> + struct resource phys;
>> + int err;
>> +
>> + if (!IS_ENABLED(CONFIG_TI_PVU))
>> + return 0;
>> +
>> + /* Only process the first restricted DMA pool, more are not allowed */
>> + of_for_each_phandle(&it, err, dev->of_node, "memory-region",
>> + NULL, 0) {
>> + if (of_device_is_compatible(it.node, "restricted-dma-pool"))
>> + break;
>> + }
>> + if (err)
>> + return err == -ENOENT ? 0 : err;
>> +
>> + err = of_address_to_resource(it.node, 0, &phys);
>> + if (err < 0) {
>> + dev_err(dev, "failed to parse memory region %pOF: %d\n",
>> + it.node, err);
>> + return 0;
>> + }
>> +
>> + /* Map all incoming requests on low and high prio port to virtID 0 */
>
> The question I asked above applies here too. How is it planned to extend
> support for multiple VirtIDs, if not on the basis of assigining one
> VirtID to LP traffic and another to HP traffic? Since we have an option
> of using different VirtIDs for LP and HP traffic, why not use it? Is
> there going to be an issue with using VirtID 0 for LP traffic and VirtID 1
> for HP traffic?
>
>> + err = ks_init_vmap(pdev, "vmap_lp");
>> + if (err)
>> + return err;
>> + err = ks_init_vmap(pdev, "vmap_hp");
>> + if (err)
>> + return err;
>> +
>> + /*
>> + * Enforce DMA pool usage with the help of the PVU.
>> + * Any request outside will be dropped and raise an error at the PVU.
>> + */
>> + return ti_pvu_create_region(KS_PCI_VIRTID, &phys);
>
> Same as above, we are passing a single VIRTID and not an array, so it
> isn't clear to me as to how it will be extended in the future.
>
>> +}
>> +
>> +static void ks_release_restricted_dma(struct platform_device *pdev)
>> +{
>> + struct of_phandle_iterator it;
>> + struct resource phys;
>> + int err;
>> +
>> + if (!IS_ENABLED(CONFIG_TI_PVU))
>> + return;
>> +
>> + of_for_each_phandle(&it, err, pdev->dev.of_node, "memory-region",
>> + NULL, 0) {
>> + if (of_device_is_compatible(it.node, "restricted-dma-pool") &&
>> + of_address_to_resource(it.node, 0, &phys) == 0) {
>> + ti_pvu_remove_region(KS_PCI_VIRTID, &phys);
>> + break;
>> + }
>> + }
>> +}
>> +
>> static int ks_pcie_probe(struct platform_device *pdev)
>> {
>> const struct dw_pcie_host_ops *host_ops;
>> @@ -1285,6 +1385,10 @@ static int ks_pcie_probe(struct platform_device *pdev)
>> if (ret < 0)
>> goto err_get_sync;
>>
>> + ret = ks_init_restricted_dma(pdev);
>> + if (ret < 0)
>> + goto err_get_sync;
>> +
>
> Shouldn't the above be moved into the case for "DW_PCIE_RC_TYPE" below? Or
> is this valid even when the SoC is configured to act as an Endpoint?
Fair remark. We currently have no setup for EP usage thus cannot even
say if it would make sense / would work as intended in that case as
well. Probably better to move then.
Jan
>
>> switch (mode) {
>> case DW_PCIE_RC_TYPE:
>> if (!IS_ENABLED(CONFIG_PCI_KEYSTONE_HOST)) {
>> @@ -1366,6 +1470,8 @@ static void ks_pcie_remove(struct platform_device *pdev)
>> int num_lanes = ks_pcie->num_lanes;
>> struct device *dev = &pdev->dev;
>>
>> + ks_release_restricted_dma(pdev);
>> +
>> pm_runtime_put(dev);
>> pm_runtime_disable(dev);
>> ks_pcie_disable_phy(ks_pcie);
>
> Regards,
> Siddharth.
--
Siemens AG, Foundational Technologies
Linux Expert Center
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v8 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654
2025-07-15 8:55 ` Jan Kiszka
@ 2025-07-15 9:15 ` Siddharth Vadapalli
2025-07-16 5:10 ` [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation huaqian.li
2025-07-16 5:39 ` [PATCH v9 (RESEND) 0/7] " huaqian.li
0 siblings, 2 replies; 58+ messages in thread
From: Siddharth Vadapalli @ 2025-07-15 9:15 UTC (permalink / raw)
To: Jan Kiszka
Cc: Siddharth Vadapalli, huaqian.li, helgaas, baocheng.su, bhelgaas,
conor+dt, devicetree, diogo.ivo, kristo, krzk+dt, kw,
linux-arm-kernel, linux-kernel, linux-pci, lpieralisi, nm, robh,
ssantosh, vigneshr
On Tue, Jul 15, 2025 at 10:55:19AM +0200, Jan Kiszka wrote:
Hello Jan,
> On 25.04.25 18:48, Siddharth Vadapalli wrote:
> > On Tue, Apr 22, 2025 at 02:14:03PM +0800, huaqian.li@siemens.com wrote:
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>
> >> The AM654 lacks an IOMMU, thus does not support isolating DMA requests
> >> from untrusted PCI devices to selected memory regions this way. Use
> >> static PVU-based protection instead. The PVU, when enabled, will only
> >> accept DMA requests that address previously configured regions.
> >>
> >> Use the availability of a restricted-dma-pool memory region as trigger
> >> and register it as valid DMA target with the PVU. In addition, enable
> >> the mapping of requester IDs to VirtIDs in the PCI RC. Use only a single
> >> VirtID so far, catching all devices. This may be extended later on.
> >>
> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> >> Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
> >> ---
> >> drivers/pci/controller/dwc/pci-keystone.c | 106 ++++++++++++++++++++++
> >> 1 file changed, 106 insertions(+)
> >>
> >> diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
> >> index 76a37368ae4f..ea2d8768e333 100644
> >> --- a/drivers/pci/controller/dwc/pci-keystone.c
> >> +++ b/drivers/pci/controller/dwc/pci-keystone.c
> >> @@ -19,6 +19,7 @@
> >> #include <linux/mfd/syscon.h>
> >> #include <linux/msi.h>
> >> #include <linux/of.h>
> >> +#include <linux/of_address.h>
> >> #include <linux/of_irq.h>
> >> #include <linux/of_pci.h>
> >> #include <linux/phy/phy.h>
> >> @@ -26,6 +27,7 @@
> >> #include <linux/regmap.h>
> >> #include <linux/resource.h>
> >> #include <linux/signal.h>
> >> +#include <linux/ti-pvu.h>
> >>
> >> #include "../../pci.h"
> >> #include "pcie-designware.h"
> >> @@ -111,6 +113,16 @@
> >>
> >> #define PCI_DEVICE_ID_TI_AM654X 0xb00c
> >>
> >> +#define KS_PCI_VIRTID 0
> >> +
> >> +#define PCIE_VMAP_xP_CTRL 0x0
> >> +#define PCIE_VMAP_xP_REQID 0x4
> >> +#define PCIE_VMAP_xP_VIRTID 0x8
> >> +
> >> +#define PCIE_VMAP_xP_CTRL_EN BIT(0)
> >> +
> >> +#define PCIE_VMAP_xP_VIRTID_VID_MASK 0xfff
> >> +
> >> struct ks_pcie_of_data {
> >> enum dw_pcie_device_mode mode;
> >> const struct dw_pcie_host_ops *host_ops;
> >> @@ -1137,6 +1149,94 @@ static const struct of_device_id ks_pcie_of_match[] = {
> >> { },
> >> };
> >>
> >> +static int ks_init_vmap(struct platform_device *pdev, const char *vmap_name)
> >> +{
> >> + struct resource *res;
> >> + void __iomem *base;
> >> + u32 val;
> >> +
> >> + if (!IS_ENABLED(CONFIG_TI_PVU))
> >> + return 0;
> >> +
> >> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, vmap_name);
> >> + base = devm_pci_remap_cfg_resource(&pdev->dev, res);
> >> + if (IS_ERR(base))
> >> + return PTR_ERR(base);
> >> +
> >> + writel(0, base + PCIE_VMAP_xP_REQID);
> >> +
> >> + val = readl(base + PCIE_VMAP_xP_VIRTID);
> >> + val &= ~PCIE_VMAP_xP_VIRTID_VID_MASK;
> >> + val |= KS_PCI_VIRTID;
> >
> > While it has been stated that we are going to start off with a single
> > VirtID for now and extend it later on, is there an example for how it may
> > be extended? The only option I see is that of associating one VirtID for
> > Low-Priority (LP) traffic and another for High-Priority (HP) traffic, in
> > which case, it might be better to define them upfront and use them like:
> > #define KS_PCI_LP_VIRTID 0
> > #define KS_PCI_HP_VIRTID 1
>
> Sorry for the late reply, was just reminded of this question:
>
> When trying to design anything beyond the current use case, I would be
> struggling right now with the how, simply because we would have no user
> of extended APIs around to make sure that the result would be useful.
> Can you envision such use cases? If not, I would rather suggest to
> postpone any attempts to broaden the API until we have such users.
I understand that it might not be possible to extend it (or at-least it
doesn't seem to be straightforward), in which case, we could state the
same in commit message. I had asked for an example of extending it
because the commit message states:
....Use only a single VirtID so far, catching all devices.
This may be extended later on.
without explaining how it could be extended later on. To be precise, my
question was aimed at whether or not the current implementation allows
it to be extended in the future (maintaining backward compatibility). If
that's not yet known, it might be better to state that in the commit
message, or omit the portion which states that it may be extended later on.
-----8<---rest of the email has been trimmed-----8<---------------------
Regards,
Siddharth.
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation
2025-07-15 9:15 ` Siddharth Vadapalli
@ 2025-07-16 5:10 ` huaqian.li
2025-07-16 5:10 ` [PATCH v9 1/7] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit huaqian.li
` (7 more replies)
2025-07-16 5:39 ` [PATCH v9 (RESEND) 0/7] " huaqian.li
1 sibling, 8 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:10 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr
From: Li Hua Qian <huaqian.li@siemens.com>
Changes in v8:
- remove patch 8 from this series to simplify the patchset
- fix dt_bindings_check warnings (patch 2), 'memory-region' must
not be a required property
Changes in v7:
- add schema expressing dependency as suggested on pci-host bindings
- resolve review comments on pci-keystone driver
- add a new patch to make IO_TLB_SEGSIZE configurable
- improve patches based on checkpath.pl
Changes in v6:
- make restricted DMA memory-region available to all pci-keystone
devices, moving property to unconditional section (patch 2)
Changes in v5:
- resolve review comments on pci-host bindings
- reduce DMA memory regions to 1 - swiotlb does not support more
- move activation into overlay (controlled via firmware)
- use ks_init_vmap helper instead of loop in
rework ks_init_restricted_dma
- add more comments to pci-keystone
- use 2 chained TLBs of PVU to support maximum of swiotlb (320 MB)
Changes in v4:
- reorder patch queue, moving all DTS changes to the back
- limit activation to IOT2050 Advanced variants
- move DMA pool to allow firmware-based expansion it up to 512M
Changes in v3:
- fix ti,am654-pvu.yaml according to review comments
- address review comments on ti,am65-pci-host.yaml
- differentiate between different compatibles in ti,am65-pci-host.yaml
- move pvu nodes to k3-am65-main.dtsi
- reorder patch series, pulling bindings and generic DT bits to the front
Changes in v2:
- fix dt_bindings_check issues (patch 1)
- address first review comments (patch 2)
- extend ti,am65-pci-host bindings for PVU (new patch 3)
Only few of the K3 SoCs have an IOMMU and, thus, can isolate the system
against DMA-based attacks of external PCI devices. The AM65 is without
an IOMMU, but it comes with something close to it: the Peripheral
Virtualization Unit (PVU).
The PVU was originally designed to establish static compartments via a
hypervisor, isolate those DMA-wise against each other and the host and
even allow remapping of guest-physical addresses. But it only provides
a static translation region, not page-granular mappings. Thus, it cannot
be handled transparently like an IOMMU.
Now, to use the PVU for the purpose of isolated PCI devices from the
Linux host, this series takes a different approach. It defines a
restricted-dma-pool for the PCI host, using swiotlb to map all DMA
buffers from a static memory carve-out. And to enforce that the devices
actually follow this, a special PVU soc driver is introduced. The driver
permits access to the GIC ITS and otherwise waits for other drivers that
detect devices with constrained DMA to register pools with the PVU.
For the AM65, the first (and possibly only) driver where this is
introduced is the pci-keystone host controller. Finally, this series
provides a DT overlay for the IOT2050 Advanced devices (all have
MiniPCIe or M.2 extension slots) to make use of this protection scheme.
Application of this overlay will be handled by firmware.
Due to the cross-cutting nature of these changes, multiple subsystems
are affected. However, I wanted to present the whole thing in one series
to allow everyone to review with the complete picture in hands. If
preferred, I can also split the series up, of course.
Jan
Jan Kiszka (7):
dt-bindings: soc: ti: Add AM65 peripheral virtualization unit
dt-bindings: PCI: ti,am65: Extend for use with PVU
soc: ti: Add IOMMU-like PVU driver
PCI: keystone: Add support for PVU-based DMA isolation on AM654
arm64: dts: ti: k3-am65-main: Add PVU nodes
arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes
arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices
behind PCI RC
.../bindings/pci/ti,am65-pci-host.yaml | 28 +-
.../bindings/soc/ti/ti,am654-pvu.yaml | 51 ++
arch/arm64/boot/dts/ti/Makefile | 5 +
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 38 +-
...am6548-iot2050-advanced-dma-isolation.dtso | 33 ++
drivers/pci/controller/dwc/pci-keystone.c | 106 ++++
drivers/soc/ti/Kconfig | 4 +
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti-pvu.c | 500 ++++++++++++++++++
include/linux/ti-pvu.h | 32 ++
10 files changed, 791 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
create mode 100644 drivers/soc/ti/ti-pvu.c
create mode 100644 include/linux/ti-pvu.h
--
2.34.1
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH v9 1/7] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit
2025-07-16 5:10 ` [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation huaqian.li
@ 2025-07-16 5:10 ` huaqian.li
2025-07-16 5:10 ` [PATCH v9 2/7] dt-bindings: PCI: ti,am65: Extend for use with PVU huaqian.li
` (6 subsequent siblings)
7 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:10 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr,
Krzysztof Kozlowski
From: Jan Kiszka <jan.kiszka@siemens.com>
The PVU allows to define a limited set of mappings for incoming DMA
requests to the system memory. It is not a real IOMMU, thus hooked up
under the TI SoC bindings.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
.../bindings/soc/ti/ti,am654-pvu.yaml | 51 +++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml b/Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
new file mode 100644
index 000000000000..e4a5fc47d674
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) Siemens AG, 2024
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/ti/ti,am654-pvu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI AM654 Peripheral Virtualization Unit
+
+maintainers:
+ - Jan Kiszka <jan.kiszka@siemens.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,am654-pvu
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: cfg
+ - const: tlbif
+
+ interrupts:
+ items:
+ - description: fault interrupt
+
+ interrupt-names:
+ items:
+ - const: pvu
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+ iommu@30f80000 {
+ compatible = "ti,am654-pvu";
+ reg = <0x30f80000 0x1000>,
+ <0x36000000 0x100000>;
+ reg-names = "cfg", "tlbif";
+ interrupts-extended = <&intr_main_navss 390>;
+ interrupt-names = "pvu";
+ };
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v9 2/7] dt-bindings: PCI: ti,am65: Extend for use with PVU
2025-07-16 5:10 ` [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation huaqian.li
2025-07-16 5:10 ` [PATCH v9 1/7] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit huaqian.li
@ 2025-07-16 5:10 ` huaqian.li
2025-07-16 5:10 ` [PATCH v9 3/7] soc: ti: Add IOMMU-like PVU driver huaqian.li
` (5 subsequent siblings)
7 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:10 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr,
Krzysztof Kozlowski
From: Jan Kiszka <jan.kiszka@siemens.com>
The PVU on the AM65 SoC is capable of restricting DMA from PCIe devices
to specific regions of host memory. Add the optional property
"memory-regions" to point to such regions of memory when PVU is used.
Since the PVU deals with system physical addresses, utilizing the PVU
with PCIe devices also requires setting up the VMAP registers to map the
Requester ID of the PCIe device to the CBA Virtual ID, which in turn is
mapped to the system physical address. Hence, describe the VMAP
registers which are optional unless the PVU shall be used for PCIe.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
.../bindings/pci/ti,am65-pci-host.yaml | 28 +++++++++++++++++--
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
index 0a9d10532cc8..98f6c7f1b1a6 100644
--- a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
@@ -20,14 +20,18 @@ properties:
- ti,keystone-pcie
reg:
- maxItems: 4
+ minItems: 4
+ maxItems: 6
reg-names:
+ minItems: 4
items:
- const: app
- const: dbics
- const: config
- const: atu
+ - const: vmap_lp
+ - const: vmap_hp
interrupts:
maxItems: 1
@@ -69,6 +73,15 @@ properties:
items:
pattern: '^pcie-phy[0-1]$'
+ memory-region:
+ maxItems: 1
+ description: |
+ phandle to a restricted DMA pool to be used for all devices behind
+ this controller. The regions should be defined according to
+ reserved-memory/shared-dma-pool.yaml.
+ Note that enforcement via the PVU will only be available to
+ ti,am654-pcie-rc devices.
+
required:
- compatible
- reg
@@ -89,6 +102,13 @@ then:
- power-domains
- msi-map
- num-viewport
+else:
+ properties:
+ reg:
+ maxItems: 4
+
+ reg-names:
+ maxItems: 4
unevaluatedProperties: false
@@ -104,8 +124,10 @@ examples:
reg = <0x5500000 0x1000>,
<0x5501000 0x1000>,
<0x10000000 0x2000>,
- <0x5506000 0x1000>;
- reg-names = "app", "dbics", "config", "atu";
+ <0x5506000 0x1000>,
+ <0x2900000 0x1000>,
+ <0x2908000 0x1000>;
+ reg-names = "app", "dbics", "config", "atu", "vmap_lp", "vmap_hp";
power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <3>;
#size-cells = <2>;
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v9 3/7] soc: ti: Add IOMMU-like PVU driver
2025-07-16 5:10 ` [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation huaqian.li
2025-07-16 5:10 ` [PATCH v9 1/7] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit huaqian.li
2025-07-16 5:10 ` [PATCH v9 2/7] dt-bindings: PCI: ti,am65: Extend for use with PVU huaqian.li
@ 2025-07-16 5:10 ` huaqian.li
2025-07-16 5:10 ` [PATCH v9 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654 huaqian.li
` (4 subsequent siblings)
7 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:10 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
The TI Peripheral Virtualization Unit (PVU) permits to define a limited
set of mappings for DMA requests on the system memory. Unlike with an
IOMMU, there is no fallback to a memory-backed page table, only a fixed
set of register-backed TLBs. Emulating an IOMMU behavior appears to be
the more fragile the more fragmentation of pending requests occur.
Therefore, this driver does not expose the PVU as an IOMMU. It rather
introduces a simple, static interface to devices that are under
restricted-dma-pool constraints. They can register their pools with the
PVUs, enabling only those pools to work for DMA. As also MSI is issued
as DMA, the PVU already register the related translator region of the
AM654 as valid DMA target.
This driver is the essential building block for limiting DMA from
untrusted devices to clearly defined memory regions in the absence of a
real IOMMU (SMMU).
Co-developed-by: Diogo Ivo <diogo.ivo@siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
drivers/soc/ti/Kconfig | 4 +
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti-pvu.c | 500 ++++++++++++++++++++++++++++++++++++++++
include/linux/ti-pvu.h | 32 +++
4 files changed, 537 insertions(+)
create mode 100644 drivers/soc/ti/ti-pvu.c
create mode 100644 include/linux/ti-pvu.h
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 1a93001c9e36..af7173ad84de 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -82,6 +82,10 @@ config TI_PRUSS
processors on various TI SoCs. It's safe to say N here if you're
not interested in the PRU or if you are unsure.
+config TI_PVU
+ bool "TI Peripheral Virtualization Unit driver"
+ depends on ARCH_K3 && DMA_RESTRICTED_POOL
+
endif # SOC_TI
config TI_SCI_INTA_MSI_DOMAIN
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index cb800a745e66..ecff3fd8c433 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_TI_K3_RINGACC) += k3-ringacc.o
obj-$(CONFIG_TI_K3_SOCINFO) += k3-socinfo.o
obj-$(CONFIG_TI_PRUSS) += pruss.o
obj-$(CONFIG_POWER_AVS_OMAP) += smartreflex.o
+obj-$(CONFIG_TI_PVU) += ti-pvu.o
diff --git a/drivers/soc/ti/ti-pvu.c b/drivers/soc/ti/ti-pvu.c
new file mode 100644
index 000000000000..38996c74cce7
--- /dev/null
+++ b/drivers/soc/ti/ti-pvu.c
@@ -0,0 +1,500 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI Peripheral Virtualization Unit driver for static DMA isolation
+ *
+ * Copyright (c) 2024, Siemens AG
+ */
+
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/ti-pvu.h>
+
+#define PVU_CONFIG 0x4
+#define PVU_ENABLE 0x10
+#define PVU_VIRTID_MAP1 0x14
+#define PVU_VIRTID_MAP2 0x18
+#define PVU_EXCEPTION_LOGGING_CONTROL 0x120
+#define PVU_EXCEPTION_LOGGING_HEADER0 0x124
+#define PVU_EXCEPTION_LOGGING_HEADER1 0x128
+#define PVU_EXCEPTION_LOGGING_DATA0 0x12c
+#define PVU_EXCEPTION_LOGGING_DATA1 0x130
+#define PVU_EXCEPTION_LOGGING_DATA2 0x134
+#define PVU_EXCEPTION_LOGGING_DATA2_SECURE BIT(0)
+#define PVU_EXCEPTION_LOGGING_DATA2_PRIV BIT(1)
+#define PVU_EXCEPTION_LOGGING_DATA2_CACHEABLE BIT(2)
+#define PVU_EXCEPTION_LOGGING_DATA2_DEBUG BIT(3)
+#define PVU_EXCEPTION_LOGGING_DATA2_READ BIT(4)
+#define PVU_EXCEPTION_LOGGING_DATA2_WRITE BIT(5)
+#define PVU_EXCEPTION_LOGGING_DATA3 0x138
+#define PVU_EXCEPTION_ENABLE_SET 0x148
+#define PVU_EOI_REG 0x150
+
+#define PVU_CHAIN 0x0
+#define PVU_CHAIN_EN BIT(31)
+#define PVU_CHAIN_LOG_DIS BIT(30)
+#define PVU_CHAIN_FAULT BIT(29)
+#define PVU_CHAIN_MASK 0xfff
+#define PVU_ENTRY0 0x20
+#define PVU_ENTRY1 0x24
+#define PVU_ENTRY1_RESERVED_MASK 0xffff0000
+#define PVU_ENTRY1_VBASE_H_MASK 0xffff
+#define PVU_ENTRY2 0x28
+#define PVU_ENTRY2_RESERVED_MASK 0x1fd00080
+#define PVU_ENTRY2_INVALID (0U << 30)
+#define PVU_ENTRY2_VALID (2U << 30)
+#define PVU_ENTRY2_MODE_MASK 0xc0000000
+#define PVU_ENTRY2_PSIZE_SHIFT 16
+#define PVU_ENTRY2_PSIZE_MASK 0xf
+#define PVU_ENTRY2_PERM_SX BIT(15)
+#define PVU_ENTRY2_PERM_SW BIT(14)
+#define PVU_ENTRY2_PERM_SR BIT(13)
+#define PVU_ENTRY2_PERM_UX BIT(12)
+#define PVU_ENTRY2_PERM_UW BIT(11)
+#define PVU_ENTRY2_PERM_UR BIT(10)
+#define PVU_ENTRY2_MEM_WRITETHROUGH (2 << 8)
+#define PVU_ENTRY2_OUTER_SHARABLE BIT(4)
+#define PVU_ENTRY2_IS_NOALLOC (0 << 2)
+#define PVU_ENTRY2_OS_NOALLOC (0 << 0)
+#define PVU_ENTRY4 0x30
+#define PVU_ENTRY5 0x34
+#define PVU_ENTRY5_RESERVED_MASK 0xffff0000
+#define PVU_ENTRY5_PBASE_H_MASK 0xffff
+#define PVU_ENTRY6 0x38
+#define PVU_ENTRY6_RESERVED_MASK 0xffffffe0
+
+#define NUM_VIRTIDS 1
+
+static const struct regmap_config pvu_cfg_regmap_cfg = {
+ .name = "pvu-cfg",
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = PVU_EOI_REG,
+};
+
+enum pvu_cfg_regfields {
+ PVU_TLBS,
+ PVU_TLB_ENTRIES,
+ PVU_ENABLED,
+ PVU_DMA_CNT,
+ PVU_DMA_CL0,
+ PVU_DMA_CL1,
+ PVU_DMA_CL2,
+ PVU_DMA_CL3,
+ PVU_MAX_VIRTID,
+ PVU_EXC_SRC_ID,
+ PVU_EXC_CODE,
+ PVU_EXC_ADDR_L,
+ PVU_EXC_ADDR_H,
+ PVU_EXC_PRIV_ID,
+ PVU_EXC_PROPS,
+ PVU_EXC_ROUTE_ID,
+ PVU_EXC_BYTE_CNT,
+ PVU_EXC_ENABLE,
+ PVU_EOI,
+ PVU_MAX_CFG_FIELDS,
+};
+
+static const struct reg_field pvu_cfg_reg_fields[] = {
+ [PVU_TLBS] = REG_FIELD(PVU_CONFIG, 0, 15),
+ [PVU_TLB_ENTRIES] = REG_FIELD(PVU_CONFIG, 16, 23),
+ [PVU_ENABLED] = REG_FIELD(PVU_ENABLE, 0, 0),
+ [PVU_DMA_CNT] = REG_FIELD(PVU_VIRTID_MAP1, 0, 11),
+ [PVU_DMA_CL0] = REG_FIELD(PVU_VIRTID_MAP1, 16, 17),
+ [PVU_DMA_CL1] = REG_FIELD(PVU_VIRTID_MAP1, 18, 19),
+ [PVU_DMA_CL2] = REG_FIELD(PVU_VIRTID_MAP1, 20, 21),
+ [PVU_DMA_CL3] = REG_FIELD(PVU_VIRTID_MAP1, 22, 23),
+ [PVU_MAX_VIRTID] = REG_FIELD(PVU_VIRTID_MAP2, 0, 11),
+ [PVU_EXC_SRC_ID] = REG_FIELD(PVU_EXCEPTION_LOGGING_HEADER0, 8, 23),
+ [PVU_EXC_CODE] = REG_FIELD(PVU_EXCEPTION_LOGGING_HEADER1, 16, 23),
+ [PVU_EXC_ADDR_L] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA0, 0, 31),
+ [PVU_EXC_ADDR_H] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA1, 0, 15),
+ [PVU_EXC_PRIV_ID] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA2, 0, 7),
+ [PVU_EXC_PROPS] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA2, 8, 13),
+ [PVU_EXC_ROUTE_ID] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA2, 16, 27),
+ [PVU_EXC_BYTE_CNT] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA3, 0, 9),
+ [PVU_EXC_ENABLE] = REG_FIELD(PVU_EXCEPTION_ENABLE_SET, 0, 0),
+ [PVU_EOI] = REG_FIELD(PVU_EOI_REG, 0, 15),
+};
+
+struct ti_pvu {
+ struct list_head entry;
+ struct platform_device *pdev;
+ struct regmap *cfg;
+ struct regmap_field *cfg_fields[PVU_MAX_CFG_FIELDS];
+ void __iomem *tlbif_base;
+ unsigned int num_tlbs;
+ unsigned int num_entries;
+};
+
+static const char *pvu_excp_code_string[] = {
+ "PVU miss",
+ "maximum VirtID violation",
+ "<reserved>",
+ "read permission violation",
+ "write permission violation",
+ "execute permission violation",
+ "prefetch permission violation",
+ "<unknown>",
+};
+
+static const u64 pvu_page_size[] = {
+ 4 * 1024ULL,
+ 16 * 1024ULL,
+ 64 * 1024ULL,
+ 2 * 1024 * 1024ULL,
+ 32 * 1024 * 1024ULL,
+ 512 * 1024 * 1024ULL,
+ 1 * 1024 * 1024 * 1024ULL,
+ 16 * 1024 * 1024 * 1024ULL
+};
+
+static DEFINE_MUTEX(ti_pvu_lock);
+static LIST_HEAD(ti_pvu_list);
+
+static unsigned int pvu_field_read(struct ti_pvu *pvu, enum pvu_cfg_regfields f)
+{
+ int ret;
+ unsigned int val;
+
+ ret = regmap_field_read(pvu->cfg_fields[f], &val);
+ if (ret)
+ dev_err(&pvu->pdev->dev, "failed to read field\n");
+
+ return val;
+}
+
+static void pvu_field_write(struct ti_pvu *pvu, enum pvu_cfg_regfields f,
+ unsigned int val)
+{
+ int ret;
+
+ ret = regmap_field_write(pvu->cfg_fields[f], val);
+ if (ret)
+ dev_err(&pvu->pdev->dev, "failed to write field\n");
+}
+
+static irqreturn_t pvu_fault_isr(int irq, void *dev_id)
+{
+ u32 code, bytes, route_id, priv_id, props;
+ struct ti_pvu *pvu = dev_id;
+ const char *code_str;
+ u64 address;
+
+ code = pvu_field_read(pvu, PVU_EXC_CODE);
+ code_str = pvu_excp_code_string[
+ min(code, (u32)ARRAY_SIZE(pvu_excp_code_string) - 1)];
+
+ dev_err(&pvu->pdev->dev, "fault detected, code %d (%s)\n",
+ code, code_str);
+
+ address = pvu_field_read(pvu, PVU_EXC_ADDR_L);
+ address |= (u64)pvu_field_read(pvu, PVU_EXC_ADDR_H) << 32;
+
+ bytes = pvu_field_read(pvu, PVU_EXC_BYTE_CNT);
+
+ route_id = pvu_field_read(pvu, PVU_EXC_ROUTE_ID);
+ priv_id = pvu_field_read(pvu, PVU_EXC_PRIV_ID);
+ props = pvu_field_read(pvu, PVU_EXC_PROPS);
+
+ dev_err(&pvu->pdev->dev,
+ " address 0x%016llx size %d route-ID %d priv-ID %d flags %c%c%c%c%c%c\n",
+ address, bytes, route_id, priv_id,
+ (props & PVU_EXCEPTION_LOGGING_DATA2_WRITE) ? 'W' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_READ) ? 'R' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_DEBUG) ? 'D' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_CACHEABLE) ? 'C' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_PRIV) ? 'P' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_SECURE) ? 'S' : '-');
+
+ pvu_field_write(pvu, PVU_EOI, 0);
+
+ return IRQ_HANDLED;
+}
+
+static void __iomem *pvu_get_entry_base(struct ti_pvu *pvu, unsigned int entry)
+{
+ return pvu->tlbif_base + (entry / pvu->num_entries) * 0x1000 +
+ (entry % pvu->num_entries) * 0x20;
+}
+
+static int pvu_get_free_entry(struct ti_pvu *pvu)
+{
+ unsigned int n;
+ u32 val;
+
+ /* We use up to 2 TLBs via chainging */
+ for (n = 0; n < pvu->num_entries * 2; n++) {
+ val = readl(pvu_get_entry_base(pvu, n) + PVU_ENTRY2);
+ if ((val & PVU_ENTRY2_MODE_MASK) == PVU_ENTRY2_INVALID)
+ return n;
+ }
+ return -ENOSPC;
+}
+
+static void pvu_write_entry(struct ti_pvu *pvu, unsigned int entry,
+ u64 addr, u32 psize)
+{
+ void __iomem *entry_base = pvu_get_entry_base(pvu, entry);
+ u32 val;
+
+ writel((u32)addr, entry_base + PVU_ENTRY0);
+
+ val = readl(entry_base + PVU_ENTRY1);
+ val &= PVU_ENTRY1_RESERVED_MASK;
+ val |= (addr >> 32) & PVU_ENTRY1_VBASE_H_MASK;
+ writel(val, entry_base + PVU_ENTRY1);
+
+ writel((u32)addr, entry_base + PVU_ENTRY4);
+
+ val = readl(entry_base + PVU_ENTRY5);
+ val &= PVU_ENTRY5_RESERVED_MASK;
+ val |= (addr >> 32) & PVU_ENTRY5_PBASE_H_MASK;
+ writel(val, entry_base + PVU_ENTRY5);
+
+ val = readl(entry_base + PVU_ENTRY6);
+ val &= PVU_ENTRY6_RESERVED_MASK;
+ writel(val, entry_base + PVU_ENTRY6);
+
+ val = readl(entry_base + PVU_ENTRY2);
+ val &= PVU_ENTRY2_RESERVED_MASK;
+ val |= psize << PVU_ENTRY2_PSIZE_SHIFT;
+ val |= PVU_ENTRY2_VALID |
+ PVU_ENTRY2_PERM_UR | PVU_ENTRY2_PERM_SR |
+ PVU_ENTRY2_PERM_UW | PVU_ENTRY2_PERM_SW |
+ PVU_ENTRY2_PERM_UX | PVU_ENTRY2_PERM_SX |
+ PVU_ENTRY2_MEM_WRITETHROUGH | PVU_ENTRY2_OUTER_SHARABLE |
+ PVU_ENTRY2_IS_NOALLOC | PVU_ENTRY2_OS_NOALLOC;
+ writel(val, entry_base + PVU_ENTRY2);
+}
+
+static int pvu_create_region(struct ti_pvu *pvu, u64 addr, u64 size)
+{
+ u64 page_size;
+ int psize;
+ int entry;
+
+ while (size > 0) {
+ entry = pvu_get_free_entry(pvu);
+ if (entry < 0) {
+ dev_err(&pvu->pdev->dev, "ran out of TLB entries\n");
+ return -ENOSPC;
+ }
+
+ for (psize = ARRAY_SIZE(pvu_page_size) - 1; psize >= 0; psize--) {
+ page_size = pvu_page_size[psize];
+ if (size >= page_size && (addr & (page_size - 1)) == 0)
+ break;
+ }
+ if (psize < 0) {
+ dev_err(&pvu->pdev->dev, "unaligned region provided\n");
+ return -EINVAL;
+ }
+
+ pvu_write_entry(pvu, entry, addr, psize);
+ dev_info(&pvu->pdev->dev,
+ "created TLB entry %d.%d: 0x%08llx, psize %d (0x%08llx)\n",
+ entry / pvu->num_entries, entry % pvu->num_entries,
+ addr, psize, page_size);
+
+ size -= page_size;
+ addr += page_size;
+ }
+
+ return 0;
+}
+
+static void pvu_remove_region(struct ti_pvu *pvu, u64 addr, u64 size)
+{
+ void __iomem *entry_base;
+ unsigned int n, psize;
+ u64 entry_addr;
+ u32 entry2;
+
+ for (n = 0; n < pvu->num_entries * 2; n++) {
+ entry_base = pvu_get_entry_base(pvu, n);
+ entry2 = readl(entry_base + PVU_ENTRY2);
+ if ((entry2 & PVU_ENTRY2_MODE_MASK) != PVU_ENTRY2_VALID)
+ continue;
+
+ entry_addr = readl(entry_base + PVU_ENTRY0);
+ entry_addr |= (u64)(readl(entry_base + PVU_ENTRY1) &
+ PVU_ENTRY1_VBASE_H_MASK) << 32;
+
+ psize = (entry2 >> PVU_ENTRY2_PSIZE_SHIFT) &
+ PVU_ENTRY2_PSIZE_MASK;
+ if (psize >= ARRAY_SIZE(pvu_page_size))
+ continue;
+
+ if (entry_addr >= addr &&
+ (entry_addr + pvu_page_size[psize]) <= (addr + size)) {
+ entry2 &= ~PVU_ENTRY2_MODE_MASK;
+ entry2 |= PVU_ENTRY2_INVALID;
+ writel(entry2, entry_base + PVU_ENTRY2);
+
+ dev_info(&pvu->pdev->dev, "removed TLB entry %d.%d\n",
+ n / pvu->num_entries, n % pvu->num_entries);
+ }
+ }
+}
+
+int ti_pvu_create_region(unsigned int virt_id, const struct resource *region)
+{
+ struct ti_pvu *pvu;
+ int err = 0;
+
+ if (virt_id >= NUM_VIRTIDS)
+ return -EINVAL;
+
+ mutex_lock(&ti_pvu_lock);
+
+ list_for_each_entry(pvu, &ti_pvu_list, entry) {
+ err = pvu_create_region(pvu, region->start,
+ region->end + 1 - region->start);
+ if (err)
+ break;
+ }
+
+ mutex_unlock(&ti_pvu_lock);
+
+ return err;
+}
+
+int ti_pvu_remove_region(unsigned int virt_id, const struct resource *region)
+{
+ struct ti_pvu *pvu;
+
+ if (virt_id >= NUM_VIRTIDS)
+ return -EINVAL;
+
+ mutex_lock(&ti_pvu_lock);
+
+ list_for_each_entry(pvu, &ti_pvu_list, entry) {
+ pvu_remove_region(pvu, region->start,
+ region->end + 1 - region->start);
+ }
+
+ mutex_unlock(&ti_pvu_lock);
+
+ return 0;
+}
+
+static int ti_pvu_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *its_node;
+ void __iomem *base;
+ struct ti_pvu *pvu;
+ u32 val;
+ int ret;
+
+ pvu = devm_kzalloc(dev, sizeof(*pvu), GFP_KERNEL);
+ if (!pvu)
+ return -ENOMEM;
+
+ pvu->pdev = pdev;
+
+ base = devm_platform_ioremap_resource_byname(pdev, "cfg");
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ pvu->cfg = devm_regmap_init_mmio(dev, base, &pvu_cfg_regmap_cfg);
+ if (IS_ERR(pvu->cfg))
+ return dev_err_probe(dev, PTR_ERR(pvu->cfg), "failed to init cfg regmap");
+
+ ret = devm_regmap_field_bulk_alloc(dev, pvu->cfg, pvu->cfg_fields,
+ pvu_cfg_reg_fields, PVU_MAX_CFG_FIELDS);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to alloc cfg regmap fields");
+
+ pvu->num_tlbs = pvu_field_read(pvu, PVU_TLBS);
+ pvu->num_entries = pvu_field_read(pvu, PVU_TLB_ENTRIES);
+ dev_info(dev, "TLBs: %d, entries per TLB: %d\n", pvu->num_tlbs,
+ pvu->num_entries);
+
+ pvu->tlbif_base = devm_platform_ioremap_resource_byname(pdev, "tlbif");
+ if (IS_ERR(pvu->tlbif_base))
+ return PTR_ERR(pvu->tlbif_base);
+
+ its_node = of_find_compatible_node(0, 0, "arm,gic-v3-its");
+ if (its_node) {
+ u32 pre_its_window[2];
+
+ ret = of_property_read_u32_array(its_node,
+ "socionext,synquacer-pre-its",
+ pre_its_window,
+ ARRAY_SIZE(pre_its_window));
+ if (ret) {
+ dev_err(dev, "failed to read pre-its property\n");
+ return ret;
+ }
+
+ ret = pvu_create_region(pvu, pre_its_window[0],
+ pre_its_window[1]);
+ if (ret)
+ return ret;
+ }
+
+ /* Enable the first two TLBs, chaining from 0 to 1 */
+ val = readl(pvu->tlbif_base + PVU_CHAIN);
+ val |= PVU_CHAIN_EN | 1;
+ writel(val, pvu->tlbif_base + PVU_CHAIN);
+
+ val = readl(pvu->tlbif_base + PVU_CHAIN + 0x1000);
+ val |= PVU_CHAIN_EN;
+ writel(val, pvu->tlbif_base + PVU_CHAIN + 0x1000);
+
+ pvu_field_write(pvu, PVU_DMA_CNT, 0);
+ pvu_field_write(pvu, PVU_DMA_CL0, 0);
+ pvu_field_write(pvu, PVU_DMA_CL1, 0);
+ pvu_field_write(pvu, PVU_DMA_CL2, 0);
+ pvu_field_write(pvu, PVU_DMA_CL3, 0);
+ pvu_field_write(pvu, PVU_MAX_VIRTID, NUM_VIRTIDS);
+
+ ret = platform_get_irq(pdev, 0);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to get irq\n");
+
+ ret = devm_request_irq(dev, ret, pvu_fault_isr, 0, dev_name(dev), pvu);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to request irq\n");
+
+ pvu_field_write(pvu, PVU_EXC_ENABLE, 1);
+ pvu_field_write(pvu, PVU_ENABLED, 1);
+
+ dev_set_drvdata(dev, pvu);
+
+ mutex_lock(&ti_pvu_lock);
+ list_add(&pvu->entry, &ti_pvu_list);
+ mutex_unlock(&ti_pvu_lock);
+
+ return 0;
+}
+
+static void ti_pvu_remove(struct platform_device *pdev)
+{
+ struct ti_pvu *pvu = dev_get_drvdata(&pdev->dev);
+
+ mutex_lock(&ti_pvu_lock);
+ list_del(&pvu->entry);
+ mutex_unlock(&ti_pvu_lock);
+}
+
+static const struct of_device_id ti_pvu_of_match[] = {
+ { .compatible = "ti,am654-pvu", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ti_pvu_of_match);
+
+static struct platform_driver ti_pvu_driver = {
+ .driver = {
+ .name = "ti-pvu",
+ .of_match_table = ti_pvu_of_match,
+ },
+ .probe = ti_pvu_probe,
+ .remove = ti_pvu_remove,
+};
+module_platform_driver(ti_pvu_driver);
diff --git a/include/linux/ti-pvu.h b/include/linux/ti-pvu.h
new file mode 100644
index 000000000000..7088da8dad9a
--- /dev/null
+++ b/include/linux/ti-pvu.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * TI Peripheral Virtualization Unit driver for static DMA isolation
+ *
+ * Copyright (c) 2024, Siemens AG
+ */
+
+#ifndef _LINUX_TI_PVU_H
+#define _LINUX_TI_PVU_H
+
+#include <linux/ioport.h>
+
+#if IS_ENABLED(CONFIG_TI_PVU)
+int ti_pvu_create_region(unsigned int virt_id,
+ const struct resource *region);
+int ti_pvu_remove_region(unsigned int virt_id,
+ const struct resource *region);
+#else
+static inline int ti_pvu_create_region(unsigned int virt_id,
+ const struct resource *region)
+{
+ return 0;
+}
+
+static inline int ti_pvu_remove_region(unsigned int virt_id,
+ const struct resource *region)
+{
+ return 0;
+}
+#endif
+
+#endif /* _LINUX_TI_PVU_H */
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v9 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654
2025-07-16 5:10 ` [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation huaqian.li
` (2 preceding siblings ...)
2025-07-16 5:10 ` [PATCH v9 3/7] soc: ti: Add IOMMU-like PVU driver huaqian.li
@ 2025-07-16 5:10 ` huaqian.li
2025-07-16 5:10 ` [PATCH v9 5/7] arm64: dts: ti: k3-am65-main: Add PVU nodes huaqian.li
` (3 subsequent siblings)
7 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:10 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
The AM654 lacks an IOMMU, thus does not support isolating DMA requests
from untrusted PCI devices to selected memory regions this way. Use
static PVU-based protection instead. The PVU, when enabled, will only
accept DMA requests that address previously configured regions.
Use the availability of a restricted-dma-pool memory region as trigger
and register it as valid DMA target with the PVU. In addition, enable
the mapping of requester IDs to VirtIDs in the PCI RC. Use only a single
VirtID so far, catching all devices.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
drivers/pci/controller/dwc/pci-keystone.c | 106 ++++++++++++++++++++++
1 file changed, 106 insertions(+)
diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
index 2b2632e513b5..fbf1bf43b7ca 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -19,6 +19,7 @@
#include <linux/mfd/syscon.h>
#include <linux/msi.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_pci.h>
#include <linux/phy/phy.h>
@@ -26,6 +27,7 @@
#include <linux/regmap.h>
#include <linux/resource.h>
#include <linux/signal.h>
+#include <linux/ti-pvu.h>
#include "../../pci.h"
#include "pcie-designware.h"
@@ -111,6 +113,16 @@
#define PCI_DEVICE_ID_TI_AM654X 0xb00c
+#define KS_PCI_VIRTID 0
+
+#define PCIE_VMAP_xP_CTRL 0x0
+#define PCIE_VMAP_xP_REQID 0x4
+#define PCIE_VMAP_xP_VIRTID 0x8
+
+#define PCIE_VMAP_xP_CTRL_EN BIT(0)
+
+#define PCIE_VMAP_xP_VIRTID_VID_MASK 0xfff
+
struct ks_pcie_of_data {
enum dw_pcie_device_mode mode;
const struct dw_pcie_host_ops *host_ops;
@@ -1136,6 +1148,94 @@ static const struct of_device_id ks_pcie_of_match[] = {
{ },
};
+static int ks_init_vmap(struct platform_device *pdev, const char *vmap_name)
+{
+ struct resource *res;
+ void __iomem *base;
+ u32 val;
+
+ if (!IS_ENABLED(CONFIG_TI_PVU))
+ return 0;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, vmap_name);
+ base = devm_pci_remap_cfg_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ writel(0, base + PCIE_VMAP_xP_REQID);
+
+ val = readl(base + PCIE_VMAP_xP_VIRTID);
+ val &= ~PCIE_VMAP_xP_VIRTID_VID_MASK;
+ val |= KS_PCI_VIRTID;
+ writel(val, base + PCIE_VMAP_xP_VIRTID);
+
+ val = readl(base + PCIE_VMAP_xP_CTRL);
+ val |= PCIE_VMAP_xP_CTRL_EN;
+ writel(val, base + PCIE_VMAP_xP_CTRL);
+
+ return 0;
+}
+
+static int ks_init_restricted_dma(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct of_phandle_iterator it;
+ struct resource phys;
+ int err;
+
+ if (!IS_ENABLED(CONFIG_TI_PVU))
+ return 0;
+
+ /* Only process the first restricted DMA pool, more are not allowed */
+ of_for_each_phandle(&it, err, dev->of_node, "memory-region",
+ NULL, 0) {
+ if (of_device_is_compatible(it.node, "restricted-dma-pool"))
+ break;
+ }
+ if (err)
+ return err == -ENOENT ? 0 : err;
+
+ err = of_address_to_resource(it.node, 0, &phys);
+ if (err < 0) {
+ dev_err(dev, "failed to parse memory region %pOF: %d\n",
+ it.node, err);
+ return 0;
+ }
+
+ /* Map all incoming requests on low and high prio port to virtID 0 */
+ err = ks_init_vmap(pdev, "vmap_lp");
+ if (err)
+ return err;
+ err = ks_init_vmap(pdev, "vmap_hp");
+ if (err)
+ return err;
+
+ /*
+ * Enforce DMA pool usage with the help of the PVU.
+ * Any request outside will be dropped and raise an error at the PVU.
+ */
+ return ti_pvu_create_region(KS_PCI_VIRTID, &phys);
+}
+
+static void ks_release_restricted_dma(struct platform_device *pdev)
+{
+ struct of_phandle_iterator it;
+ struct resource phys;
+ int err;
+
+ if (!IS_ENABLED(CONFIG_TI_PVU))
+ return;
+
+ of_for_each_phandle(&it, err, pdev->dev.of_node, "memory-region",
+ NULL, 0) {
+ if (of_device_is_compatible(it.node, "restricted-dma-pool") &&
+ of_address_to_resource(it.node, 0, &phys) == 0) {
+ ti_pvu_remove_region(KS_PCI_VIRTID, &phys);
+ break;
+ }
+ }
+}
+
static int ks_pcie_probe(struct platform_device *pdev)
{
const struct dw_pcie_host_ops *host_ops;
@@ -1284,6 +1384,10 @@ static int ks_pcie_probe(struct platform_device *pdev)
if (ret < 0)
goto err_get_sync;
+ ret = ks_init_restricted_dma(pdev);
+ if (ret < 0)
+ goto err_get_sync;
+
switch (mode) {
case DW_PCIE_RC_TYPE:
if (!IS_ENABLED(CONFIG_PCI_KEYSTONE_HOST)) {
@@ -1365,6 +1469,8 @@ static void ks_pcie_remove(struct platform_device *pdev)
int num_lanes = ks_pcie->num_lanes;
struct device *dev = &pdev->dev;
+ ks_release_restricted_dma(pdev);
+
pm_runtime_put(dev);
pm_runtime_disable(dev);
ks_pcie_disable_phy(ks_pcie);
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v9 5/7] arm64: dts: ti: k3-am65-main: Add PVU nodes
2025-07-16 5:10 ` [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation huaqian.li
` (3 preceding siblings ...)
2025-07-16 5:10 ` [PATCH v9 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654 huaqian.li
@ 2025-07-16 5:10 ` huaqian.li
2025-07-16 5:10 ` [PATCH v9 6/7] arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes huaqian.li
` (2 subsequent siblings)
7 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:10 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
Add nodes for the two PVUs of the AM65. Keep them disabled, though,
because the board has to additionally define DMA pools and the devices
to be isolated.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index b085e7361116..be65e6aa7b80 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -843,6 +843,26 @@ main_cpts_mux: refclk-mux {
assigned-clock-parents = <&k3_clks 118 5>;
};
};
+
+ ti_pvu0: iommu@30f80000 {
+ compatible = "ti,am654-pvu";
+ reg = <0 0x30f80000 0 0x1000>,
+ <0 0x36000000 0 0x100000>;
+ reg-names = "cfg", "tlbif";
+ interrupts-extended = <&intr_main_navss 390>;
+ interrupt-names = "pvu";
+ status = "disabled";
+ };
+
+ ti_pvu1: iommu@30f81000 {
+ compatible = "ti,am654-pvu";
+ reg = <0 0x30f81000 0 0x1000>,
+ <0 0x36100000 0 0x100000>;
+ reg-names = "cfg", "tlbif";
+ interrupts-extended = <&intr_main_navss 389>;
+ interrupt-names = "pvu";
+ status = "disabled";
+ };
};
main_gpio0: gpio@600000 {
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v9 6/7] arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes
2025-07-16 5:10 ` [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation huaqian.li
` (4 preceding siblings ...)
2025-07-16 5:10 ` [PATCH v9 5/7] arm64: dts: ti: k3-am65-main: Add PVU nodes huaqian.li
@ 2025-07-16 5:10 ` huaqian.li
2025-07-16 5:10 ` [PATCH v9 7/7] arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices behind PCI RC huaqian.li
2025-07-16 6:02 ` [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation Krzysztof Kozlowski
7 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:10 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
Rewrap the long lines at this chance.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index be65e6aa7b80..d0036b0aa818 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -897,8 +897,13 @@ main_gpio1: gpio@601000 {
pcie0_rc: pcie@5500000 {
compatible = "ti,am654-pcie-rc";
- reg = <0x0 0x5500000 0x0 0x1000>, <0x0 0x5501000 0x0 0x1000>, <0x0 0x10000000 0x0 0x2000>, <0x0 0x5506000 0x0 0x1000>;
- reg-names = "app", "dbics", "config", "atu";
+ reg = <0x0 0x5500000 0x0 0x1000>,
+ <0x0 0x5501000 0x0 0x1000>,
+ <0x0 0x10000000 0x0 0x2000>,
+ <0x0 0x5506000 0x0 0x1000>,
+ <0x0 0x2900000 0x0 0x1000>,
+ <0x0 0x2908000 0x0 0x1000>;
+ reg-names = "app", "dbics", "config", "atu", "vmap_lp", "vmap_hp";
power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <3>;
#size-cells = <2>;
@@ -918,8 +923,13 @@ pcie0_rc: pcie@5500000 {
pcie1_rc: pcie@5600000 {
compatible = "ti,am654-pcie-rc";
- reg = <0x0 0x5600000 0x0 0x1000>, <0x0 0x5601000 0x0 0x1000>, <0x0 0x18000000 0x0 0x2000>, <0x0 0x5606000 0x0 0x1000>;
- reg-names = "app", "dbics", "config", "atu";
+ reg = <0x0 0x5600000 0x0 0x1000>,
+ <0x0 0x5601000 0x0 0x1000>,
+ <0x0 0x18000000 0x0 0x2000>,
+ <0x0 0x5606000 0x0 0x1000>,
+ <0x0 0x2910000 0x0 0x1000>,
+ <0x0 0x2918000 0x0 0x1000>;
+ reg-names = "app", "dbics", "config", "atu", "vmap_lp", "vmap_hp";
power-domains = <&k3_pds 121 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <3>;
#size-cells = <2>;
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v9 7/7] arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices behind PCI RC
2025-07-16 5:10 ` [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation huaqian.li
` (5 preceding siblings ...)
2025-07-16 5:10 ` [PATCH v9 6/7] arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes huaqian.li
@ 2025-07-16 5:10 ` huaqian.li
2025-07-16 6:02 ` [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation Krzysztof Kozlowski
7 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:10 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
Reserve a 64M memory region and ensure that all PCI devices do their DMA
only inside that region. This is configured via a restricted-dma-pool
and enforced with the help of the first PVU.
Applying this isolation is not totally free in terms of overhead and
memory consumption. It makes only sense for variants that support
secure booting, and generally only when this is actually enable.
Therefore model it as overlay that can be activated on demand. The
firmware will take care of this via DT fixup during boot and will also
provide a way to adjust the pool size.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
arch/arm64/boot/dts/ti/Makefile | 5 +++
...am6548-iot2050-advanced-dma-isolation.dtso | 33 +++++++++++++++++++
2 files changed, 38 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index c6171de9fe88..66b1d8093fa2 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -84,8 +84,10 @@ k3-am654-gp-evm-dtbs := k3-am654-base-board.dtb \
k3-am654-evm-dtbs := k3-am654-base-board.dtb k3-am654-icssg2.dtbo
k3-am654-idk-dtbs := k3-am654-evm.dtb k3-am654-idk.dtbo k3-am654-pcie-usb2.dtbo
k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-dtbs := k3-am6548-iot2050-advanced-m2.dtb \
+ k3-am6548-iot2050-advanced-dma-isolation.dtbo \
k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie.dtbo
k3-am6548-iot2050-advanced-m2-bkey-usb3-dtbs := k3-am6548-iot2050-advanced-m2.dtb \
+ k3-am6548-iot2050-advanced-dma-isolation.dtbo \
k3-am6548-iot2050-advanced-m2-bkey-usb3.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic-pg2.dtb
@@ -288,7 +290,10 @@ DTC_FLAGS_k3-am62p5-sk += -@
DTC_FLAGS_k3-am642-evm += -@
DTC_FLAGS_k3-am642-phyboard-electra-rdk += -@
DTC_FLAGS_k3-am642-tqma64xxl-mbax4xxl += -@
+DTC_FLAGS_k3-am6548-iot2050-advanced += -@
DTC_FLAGS_k3-am6548-iot2050-advanced-m2 += -@
+DTC_FLAGS_k3-am6548-iot2050-advanced-pg2 += -@
+DTC_FLAGS_k3-am6548-iot2050-advanced-sm += -@
DTC_FLAGS_k3-am68-sk-base-board += -@
DTC_FLAGS_k3-am69-sk += -@
DTC_FLAGS_k3-j7200-common-proc-board += -@
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
new file mode 100644
index 000000000000..dfd75d2dc245
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * IOT2050, overlay for isolating DMA requests via PVU
+ * Copyright (c) Siemens AG, 2024
+ *
+ * Authors:
+ * Jan Kiszka <jan.kiszka@siemens.com>
+ */
+
+/dts-v1/;
+/plugin/;
+
+&{/reserved-memory} {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pci_restricted_dma_region: restricted-dma@c0000000 {
+ compatible = "restricted-dma-pool";
+ reg = <0 0xc0000000 0 0x4000000>;
+ };
+};
+
+&pcie0_rc {
+ memory-region = <&pci_restricted_dma_region>;
+};
+
+&pcie1_rc {
+ memory-region = <&pci_restricted_dma_region>;
+};
+
+&ti_pvu0 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation
2025-07-16 5:10 ` [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation huaqian.li
` (6 preceding siblings ...)
2025-07-16 5:10 ` [PATCH v9 7/7] arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices behind PCI RC huaqian.li
@ 2025-07-16 6:02 ` Krzysztof Kozlowski
2025-07-16 6:37 ` Li, Hua Qian
7 siblings, 1 reply; 58+ messages in thread
From: Krzysztof Kozlowski @ 2025-07-16 6:02 UTC (permalink / raw)
To: huaqian.li, s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel, linux-kernel,
linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr
On 16/07/2025 07:10, huaqian.li@siemens.com wrote:
> From: Li Hua Qian <huaqian.li@siemens.com>
>
> Changes in v8:
> - remove patch 8 from this series to simplify the patchset
> - fix dt_bindings_check warnings (patch 2), 'memory-region' must
> not be a required property
>
You keep attaching this to other thread creating this monstrosity:
https://lore.kernel.org/all/20250422061406.112539-2-huaqian.li@siemens.com/
Don't. Each patchset is each own thread.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation
2025-07-16 6:02 ` [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation Krzysztof Kozlowski
@ 2025-07-16 6:37 ` Li, Hua Qian
0 siblings, 0 replies; 58+ messages in thread
From: Li, Hua Qian @ 2025-07-16 6:37 UTC (permalink / raw)
To: s-vadapalli@ti.com, krzk@kernel.org
Cc: ssantosh@kernel.org, robh@kernel.org, kw@linux.com,
kristo@kernel.org, Kiszka, Jan, helgaas@kernel.org,
linux-kernel@vger.kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, lpieralisi@kernel.org,
krzk+dt@kernel.org, Su, Bao Cheng,
linux-arm-kernel@lists.infradead.org, nm@ti.com,
linux-pci@vger.kernel.org, bhelgaas@google.com, vigneshr@ti.com,
Lopes Ivo, Diogo Miguel
On Wed, 2025-07-16 at 08:02 +0200, Krzysztof Kozlowski wrote:
> On 16/07/2025 07:10, huaqian.li@siemens.com wrote:
> > From: Li Hua Qian <huaqian.li@siemens.com>
> >
> > Changes in v8:
> > - remove patch 8 from this series to simplify the patchset
> > - fix dt_bindings_check warnings (patch 2), 'memory-region' must
> > not be a required property
> >
>
> You keep attaching this to other thread creating this monstrosity:
> https://lore.kernel.org/all/20250422061406.112539-2-huaqian.li@siemens.com/
>
> Don't. Each patchset is each own thread.
>
> Best regards,
> Krzysztof
Hi Krzysztof,
Thank you for pointing out this issue. I apologize for the threading
confusion. I mistakenly used an incorrect --in-reply-to parameter when
copying git send-email command and sending the patch series, which
caused it to be threaded with the previous series instead of starting a
new thread.
I'll ensure future patch series are sent as independent threads without
any --in-reply-to reference to avoid this problem.
Thanks again.
With Best Regards,
--
Hua Qian Li
Siemens AG
http://www.siemens.com/
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v9 (RESEND) 0/7] soc: ti: Add and use PVU on K3-AM65 for DMA isolation
2025-07-15 9:15 ` Siddharth Vadapalli
2025-07-16 5:10 ` [PATCH v9 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation huaqian.li
@ 2025-07-16 5:39 ` huaqian.li
2025-07-16 5:39 ` [PATCH v9 (RESEND) 1/7] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit huaqian.li
` (6 more replies)
1 sibling, 7 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:39 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr
From: Li Hua Qian <huaqian.li@siemens.com>
[Resending v9 due to formatting issue in previous cover letter]
Changes in v9:
- Update commit message (patch 4) to remove ambiguous extension claims
based on upstream feedback
Changes in v8:
- remove patch 8 from this series to simplify the patchset
- fix dt_bindings_check warnings (patch 2), 'memory-region' must
not be a required property
Changes in v7:
- add schema expressing dependency as suggested on pci-host bindings
- resolve review comments on pci-keystone driver
- add a new patch to make IO_TLB_SEGSIZE configurable
- improve patches based on checkpath.pl
Changes in v6:
- make restricted DMA memory-region available to all pci-keystone
devices, moving property to unconditional section (patch 2)
Changes in v5:
- resolve review comments on pci-host bindings
- reduce DMA memory regions to 1 - swiotlb does not support more
- move activation into overlay (controlled via firmware)
- use ks_init_vmap helper instead of loop in
rework ks_init_restricted_dma
- add more comments to pci-keystone
- use 2 chained TLBs of PVU to support maximum of swiotlb (320 MB)
Changes in v4:
- reorder patch queue, moving all DTS changes to the back
- limit activation to IOT2050 Advanced variants
- move DMA pool to allow firmware-based expansion it up to 512M
Changes in v3:
- fix ti,am654-pvu.yaml according to review comments
- address review comments on ti,am65-pci-host.yaml
- differentiate between different compatibles in ti,am65-pci-host.yaml
- move pvu nodes to k3-am65-main.dtsi
- reorder patch series, pulling bindings and generic DT bits to the front
Changes in v2:
- fix dt_bindings_check issues (patch 1)
- address first review comments (patch 2)
- extend ti,am65-pci-host bindings for PVU (new patch 3)
Only few of the K3 SoCs have an IOMMU and, thus, can isolate the system
against DMA-based attacks of external PCI devices. The AM65 is without
an IOMMU, but it comes with something close to it: the Peripheral
Virtualization Unit (PVU).
The PVU was originally designed to establish static compartments via a
hypervisor, isolate those DMA-wise against each other and the host and
even allow remapping of guest-physical addresses. But it only provides
a static translation region, not page-granular mappings. Thus, it cannot
be handled transparently like an IOMMU.
Now, to use the PVU for the purpose of isolated PCI devices from the
Linux host, this series takes a different approach. It defines a
restricted-dma-pool for the PCI host, using swiotlb to map all DMA
buffers from a static memory carve-out. And to enforce that the devices
actually follow this, a special PVU soc driver is introduced. The driver
permits access to the GIC ITS and otherwise waits for other drivers that
detect devices with constrained DMA to register pools with the PVU.
For the AM65, the first (and possibly only) driver where this is
introduced is the pci-keystone host controller. Finally, this series
provides a DT overlay for the IOT2050 Advanced devices (all have
MiniPCIe or M.2 extension slots) to make use of this protection scheme.
Application of this overlay will be handled by firmware.
Due to the cross-cutting nature of these changes, multiple subsystems
are affected. However, I wanted to present the whole thing in one series
to allow everyone to review with the complete picture in hands. If
preferred, I can also split the series up, of course.
Jan
Jan Kiszka (7):
dt-bindings: soc: ti: Add AM65 peripheral virtualization unit
dt-bindings: PCI: ti,am65: Extend for use with PVU
soc: ti: Add IOMMU-like PVU driver
PCI: keystone: Add support for PVU-based DMA isolation on AM654
arm64: dts: ti: k3-am65-main: Add PVU nodes
arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes
arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices
behind PCI RC
.../bindings/pci/ti,am65-pci-host.yaml | 28 +-
.../bindings/soc/ti/ti,am654-pvu.yaml | 51 ++
arch/arm64/boot/dts/ti/Makefile | 5 +
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 38 +-
...am6548-iot2050-advanced-dma-isolation.dtso | 33 ++
drivers/pci/controller/dwc/pci-keystone.c | 106 ++++
drivers/soc/ti/Kconfig | 4 +
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti-pvu.c | 500 ++++++++++++++++++
include/linux/ti-pvu.h | 32 ++
10 files changed, 791 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
create mode 100644 drivers/soc/ti/ti-pvu.c
create mode 100644 include/linux/ti-pvu.h
--
2.34.1
^ permalink raw reply [flat|nested] 58+ messages in thread* [PATCH v9 (RESEND) 1/7] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit
2025-07-16 5:39 ` [PATCH v9 (RESEND) 0/7] " huaqian.li
@ 2025-07-16 5:39 ` huaqian.li
2025-07-16 5:39 ` [PATCH v9 (RESEND) 2/7] dt-bindings: PCI: ti,am65: Extend for use with PVU huaqian.li
` (5 subsequent siblings)
6 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:39 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr,
Krzysztof Kozlowski
From: Jan Kiszka <jan.kiszka@siemens.com>
The PVU allows to define a limited set of mappings for incoming DMA
requests to the system memory. It is not a real IOMMU, thus hooked up
under the TI SoC bindings.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
.../bindings/soc/ti/ti,am654-pvu.yaml | 51 +++++++++++++++++++
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml b/Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
new file mode 100644
index 000000000000..e4a5fc47d674
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) Siemens AG, 2024
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/ti/ti,am654-pvu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI AM654 Peripheral Virtualization Unit
+
+maintainers:
+ - Jan Kiszka <jan.kiszka@siemens.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,am654-pvu
+
+ reg:
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: cfg
+ - const: tlbif
+
+ interrupts:
+ items:
+ - description: fault interrupt
+
+ interrupt-names:
+ items:
+ - const: pvu
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+
+additionalProperties: false
+
+examples:
+ - |
+ iommu@30f80000 {
+ compatible = "ti,am654-pvu";
+ reg = <0x30f80000 0x1000>,
+ <0x36000000 0x100000>;
+ reg-names = "cfg", "tlbif";
+ interrupts-extended = <&intr_main_navss 390>;
+ interrupt-names = "pvu";
+ };
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v9 (RESEND) 2/7] dt-bindings: PCI: ti,am65: Extend for use with PVU
2025-07-16 5:39 ` [PATCH v9 (RESEND) 0/7] " huaqian.li
2025-07-16 5:39 ` [PATCH v9 (RESEND) 1/7] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit huaqian.li
@ 2025-07-16 5:39 ` huaqian.li
2025-07-16 5:39 ` [PATCH v9 (RESEND) 3/7] soc: ti: Add IOMMU-like PVU driver huaqian.li
` (4 subsequent siblings)
6 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:39 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr,
Krzysztof Kozlowski
From: Jan Kiszka <jan.kiszka@siemens.com>
The PVU on the AM65 SoC is capable of restricting DMA from PCIe devices
to specific regions of host memory. Add the optional property
"memory-regions" to point to such regions of memory when PVU is used.
Since the PVU deals with system physical addresses, utilizing the PVU
with PCIe devices also requires setting up the VMAP registers to map the
Requester ID of the PCIe device to the CBA Virtual ID, which in turn is
mapped to the system physical address. Hence, describe the VMAP
registers which are optional unless the PVU shall be used for PCIe.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
.../bindings/pci/ti,am65-pci-host.yaml | 28 +++++++++++++++++--
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
index 0a9d10532cc8..98f6c7f1b1a6 100644
--- a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml
@@ -20,14 +20,18 @@ properties:
- ti,keystone-pcie
reg:
- maxItems: 4
+ minItems: 4
+ maxItems: 6
reg-names:
+ minItems: 4
items:
- const: app
- const: dbics
- const: config
- const: atu
+ - const: vmap_lp
+ - const: vmap_hp
interrupts:
maxItems: 1
@@ -69,6 +73,15 @@ properties:
items:
pattern: '^pcie-phy[0-1]$'
+ memory-region:
+ maxItems: 1
+ description: |
+ phandle to a restricted DMA pool to be used for all devices behind
+ this controller. The regions should be defined according to
+ reserved-memory/shared-dma-pool.yaml.
+ Note that enforcement via the PVU will only be available to
+ ti,am654-pcie-rc devices.
+
required:
- compatible
- reg
@@ -89,6 +102,13 @@ then:
- power-domains
- msi-map
- num-viewport
+else:
+ properties:
+ reg:
+ maxItems: 4
+
+ reg-names:
+ maxItems: 4
unevaluatedProperties: false
@@ -104,8 +124,10 @@ examples:
reg = <0x5500000 0x1000>,
<0x5501000 0x1000>,
<0x10000000 0x2000>,
- <0x5506000 0x1000>;
- reg-names = "app", "dbics", "config", "atu";
+ <0x5506000 0x1000>,
+ <0x2900000 0x1000>,
+ <0x2908000 0x1000>;
+ reg-names = "app", "dbics", "config", "atu", "vmap_lp", "vmap_hp";
power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <3>;
#size-cells = <2>;
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v9 (RESEND) 3/7] soc: ti: Add IOMMU-like PVU driver
2025-07-16 5:39 ` [PATCH v9 (RESEND) 0/7] " huaqian.li
2025-07-16 5:39 ` [PATCH v9 (RESEND) 1/7] dt-bindings: soc: ti: Add AM65 peripheral virtualization unit huaqian.li
2025-07-16 5:39 ` [PATCH v9 (RESEND) 2/7] dt-bindings: PCI: ti,am65: Extend for use with PVU huaqian.li
@ 2025-07-16 5:39 ` huaqian.li
2025-07-16 5:39 ` [PATCH v9 (RESEND) 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654 huaqian.li
` (3 subsequent siblings)
6 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:39 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
The TI Peripheral Virtualization Unit (PVU) permits to define a limited
set of mappings for DMA requests on the system memory. Unlike with an
IOMMU, there is no fallback to a memory-backed page table, only a fixed
set of register-backed TLBs. Emulating an IOMMU behavior appears to be
the more fragile the more fragmentation of pending requests occur.
Therefore, this driver does not expose the PVU as an IOMMU. It rather
introduces a simple, static interface to devices that are under
restricted-dma-pool constraints. They can register their pools with the
PVUs, enabling only those pools to work for DMA. As also MSI is issued
as DMA, the PVU already register the related translator region of the
AM654 as valid DMA target.
This driver is the essential building block for limiting DMA from
untrusted devices to clearly defined memory regions in the absence of a
real IOMMU (SMMU).
Co-developed-by: Diogo Ivo <diogo.ivo@siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
drivers/soc/ti/Kconfig | 4 +
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti-pvu.c | 500 ++++++++++++++++++++++++++++++++++++++++
include/linux/ti-pvu.h | 32 +++
4 files changed, 537 insertions(+)
create mode 100644 drivers/soc/ti/ti-pvu.c
create mode 100644 include/linux/ti-pvu.h
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 1a93001c9e36..af7173ad84de 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -82,6 +82,10 @@ config TI_PRUSS
processors on various TI SoCs. It's safe to say N here if you're
not interested in the PRU or if you are unsure.
+config TI_PVU
+ bool "TI Peripheral Virtualization Unit driver"
+ depends on ARCH_K3 && DMA_RESTRICTED_POOL
+
endif # SOC_TI
config TI_SCI_INTA_MSI_DOMAIN
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index cb800a745e66..ecff3fd8c433 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_TI_K3_RINGACC) += k3-ringacc.o
obj-$(CONFIG_TI_K3_SOCINFO) += k3-socinfo.o
obj-$(CONFIG_TI_PRUSS) += pruss.o
obj-$(CONFIG_POWER_AVS_OMAP) += smartreflex.o
+obj-$(CONFIG_TI_PVU) += ti-pvu.o
diff --git a/drivers/soc/ti/ti-pvu.c b/drivers/soc/ti/ti-pvu.c
new file mode 100644
index 000000000000..38996c74cce7
--- /dev/null
+++ b/drivers/soc/ti/ti-pvu.c
@@ -0,0 +1,500 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TI Peripheral Virtualization Unit driver for static DMA isolation
+ *
+ * Copyright (c) 2024, Siemens AG
+ */
+
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/ti-pvu.h>
+
+#define PVU_CONFIG 0x4
+#define PVU_ENABLE 0x10
+#define PVU_VIRTID_MAP1 0x14
+#define PVU_VIRTID_MAP2 0x18
+#define PVU_EXCEPTION_LOGGING_CONTROL 0x120
+#define PVU_EXCEPTION_LOGGING_HEADER0 0x124
+#define PVU_EXCEPTION_LOGGING_HEADER1 0x128
+#define PVU_EXCEPTION_LOGGING_DATA0 0x12c
+#define PVU_EXCEPTION_LOGGING_DATA1 0x130
+#define PVU_EXCEPTION_LOGGING_DATA2 0x134
+#define PVU_EXCEPTION_LOGGING_DATA2_SECURE BIT(0)
+#define PVU_EXCEPTION_LOGGING_DATA2_PRIV BIT(1)
+#define PVU_EXCEPTION_LOGGING_DATA2_CACHEABLE BIT(2)
+#define PVU_EXCEPTION_LOGGING_DATA2_DEBUG BIT(3)
+#define PVU_EXCEPTION_LOGGING_DATA2_READ BIT(4)
+#define PVU_EXCEPTION_LOGGING_DATA2_WRITE BIT(5)
+#define PVU_EXCEPTION_LOGGING_DATA3 0x138
+#define PVU_EXCEPTION_ENABLE_SET 0x148
+#define PVU_EOI_REG 0x150
+
+#define PVU_CHAIN 0x0
+#define PVU_CHAIN_EN BIT(31)
+#define PVU_CHAIN_LOG_DIS BIT(30)
+#define PVU_CHAIN_FAULT BIT(29)
+#define PVU_CHAIN_MASK 0xfff
+#define PVU_ENTRY0 0x20
+#define PVU_ENTRY1 0x24
+#define PVU_ENTRY1_RESERVED_MASK 0xffff0000
+#define PVU_ENTRY1_VBASE_H_MASK 0xffff
+#define PVU_ENTRY2 0x28
+#define PVU_ENTRY2_RESERVED_MASK 0x1fd00080
+#define PVU_ENTRY2_INVALID (0U << 30)
+#define PVU_ENTRY2_VALID (2U << 30)
+#define PVU_ENTRY2_MODE_MASK 0xc0000000
+#define PVU_ENTRY2_PSIZE_SHIFT 16
+#define PVU_ENTRY2_PSIZE_MASK 0xf
+#define PVU_ENTRY2_PERM_SX BIT(15)
+#define PVU_ENTRY2_PERM_SW BIT(14)
+#define PVU_ENTRY2_PERM_SR BIT(13)
+#define PVU_ENTRY2_PERM_UX BIT(12)
+#define PVU_ENTRY2_PERM_UW BIT(11)
+#define PVU_ENTRY2_PERM_UR BIT(10)
+#define PVU_ENTRY2_MEM_WRITETHROUGH (2 << 8)
+#define PVU_ENTRY2_OUTER_SHARABLE BIT(4)
+#define PVU_ENTRY2_IS_NOALLOC (0 << 2)
+#define PVU_ENTRY2_OS_NOALLOC (0 << 0)
+#define PVU_ENTRY4 0x30
+#define PVU_ENTRY5 0x34
+#define PVU_ENTRY5_RESERVED_MASK 0xffff0000
+#define PVU_ENTRY5_PBASE_H_MASK 0xffff
+#define PVU_ENTRY6 0x38
+#define PVU_ENTRY6_RESERVED_MASK 0xffffffe0
+
+#define NUM_VIRTIDS 1
+
+static const struct regmap_config pvu_cfg_regmap_cfg = {
+ .name = "pvu-cfg",
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = PVU_EOI_REG,
+};
+
+enum pvu_cfg_regfields {
+ PVU_TLBS,
+ PVU_TLB_ENTRIES,
+ PVU_ENABLED,
+ PVU_DMA_CNT,
+ PVU_DMA_CL0,
+ PVU_DMA_CL1,
+ PVU_DMA_CL2,
+ PVU_DMA_CL3,
+ PVU_MAX_VIRTID,
+ PVU_EXC_SRC_ID,
+ PVU_EXC_CODE,
+ PVU_EXC_ADDR_L,
+ PVU_EXC_ADDR_H,
+ PVU_EXC_PRIV_ID,
+ PVU_EXC_PROPS,
+ PVU_EXC_ROUTE_ID,
+ PVU_EXC_BYTE_CNT,
+ PVU_EXC_ENABLE,
+ PVU_EOI,
+ PVU_MAX_CFG_FIELDS,
+};
+
+static const struct reg_field pvu_cfg_reg_fields[] = {
+ [PVU_TLBS] = REG_FIELD(PVU_CONFIG, 0, 15),
+ [PVU_TLB_ENTRIES] = REG_FIELD(PVU_CONFIG, 16, 23),
+ [PVU_ENABLED] = REG_FIELD(PVU_ENABLE, 0, 0),
+ [PVU_DMA_CNT] = REG_FIELD(PVU_VIRTID_MAP1, 0, 11),
+ [PVU_DMA_CL0] = REG_FIELD(PVU_VIRTID_MAP1, 16, 17),
+ [PVU_DMA_CL1] = REG_FIELD(PVU_VIRTID_MAP1, 18, 19),
+ [PVU_DMA_CL2] = REG_FIELD(PVU_VIRTID_MAP1, 20, 21),
+ [PVU_DMA_CL3] = REG_FIELD(PVU_VIRTID_MAP1, 22, 23),
+ [PVU_MAX_VIRTID] = REG_FIELD(PVU_VIRTID_MAP2, 0, 11),
+ [PVU_EXC_SRC_ID] = REG_FIELD(PVU_EXCEPTION_LOGGING_HEADER0, 8, 23),
+ [PVU_EXC_CODE] = REG_FIELD(PVU_EXCEPTION_LOGGING_HEADER1, 16, 23),
+ [PVU_EXC_ADDR_L] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA0, 0, 31),
+ [PVU_EXC_ADDR_H] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA1, 0, 15),
+ [PVU_EXC_PRIV_ID] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA2, 0, 7),
+ [PVU_EXC_PROPS] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA2, 8, 13),
+ [PVU_EXC_ROUTE_ID] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA2, 16, 27),
+ [PVU_EXC_BYTE_CNT] = REG_FIELD(PVU_EXCEPTION_LOGGING_DATA3, 0, 9),
+ [PVU_EXC_ENABLE] = REG_FIELD(PVU_EXCEPTION_ENABLE_SET, 0, 0),
+ [PVU_EOI] = REG_FIELD(PVU_EOI_REG, 0, 15),
+};
+
+struct ti_pvu {
+ struct list_head entry;
+ struct platform_device *pdev;
+ struct regmap *cfg;
+ struct regmap_field *cfg_fields[PVU_MAX_CFG_FIELDS];
+ void __iomem *tlbif_base;
+ unsigned int num_tlbs;
+ unsigned int num_entries;
+};
+
+static const char *pvu_excp_code_string[] = {
+ "PVU miss",
+ "maximum VirtID violation",
+ "<reserved>",
+ "read permission violation",
+ "write permission violation",
+ "execute permission violation",
+ "prefetch permission violation",
+ "<unknown>",
+};
+
+static const u64 pvu_page_size[] = {
+ 4 * 1024ULL,
+ 16 * 1024ULL,
+ 64 * 1024ULL,
+ 2 * 1024 * 1024ULL,
+ 32 * 1024 * 1024ULL,
+ 512 * 1024 * 1024ULL,
+ 1 * 1024 * 1024 * 1024ULL,
+ 16 * 1024 * 1024 * 1024ULL
+};
+
+static DEFINE_MUTEX(ti_pvu_lock);
+static LIST_HEAD(ti_pvu_list);
+
+static unsigned int pvu_field_read(struct ti_pvu *pvu, enum pvu_cfg_regfields f)
+{
+ int ret;
+ unsigned int val;
+
+ ret = regmap_field_read(pvu->cfg_fields[f], &val);
+ if (ret)
+ dev_err(&pvu->pdev->dev, "failed to read field\n");
+
+ return val;
+}
+
+static void pvu_field_write(struct ti_pvu *pvu, enum pvu_cfg_regfields f,
+ unsigned int val)
+{
+ int ret;
+
+ ret = regmap_field_write(pvu->cfg_fields[f], val);
+ if (ret)
+ dev_err(&pvu->pdev->dev, "failed to write field\n");
+}
+
+static irqreturn_t pvu_fault_isr(int irq, void *dev_id)
+{
+ u32 code, bytes, route_id, priv_id, props;
+ struct ti_pvu *pvu = dev_id;
+ const char *code_str;
+ u64 address;
+
+ code = pvu_field_read(pvu, PVU_EXC_CODE);
+ code_str = pvu_excp_code_string[
+ min(code, (u32)ARRAY_SIZE(pvu_excp_code_string) - 1)];
+
+ dev_err(&pvu->pdev->dev, "fault detected, code %d (%s)\n",
+ code, code_str);
+
+ address = pvu_field_read(pvu, PVU_EXC_ADDR_L);
+ address |= (u64)pvu_field_read(pvu, PVU_EXC_ADDR_H) << 32;
+
+ bytes = pvu_field_read(pvu, PVU_EXC_BYTE_CNT);
+
+ route_id = pvu_field_read(pvu, PVU_EXC_ROUTE_ID);
+ priv_id = pvu_field_read(pvu, PVU_EXC_PRIV_ID);
+ props = pvu_field_read(pvu, PVU_EXC_PROPS);
+
+ dev_err(&pvu->pdev->dev,
+ " address 0x%016llx size %d route-ID %d priv-ID %d flags %c%c%c%c%c%c\n",
+ address, bytes, route_id, priv_id,
+ (props & PVU_EXCEPTION_LOGGING_DATA2_WRITE) ? 'W' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_READ) ? 'R' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_DEBUG) ? 'D' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_CACHEABLE) ? 'C' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_PRIV) ? 'P' : '-',
+ (props & PVU_EXCEPTION_LOGGING_DATA2_SECURE) ? 'S' : '-');
+
+ pvu_field_write(pvu, PVU_EOI, 0);
+
+ return IRQ_HANDLED;
+}
+
+static void __iomem *pvu_get_entry_base(struct ti_pvu *pvu, unsigned int entry)
+{
+ return pvu->tlbif_base + (entry / pvu->num_entries) * 0x1000 +
+ (entry % pvu->num_entries) * 0x20;
+}
+
+static int pvu_get_free_entry(struct ti_pvu *pvu)
+{
+ unsigned int n;
+ u32 val;
+
+ /* We use up to 2 TLBs via chainging */
+ for (n = 0; n < pvu->num_entries * 2; n++) {
+ val = readl(pvu_get_entry_base(pvu, n) + PVU_ENTRY2);
+ if ((val & PVU_ENTRY2_MODE_MASK) == PVU_ENTRY2_INVALID)
+ return n;
+ }
+ return -ENOSPC;
+}
+
+static void pvu_write_entry(struct ti_pvu *pvu, unsigned int entry,
+ u64 addr, u32 psize)
+{
+ void __iomem *entry_base = pvu_get_entry_base(pvu, entry);
+ u32 val;
+
+ writel((u32)addr, entry_base + PVU_ENTRY0);
+
+ val = readl(entry_base + PVU_ENTRY1);
+ val &= PVU_ENTRY1_RESERVED_MASK;
+ val |= (addr >> 32) & PVU_ENTRY1_VBASE_H_MASK;
+ writel(val, entry_base + PVU_ENTRY1);
+
+ writel((u32)addr, entry_base + PVU_ENTRY4);
+
+ val = readl(entry_base + PVU_ENTRY5);
+ val &= PVU_ENTRY5_RESERVED_MASK;
+ val |= (addr >> 32) & PVU_ENTRY5_PBASE_H_MASK;
+ writel(val, entry_base + PVU_ENTRY5);
+
+ val = readl(entry_base + PVU_ENTRY6);
+ val &= PVU_ENTRY6_RESERVED_MASK;
+ writel(val, entry_base + PVU_ENTRY6);
+
+ val = readl(entry_base + PVU_ENTRY2);
+ val &= PVU_ENTRY2_RESERVED_MASK;
+ val |= psize << PVU_ENTRY2_PSIZE_SHIFT;
+ val |= PVU_ENTRY2_VALID |
+ PVU_ENTRY2_PERM_UR | PVU_ENTRY2_PERM_SR |
+ PVU_ENTRY2_PERM_UW | PVU_ENTRY2_PERM_SW |
+ PVU_ENTRY2_PERM_UX | PVU_ENTRY2_PERM_SX |
+ PVU_ENTRY2_MEM_WRITETHROUGH | PVU_ENTRY2_OUTER_SHARABLE |
+ PVU_ENTRY2_IS_NOALLOC | PVU_ENTRY2_OS_NOALLOC;
+ writel(val, entry_base + PVU_ENTRY2);
+}
+
+static int pvu_create_region(struct ti_pvu *pvu, u64 addr, u64 size)
+{
+ u64 page_size;
+ int psize;
+ int entry;
+
+ while (size > 0) {
+ entry = pvu_get_free_entry(pvu);
+ if (entry < 0) {
+ dev_err(&pvu->pdev->dev, "ran out of TLB entries\n");
+ return -ENOSPC;
+ }
+
+ for (psize = ARRAY_SIZE(pvu_page_size) - 1; psize >= 0; psize--) {
+ page_size = pvu_page_size[psize];
+ if (size >= page_size && (addr & (page_size - 1)) == 0)
+ break;
+ }
+ if (psize < 0) {
+ dev_err(&pvu->pdev->dev, "unaligned region provided\n");
+ return -EINVAL;
+ }
+
+ pvu_write_entry(pvu, entry, addr, psize);
+ dev_info(&pvu->pdev->dev,
+ "created TLB entry %d.%d: 0x%08llx, psize %d (0x%08llx)\n",
+ entry / pvu->num_entries, entry % pvu->num_entries,
+ addr, psize, page_size);
+
+ size -= page_size;
+ addr += page_size;
+ }
+
+ return 0;
+}
+
+static void pvu_remove_region(struct ti_pvu *pvu, u64 addr, u64 size)
+{
+ void __iomem *entry_base;
+ unsigned int n, psize;
+ u64 entry_addr;
+ u32 entry2;
+
+ for (n = 0; n < pvu->num_entries * 2; n++) {
+ entry_base = pvu_get_entry_base(pvu, n);
+ entry2 = readl(entry_base + PVU_ENTRY2);
+ if ((entry2 & PVU_ENTRY2_MODE_MASK) != PVU_ENTRY2_VALID)
+ continue;
+
+ entry_addr = readl(entry_base + PVU_ENTRY0);
+ entry_addr |= (u64)(readl(entry_base + PVU_ENTRY1) &
+ PVU_ENTRY1_VBASE_H_MASK) << 32;
+
+ psize = (entry2 >> PVU_ENTRY2_PSIZE_SHIFT) &
+ PVU_ENTRY2_PSIZE_MASK;
+ if (psize >= ARRAY_SIZE(pvu_page_size))
+ continue;
+
+ if (entry_addr >= addr &&
+ (entry_addr + pvu_page_size[psize]) <= (addr + size)) {
+ entry2 &= ~PVU_ENTRY2_MODE_MASK;
+ entry2 |= PVU_ENTRY2_INVALID;
+ writel(entry2, entry_base + PVU_ENTRY2);
+
+ dev_info(&pvu->pdev->dev, "removed TLB entry %d.%d\n",
+ n / pvu->num_entries, n % pvu->num_entries);
+ }
+ }
+}
+
+int ti_pvu_create_region(unsigned int virt_id, const struct resource *region)
+{
+ struct ti_pvu *pvu;
+ int err = 0;
+
+ if (virt_id >= NUM_VIRTIDS)
+ return -EINVAL;
+
+ mutex_lock(&ti_pvu_lock);
+
+ list_for_each_entry(pvu, &ti_pvu_list, entry) {
+ err = pvu_create_region(pvu, region->start,
+ region->end + 1 - region->start);
+ if (err)
+ break;
+ }
+
+ mutex_unlock(&ti_pvu_lock);
+
+ return err;
+}
+
+int ti_pvu_remove_region(unsigned int virt_id, const struct resource *region)
+{
+ struct ti_pvu *pvu;
+
+ if (virt_id >= NUM_VIRTIDS)
+ return -EINVAL;
+
+ mutex_lock(&ti_pvu_lock);
+
+ list_for_each_entry(pvu, &ti_pvu_list, entry) {
+ pvu_remove_region(pvu, region->start,
+ region->end + 1 - region->start);
+ }
+
+ mutex_unlock(&ti_pvu_lock);
+
+ return 0;
+}
+
+static int ti_pvu_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *its_node;
+ void __iomem *base;
+ struct ti_pvu *pvu;
+ u32 val;
+ int ret;
+
+ pvu = devm_kzalloc(dev, sizeof(*pvu), GFP_KERNEL);
+ if (!pvu)
+ return -ENOMEM;
+
+ pvu->pdev = pdev;
+
+ base = devm_platform_ioremap_resource_byname(pdev, "cfg");
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ pvu->cfg = devm_regmap_init_mmio(dev, base, &pvu_cfg_regmap_cfg);
+ if (IS_ERR(pvu->cfg))
+ return dev_err_probe(dev, PTR_ERR(pvu->cfg), "failed to init cfg regmap");
+
+ ret = devm_regmap_field_bulk_alloc(dev, pvu->cfg, pvu->cfg_fields,
+ pvu_cfg_reg_fields, PVU_MAX_CFG_FIELDS);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to alloc cfg regmap fields");
+
+ pvu->num_tlbs = pvu_field_read(pvu, PVU_TLBS);
+ pvu->num_entries = pvu_field_read(pvu, PVU_TLB_ENTRIES);
+ dev_info(dev, "TLBs: %d, entries per TLB: %d\n", pvu->num_tlbs,
+ pvu->num_entries);
+
+ pvu->tlbif_base = devm_platform_ioremap_resource_byname(pdev, "tlbif");
+ if (IS_ERR(pvu->tlbif_base))
+ return PTR_ERR(pvu->tlbif_base);
+
+ its_node = of_find_compatible_node(0, 0, "arm,gic-v3-its");
+ if (its_node) {
+ u32 pre_its_window[2];
+
+ ret = of_property_read_u32_array(its_node,
+ "socionext,synquacer-pre-its",
+ pre_its_window,
+ ARRAY_SIZE(pre_its_window));
+ if (ret) {
+ dev_err(dev, "failed to read pre-its property\n");
+ return ret;
+ }
+
+ ret = pvu_create_region(pvu, pre_its_window[0],
+ pre_its_window[1]);
+ if (ret)
+ return ret;
+ }
+
+ /* Enable the first two TLBs, chaining from 0 to 1 */
+ val = readl(pvu->tlbif_base + PVU_CHAIN);
+ val |= PVU_CHAIN_EN | 1;
+ writel(val, pvu->tlbif_base + PVU_CHAIN);
+
+ val = readl(pvu->tlbif_base + PVU_CHAIN + 0x1000);
+ val |= PVU_CHAIN_EN;
+ writel(val, pvu->tlbif_base + PVU_CHAIN + 0x1000);
+
+ pvu_field_write(pvu, PVU_DMA_CNT, 0);
+ pvu_field_write(pvu, PVU_DMA_CL0, 0);
+ pvu_field_write(pvu, PVU_DMA_CL1, 0);
+ pvu_field_write(pvu, PVU_DMA_CL2, 0);
+ pvu_field_write(pvu, PVU_DMA_CL3, 0);
+ pvu_field_write(pvu, PVU_MAX_VIRTID, NUM_VIRTIDS);
+
+ ret = platform_get_irq(pdev, 0);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to get irq\n");
+
+ ret = devm_request_irq(dev, ret, pvu_fault_isr, 0, dev_name(dev), pvu);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to request irq\n");
+
+ pvu_field_write(pvu, PVU_EXC_ENABLE, 1);
+ pvu_field_write(pvu, PVU_ENABLED, 1);
+
+ dev_set_drvdata(dev, pvu);
+
+ mutex_lock(&ti_pvu_lock);
+ list_add(&pvu->entry, &ti_pvu_list);
+ mutex_unlock(&ti_pvu_lock);
+
+ return 0;
+}
+
+static void ti_pvu_remove(struct platform_device *pdev)
+{
+ struct ti_pvu *pvu = dev_get_drvdata(&pdev->dev);
+
+ mutex_lock(&ti_pvu_lock);
+ list_del(&pvu->entry);
+ mutex_unlock(&ti_pvu_lock);
+}
+
+static const struct of_device_id ti_pvu_of_match[] = {
+ { .compatible = "ti,am654-pvu", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ti_pvu_of_match);
+
+static struct platform_driver ti_pvu_driver = {
+ .driver = {
+ .name = "ti-pvu",
+ .of_match_table = ti_pvu_of_match,
+ },
+ .probe = ti_pvu_probe,
+ .remove = ti_pvu_remove,
+};
+module_platform_driver(ti_pvu_driver);
diff --git a/include/linux/ti-pvu.h b/include/linux/ti-pvu.h
new file mode 100644
index 000000000000..7088da8dad9a
--- /dev/null
+++ b/include/linux/ti-pvu.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * TI Peripheral Virtualization Unit driver for static DMA isolation
+ *
+ * Copyright (c) 2024, Siemens AG
+ */
+
+#ifndef _LINUX_TI_PVU_H
+#define _LINUX_TI_PVU_H
+
+#include <linux/ioport.h>
+
+#if IS_ENABLED(CONFIG_TI_PVU)
+int ti_pvu_create_region(unsigned int virt_id,
+ const struct resource *region);
+int ti_pvu_remove_region(unsigned int virt_id,
+ const struct resource *region);
+#else
+static inline int ti_pvu_create_region(unsigned int virt_id,
+ const struct resource *region)
+{
+ return 0;
+}
+
+static inline int ti_pvu_remove_region(unsigned int virt_id,
+ const struct resource *region)
+{
+ return 0;
+}
+#endif
+
+#endif /* _LINUX_TI_PVU_H */
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v9 (RESEND) 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654
2025-07-16 5:39 ` [PATCH v9 (RESEND) 0/7] " huaqian.li
` (2 preceding siblings ...)
2025-07-16 5:39 ` [PATCH v9 (RESEND) 3/7] soc: ti: Add IOMMU-like PVU driver huaqian.li
@ 2025-07-16 5:39 ` huaqian.li
2025-07-16 7:16 ` Siddharth Vadapalli
2025-07-16 5:39 ` [PATCH v9 (RESEND) 5/7] arm64: dts: ti: k3-am65-main: Add PVU nodes huaqian.li
` (2 subsequent siblings)
6 siblings, 1 reply; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:39 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
The AM654 lacks an IOMMU, thus does not support isolating DMA requests
from untrusted PCI devices to selected memory regions this way. Use
static PVU-based protection instead. The PVU, when enabled, will only
accept DMA requests that address previously configured regions.
Use the availability of a restricted-dma-pool memory region as trigger
and register it as valid DMA target with the PVU. In addition, enable
the mapping of requester IDs to VirtIDs in the PCI RC. Use only a single
VirtID so far, catching all devices.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
drivers/pci/controller/dwc/pci-keystone.c | 106 ++++++++++++++++++++++
1 file changed, 106 insertions(+)
diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
index 2b2632e513b5..fbf1bf43b7ca 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -19,6 +19,7 @@
#include <linux/mfd/syscon.h>
#include <linux/msi.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_pci.h>
#include <linux/phy/phy.h>
@@ -26,6 +27,7 @@
#include <linux/regmap.h>
#include <linux/resource.h>
#include <linux/signal.h>
+#include <linux/ti-pvu.h>
#include "../../pci.h"
#include "pcie-designware.h"
@@ -111,6 +113,16 @@
#define PCI_DEVICE_ID_TI_AM654X 0xb00c
+#define KS_PCI_VIRTID 0
+
+#define PCIE_VMAP_xP_CTRL 0x0
+#define PCIE_VMAP_xP_REQID 0x4
+#define PCIE_VMAP_xP_VIRTID 0x8
+
+#define PCIE_VMAP_xP_CTRL_EN BIT(0)
+
+#define PCIE_VMAP_xP_VIRTID_VID_MASK 0xfff
+
struct ks_pcie_of_data {
enum dw_pcie_device_mode mode;
const struct dw_pcie_host_ops *host_ops;
@@ -1136,6 +1148,94 @@ static const struct of_device_id ks_pcie_of_match[] = {
{ },
};
+static int ks_init_vmap(struct platform_device *pdev, const char *vmap_name)
+{
+ struct resource *res;
+ void __iomem *base;
+ u32 val;
+
+ if (!IS_ENABLED(CONFIG_TI_PVU))
+ return 0;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, vmap_name);
+ base = devm_pci_remap_cfg_resource(&pdev->dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ writel(0, base + PCIE_VMAP_xP_REQID);
+
+ val = readl(base + PCIE_VMAP_xP_VIRTID);
+ val &= ~PCIE_VMAP_xP_VIRTID_VID_MASK;
+ val |= KS_PCI_VIRTID;
+ writel(val, base + PCIE_VMAP_xP_VIRTID);
+
+ val = readl(base + PCIE_VMAP_xP_CTRL);
+ val |= PCIE_VMAP_xP_CTRL_EN;
+ writel(val, base + PCIE_VMAP_xP_CTRL);
+
+ return 0;
+}
+
+static int ks_init_restricted_dma(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct of_phandle_iterator it;
+ struct resource phys;
+ int err;
+
+ if (!IS_ENABLED(CONFIG_TI_PVU))
+ return 0;
+
+ /* Only process the first restricted DMA pool, more are not allowed */
+ of_for_each_phandle(&it, err, dev->of_node, "memory-region",
+ NULL, 0) {
+ if (of_device_is_compatible(it.node, "restricted-dma-pool"))
+ break;
+ }
+ if (err)
+ return err == -ENOENT ? 0 : err;
+
+ err = of_address_to_resource(it.node, 0, &phys);
+ if (err < 0) {
+ dev_err(dev, "failed to parse memory region %pOF: %d\n",
+ it.node, err);
+ return 0;
+ }
+
+ /* Map all incoming requests on low and high prio port to virtID 0 */
+ err = ks_init_vmap(pdev, "vmap_lp");
+ if (err)
+ return err;
+ err = ks_init_vmap(pdev, "vmap_hp");
+ if (err)
+ return err;
+
+ /*
+ * Enforce DMA pool usage with the help of the PVU.
+ * Any request outside will be dropped and raise an error at the PVU.
+ */
+ return ti_pvu_create_region(KS_PCI_VIRTID, &phys);
+}
+
+static void ks_release_restricted_dma(struct platform_device *pdev)
+{
+ struct of_phandle_iterator it;
+ struct resource phys;
+ int err;
+
+ if (!IS_ENABLED(CONFIG_TI_PVU))
+ return;
+
+ of_for_each_phandle(&it, err, pdev->dev.of_node, "memory-region",
+ NULL, 0) {
+ if (of_device_is_compatible(it.node, "restricted-dma-pool") &&
+ of_address_to_resource(it.node, 0, &phys) == 0) {
+ ti_pvu_remove_region(KS_PCI_VIRTID, &phys);
+ break;
+ }
+ }
+}
+
static int ks_pcie_probe(struct platform_device *pdev)
{
const struct dw_pcie_host_ops *host_ops;
@@ -1284,6 +1384,10 @@ static int ks_pcie_probe(struct platform_device *pdev)
if (ret < 0)
goto err_get_sync;
+ ret = ks_init_restricted_dma(pdev);
+ if (ret < 0)
+ goto err_get_sync;
+
switch (mode) {
case DW_PCIE_RC_TYPE:
if (!IS_ENABLED(CONFIG_PCI_KEYSTONE_HOST)) {
@@ -1365,6 +1469,8 @@ static void ks_pcie_remove(struct platform_device *pdev)
int num_lanes = ks_pcie->num_lanes;
struct device *dev = &pdev->dev;
+ ks_release_restricted_dma(pdev);
+
pm_runtime_put(dev);
pm_runtime_disable(dev);
ks_pcie_disable_phy(ks_pcie);
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v9 (RESEND) 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654
2025-07-16 5:39 ` [PATCH v9 (RESEND) 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654 huaqian.li
@ 2025-07-16 7:16 ` Siddharth Vadapalli
0 siblings, 0 replies; 58+ messages in thread
From: Siddharth Vadapalli @ 2025-07-16 7:16 UTC (permalink / raw)
To: huaqian.li
Cc: s-vadapalli, baocheng.su, bhelgaas, conor+dt, devicetree,
diogo.ivo, helgaas, jan.kiszka, kristo, krzk+dt, kw,
linux-arm-kernel, linux-kernel, linux-pci, lpieralisi, nm, robh,
ssantosh, vigneshr
On Wed, Jul 16, 2025 at 01:39:47PM +0800, huaqian.li@siemens.com wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> The AM654 lacks an IOMMU, thus does not support isolating DMA requests
> from untrusted PCI devices to selected memory regions this way. Use
> static PVU-based protection instead. The PVU, when enabled, will only
> accept DMA requests that address previously configured regions.
>
> Use the availability of a restricted-dma-pool memory region as trigger
> and register it as valid DMA target with the PVU. In addition, enable
> the mapping of requester IDs to VirtIDs in the PCI RC. Use only a single
> VirtID so far, catching all devices.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
> ---
> drivers/pci/controller/dwc/pci-keystone.c | 106 ++++++++++++++++++++++
> 1 file changed, 106 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
> index 2b2632e513b5..fbf1bf43b7ca 100644
> --- a/drivers/pci/controller/dwc/pci-keystone.c
> +++ b/drivers/pci/controller/dwc/pci-keystone.c
[------------------email has been trimmed----------------------------]
> +static void ks_release_restricted_dma(struct platform_device *pdev)
> +{
> + struct of_phandle_iterator it;
> + struct resource phys;
> + int err;
> +
> + if (!IS_ENABLED(CONFIG_TI_PVU))
> + return;
> +
> + of_for_each_phandle(&it, err, pdev->dev.of_node, "memory-region",
> + NULL, 0) {
> + if (of_device_is_compatible(it.node, "restricted-dma-pool") &&
> + of_address_to_resource(it.node, 0, &phys) == 0) {
> + ti_pvu_remove_region(KS_PCI_VIRTID, &phys);
> + break;
> + }
> + }
> +}
> +
> static int ks_pcie_probe(struct platform_device *pdev)
> {
> const struct dw_pcie_host_ops *host_ops;
> @@ -1284,6 +1384,10 @@ static int ks_pcie_probe(struct platform_device *pdev)
> if (ret < 0)
> goto err_get_sync;
>
> + ret = ks_init_restricted_dma(pdev);
> + if (ret < 0)
> + goto err_get_sync;
> +
Please move the above into the section specific to RC mode. This has
been agreed to by Jan at:
https://lore.kernel.org/r/e9716614-1849-4524-af4d-20587df365cf@siemens.com/
> switch (mode) {
> case DW_PCIE_RC_TYPE:
> if (!IS_ENABLED(CONFIG_PCI_KEYSTONE_HOST)) {
> @@ -1365,6 +1469,8 @@ static void ks_pcie_remove(struct platform_device *pdev)
> int num_lanes = ks_pcie->num_lanes;
> struct device *dev = &pdev->dev;
>
> + ks_release_restricted_dma(pdev);
> +
Regards,
Siddharth.
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v9 (RESEND) 5/7] arm64: dts: ti: k3-am65-main: Add PVU nodes
2025-07-16 5:39 ` [PATCH v9 (RESEND) 0/7] " huaqian.li
` (3 preceding siblings ...)
2025-07-16 5:39 ` [PATCH v9 (RESEND) 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654 huaqian.li
@ 2025-07-16 5:39 ` huaqian.li
2025-07-16 5:39 ` [PATCH v9 (RESEND) 6/7] arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes huaqian.li
2025-07-16 5:39 ` [PATCH v9 (RESEND) 7/7] arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices behind PCI RC huaqian.li
6 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:39 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
Add nodes for the two PVUs of the AM65. Keep them disabled, though,
because the board has to additionally define DMA pools and the devices
to be isolated.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index b085e7361116..be65e6aa7b80 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -843,6 +843,26 @@ main_cpts_mux: refclk-mux {
assigned-clock-parents = <&k3_clks 118 5>;
};
};
+
+ ti_pvu0: iommu@30f80000 {
+ compatible = "ti,am654-pvu";
+ reg = <0 0x30f80000 0 0x1000>,
+ <0 0x36000000 0 0x100000>;
+ reg-names = "cfg", "tlbif";
+ interrupts-extended = <&intr_main_navss 390>;
+ interrupt-names = "pvu";
+ status = "disabled";
+ };
+
+ ti_pvu1: iommu@30f81000 {
+ compatible = "ti,am654-pvu";
+ reg = <0 0x30f81000 0 0x1000>,
+ <0 0x36100000 0 0x100000>;
+ reg-names = "cfg", "tlbif";
+ interrupts-extended = <&intr_main_navss 389>;
+ interrupt-names = "pvu";
+ status = "disabled";
+ };
};
main_gpio0: gpio@600000 {
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v9 (RESEND) 6/7] arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes
2025-07-16 5:39 ` [PATCH v9 (RESEND) 0/7] " huaqian.li
` (4 preceding siblings ...)
2025-07-16 5:39 ` [PATCH v9 (RESEND) 5/7] arm64: dts: ti: k3-am65-main: Add PVU nodes huaqian.li
@ 2025-07-16 5:39 ` huaqian.li
2025-07-16 5:39 ` [PATCH v9 (RESEND) 7/7] arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices behind PCI RC huaqian.li
6 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:39 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
Rewrap the long lines at this chance.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index be65e6aa7b80..d0036b0aa818 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -897,8 +897,13 @@ main_gpio1: gpio@601000 {
pcie0_rc: pcie@5500000 {
compatible = "ti,am654-pcie-rc";
- reg = <0x0 0x5500000 0x0 0x1000>, <0x0 0x5501000 0x0 0x1000>, <0x0 0x10000000 0x0 0x2000>, <0x0 0x5506000 0x0 0x1000>;
- reg-names = "app", "dbics", "config", "atu";
+ reg = <0x0 0x5500000 0x0 0x1000>,
+ <0x0 0x5501000 0x0 0x1000>,
+ <0x0 0x10000000 0x0 0x2000>,
+ <0x0 0x5506000 0x0 0x1000>,
+ <0x0 0x2900000 0x0 0x1000>,
+ <0x0 0x2908000 0x0 0x1000>;
+ reg-names = "app", "dbics", "config", "atu", "vmap_lp", "vmap_hp";
power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <3>;
#size-cells = <2>;
@@ -918,8 +923,13 @@ pcie0_rc: pcie@5500000 {
pcie1_rc: pcie@5600000 {
compatible = "ti,am654-pcie-rc";
- reg = <0x0 0x5600000 0x0 0x1000>, <0x0 0x5601000 0x0 0x1000>, <0x0 0x18000000 0x0 0x2000>, <0x0 0x5606000 0x0 0x1000>;
- reg-names = "app", "dbics", "config", "atu";
+ reg = <0x0 0x5600000 0x0 0x1000>,
+ <0x0 0x5601000 0x0 0x1000>,
+ <0x0 0x18000000 0x0 0x2000>,
+ <0x0 0x5606000 0x0 0x1000>,
+ <0x0 0x2910000 0x0 0x1000>,
+ <0x0 0x2918000 0x0 0x1000>;
+ reg-names = "app", "dbics", "config", "atu", "vmap_lp", "vmap_hp";
power-domains = <&k3_pds 121 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <3>;
#size-cells = <2>;
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v9 (RESEND) 7/7] arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices behind PCI RC
2025-07-16 5:39 ` [PATCH v9 (RESEND) 0/7] " huaqian.li
` (5 preceding siblings ...)
2025-07-16 5:39 ` [PATCH v9 (RESEND) 6/7] arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes huaqian.li
@ 2025-07-16 5:39 ` huaqian.li
6 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-07-16 5:39 UTC (permalink / raw)
To: s-vadapalli
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo, helgaas,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
Reserve a 64M memory region and ensure that all PCI devices do their DMA
only inside that region. This is configured via a restricted-dma-pool
and enforced with the help of the first PVU.
Applying this isolation is not totally free in terms of overhead and
memory consumption. It makes only sense for variants that support
secure booting, and generally only when this is actually enable.
Therefore model it as overlay that can be activated on demand. The
firmware will take care of this via DT fixup during boot and will also
provide a way to adjust the pool size.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
arch/arm64/boot/dts/ti/Makefile | 5 +++
...am6548-iot2050-advanced-dma-isolation.dtso | 33 +++++++++++++++++++
2 files changed, 38 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index c6171de9fe88..66b1d8093fa2 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -84,8 +84,10 @@ k3-am654-gp-evm-dtbs := k3-am654-base-board.dtb \
k3-am654-evm-dtbs := k3-am654-base-board.dtb k3-am654-icssg2.dtbo
k3-am654-idk-dtbs := k3-am654-evm.dtb k3-am654-idk.dtbo k3-am654-pcie-usb2.dtbo
k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-dtbs := k3-am6548-iot2050-advanced-m2.dtb \
+ k3-am6548-iot2050-advanced-dma-isolation.dtbo \
k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie.dtbo
k3-am6548-iot2050-advanced-m2-bkey-usb3-dtbs := k3-am6548-iot2050-advanced-m2.dtb \
+ k3-am6548-iot2050-advanced-dma-isolation.dtbo \
k3-am6548-iot2050-advanced-m2-bkey-usb3.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic-pg2.dtb
@@ -288,7 +290,10 @@ DTC_FLAGS_k3-am62p5-sk += -@
DTC_FLAGS_k3-am642-evm += -@
DTC_FLAGS_k3-am642-phyboard-electra-rdk += -@
DTC_FLAGS_k3-am642-tqma64xxl-mbax4xxl += -@
+DTC_FLAGS_k3-am6548-iot2050-advanced += -@
DTC_FLAGS_k3-am6548-iot2050-advanced-m2 += -@
+DTC_FLAGS_k3-am6548-iot2050-advanced-pg2 += -@
+DTC_FLAGS_k3-am6548-iot2050-advanced-sm += -@
DTC_FLAGS_k3-am68-sk-base-board += -@
DTC_FLAGS_k3-am69-sk += -@
DTC_FLAGS_k3-j7200-common-proc-board += -@
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
new file mode 100644
index 000000000000..dfd75d2dc245
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * IOT2050, overlay for isolating DMA requests via PVU
+ * Copyright (c) Siemens AG, 2024
+ *
+ * Authors:
+ * Jan Kiszka <jan.kiszka@siemens.com>
+ */
+
+/dts-v1/;
+/plugin/;
+
+&{/reserved-memory} {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pci_restricted_dma_region: restricted-dma@c0000000 {
+ compatible = "restricted-dma-pool";
+ reg = <0 0xc0000000 0 0x4000000>;
+ };
+};
+
+&pcie0_rc {
+ memory-region = <&pci_restricted_dma_region>;
+};
+
+&pcie1_rc {
+ memory-region = <&pci_restricted_dma_region>;
+};
+
+&ti_pvu0 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread
* [PATCH v8 5/7] arm64: dts: ti: k3-am65-main: Add PVU nodes
2025-04-22 6:13 ` [PATCH v8 " huaqian.li
` (3 preceding siblings ...)
2025-04-22 6:14 ` [PATCH v8 4/7] PCI: keystone: Add support for PVU-based DMA isolation on AM654 huaqian.li
@ 2025-04-22 6:14 ` huaqian.li
2025-04-22 6:14 ` [PATCH v8 6/7] arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes huaqian.li
2025-04-22 6:14 ` [PATCH v8 7/7] arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices behind PCI RC huaqian.li
6 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-04-22 6:14 UTC (permalink / raw)
To: helgaas
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
Add nodes for the two PVUs of the AM65. Keep them disabled, though,
because the board has to additionally define DMA pools and the devices
to be isolated.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 94a812a1355b..977c66a3a7c7 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -841,6 +841,26 @@ main_cpts_mux: refclk-mux {
assigned-clock-parents = <&k3_clks 118 5>;
};
};
+
+ ti_pvu0: iommu@30f80000 {
+ compatible = "ti,am654-pvu";
+ reg = <0 0x30f80000 0 0x1000>,
+ <0 0x36000000 0 0x100000>;
+ reg-names = "cfg", "tlbif";
+ interrupts-extended = <&intr_main_navss 390>;
+ interrupt-names = "pvu";
+ status = "disabled";
+ };
+
+ ti_pvu1: iommu@30f81000 {
+ compatible = "ti,am654-pvu";
+ reg = <0 0x30f81000 0 0x1000>,
+ <0 0x36100000 0 0x100000>;
+ reg-names = "cfg", "tlbif";
+ interrupts-extended = <&intr_main_navss 389>;
+ interrupt-names = "pvu";
+ status = "disabled";
+ };
};
main_gpio0: gpio@600000 {
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v8 6/7] arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes
2025-04-22 6:13 ` [PATCH v8 " huaqian.li
` (4 preceding siblings ...)
2025-04-22 6:14 ` [PATCH v8 5/7] arm64: dts: ti: k3-am65-main: Add PVU nodes huaqian.li
@ 2025-04-22 6:14 ` huaqian.li
2025-04-22 6:14 ` [PATCH v8 7/7] arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices behind PCI RC huaqian.li
6 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-04-22 6:14 UTC (permalink / raw)
To: helgaas
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
Rewrap the long lines at this chance.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 977c66a3a7c7..e816c03569ff 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -895,8 +895,13 @@ main_gpio1: gpio@601000 {
pcie0_rc: pcie@5500000 {
compatible = "ti,am654-pcie-rc";
- reg = <0x0 0x5500000 0x0 0x1000>, <0x0 0x5501000 0x0 0x1000>, <0x0 0x10000000 0x0 0x2000>, <0x0 0x5506000 0x0 0x1000>;
- reg-names = "app", "dbics", "config", "atu";
+ reg = <0x0 0x5500000 0x0 0x1000>,
+ <0x0 0x5501000 0x0 0x1000>,
+ <0x0 0x10000000 0x0 0x2000>,
+ <0x0 0x5506000 0x0 0x1000>,
+ <0x0 0x2900000 0x0 0x1000>,
+ <0x0 0x2908000 0x0 0x1000>;
+ reg-names = "app", "dbics", "config", "atu", "vmap_lp", "vmap_hp";
power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <3>;
#size-cells = <2>;
@@ -916,8 +921,13 @@ pcie0_rc: pcie@5500000 {
pcie1_rc: pcie@5600000 {
compatible = "ti,am654-pcie-rc";
- reg = <0x0 0x5600000 0x0 0x1000>, <0x0 0x5601000 0x0 0x1000>, <0x0 0x18000000 0x0 0x2000>, <0x0 0x5606000 0x0 0x1000>;
- reg-names = "app", "dbics", "config", "atu";
+ reg = <0x0 0x5600000 0x0 0x1000>,
+ <0x0 0x5601000 0x0 0x1000>,
+ <0x0 0x18000000 0x0 0x2000>,
+ <0x0 0x5606000 0x0 0x1000>,
+ <0x0 0x2910000 0x0 0x1000>,
+ <0x0 0x2918000 0x0 0x1000>;
+ reg-names = "app", "dbics", "config", "atu", "vmap_lp", "vmap_hp";
power-domains = <&k3_pds 121 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <3>;
#size-cells = <2>;
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v8 7/7] arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices behind PCI RC
2025-04-22 6:13 ` [PATCH v8 " huaqian.li
` (5 preceding siblings ...)
2025-04-22 6:14 ` [PATCH v8 6/7] arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes huaqian.li
@ 2025-04-22 6:14 ` huaqian.li
6 siblings, 0 replies; 58+ messages in thread
From: huaqian.li @ 2025-04-22 6:14 UTC (permalink / raw)
To: helgaas
Cc: baocheng.su, bhelgaas, conor+dt, devicetree, diogo.ivo,
huaqian.li, jan.kiszka, kristo, krzk+dt, kw, linux-arm-kernel,
linux-kernel, linux-pci, lpieralisi, nm, robh, s-vadapalli,
ssantosh, vigneshr
From: Jan Kiszka <jan.kiszka@siemens.com>
Reserve a 64M memory region and ensure that all PCI devices do their DMA
only inside that region. This is configured via a restricted-dma-pool
and enforced with the help of the first PVU.
Applying this isolation is not totally free in terms of overhead and
memory consumption. It makes only sense for variants that support
secure booting, and generally only when this is actually enable.
Therefore model it as overlay that can be activated on demand. The
firmware will take care of this via DT fixup during boot and will also
provide a way to adjust the pool size.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Li Hua Qian <huaqian.li@siemens.com>
---
arch/arm64/boot/dts/ti/Makefile | 5 +++
...am6548-iot2050-advanced-dma-isolation.dtso | 33 +++++++++++++++++++
2 files changed, 38 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 03d4cecfc001..12c2cee955f2 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -73,8 +73,10 @@ k3-am654-gp-evm-dtbs := k3-am654-base-board.dtb \
k3-am654-evm-dtbs := k3-am654-base-board.dtb k3-am654-icssg2.dtbo
k3-am654-idk-dtbs := k3-am654-evm.dtb k3-am654-idk.dtbo k3-am654-pcie-usb2.dtbo
k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-dtbs := k3-am6548-iot2050-advanced-m2.dtb \
+ k3-am6548-iot2050-advanced-dma-isolation.dtbo \
k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie.dtbo
k3-am6548-iot2050-advanced-m2-bkey-usb3-dtbs := k3-am6548-iot2050-advanced-m2.dtb \
+ k3-am6548-iot2050-advanced-dma-isolation.dtbo \
k3-am6548-iot2050-advanced-m2-bkey-usb3.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic-pg2.dtb
@@ -261,7 +263,10 @@ DTC_FLAGS_k3-am62p5-sk += -@
DTC_FLAGS_k3-am642-evm += -@
DTC_FLAGS_k3-am642-phyboard-electra-rdk += -@
DTC_FLAGS_k3-am642-tqma64xxl-mbax4xxl += -@
+DTC_FLAGS_k3-am6548-iot2050-advanced += -@
DTC_FLAGS_k3-am6548-iot2050-advanced-m2 += -@
+DTC_FLAGS_k3-am6548-iot2050-advanced-pg2 += -@
+DTC_FLAGS_k3-am6548-iot2050-advanced-sm += -@
DTC_FLAGS_k3-am68-sk-base-board += -@
DTC_FLAGS_k3-am69-sk += -@
DTC_FLAGS_k3-j7200-common-proc-board += -@
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
new file mode 100644
index 000000000000..dfd75d2dc245
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * IOT2050, overlay for isolating DMA requests via PVU
+ * Copyright (c) Siemens AG, 2024
+ *
+ * Authors:
+ * Jan Kiszka <jan.kiszka@siemens.com>
+ */
+
+/dts-v1/;
+/plugin/;
+
+&{/reserved-memory} {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pci_restricted_dma_region: restricted-dma@c0000000 {
+ compatible = "restricted-dma-pool";
+ reg = <0 0xc0000000 0 0x4000000>;
+ };
+};
+
+&pcie0_rc {
+ memory-region = <&pci_restricted_dma_region>;
+};
+
+&pcie1_rc {
+ memory-region = <&pci_restricted_dma_region>;
+};
+
+&ti_pvu0 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [PATCH v7 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation
2025-04-18 7:30 ` [PATCH v7 0/8] " huaqian.li
` (8 preceding siblings ...)
2025-04-18 13:43 ` [PATCH v7 0/8] soc: ti: Add and use PVU on K3-AM65 for DMA isolation Nishanth Menon
@ 2025-04-21 15:07 ` Rob Herring (Arm)
9 siblings, 0 replies; 58+ messages in thread
From: Rob Herring (Arm) @ 2025-04-21 15:07 UTC (permalink / raw)
To: huaqian.li
Cc: helgaas, linux-arm-kernel, linux-kernel, vigneshr, devicetree, kw,
iommu, nm, bhelgaas, baocheng.su, jan.kiszka, conor+dt,
lpieralisi, diogo.ivo, kristo, m.szyprowski, robin.murphy,
ssantosh, s-vadapalli, krzk+dt, linux-pci
On Fri, 18 Apr 2025 15:30:18 +0800, huaqian.li@siemens.com wrote:
> From: Li Hua Qian <huaqian.li@siemens.com>
>
> Changes in v7:
> - add schema expressing dependency as suggested on pci-host bindings
> - resolve review comments on pci-keystone driver
> - add a new patch to make IO_TLB_SEGSIZE configurable
> - improve patches based on checkpath.pl
>
> Changes in v6:
> - make restricted DMA memory-region available to all pci-keystone
> devices, moving property to unconditional section (patch 2)
>
> Changes in v5:
> - resolve review comments on pci-host bindings
> - reduce DMA memory regions to 1 - swiotlb does not support more
> - move activation into overlay (controlled via firmware)
> - use ks_init_vmap helper instead of loop in
> rework ks_init_restricted_dma
> - add more comments to pci-keystone
> - use 2 chained TLBs of PVU to support maximum of swiotlb (320 MB)
>
> Changes in v4:
> - reorder patch queue, moving all DTS changes to the back
> - limit activation to IOT2050 Advanced variants
> - move DMA pool to allow firmware-based expansion it up to 512M
>
> Changes in v3:
> - fix ti,am654-pvu.yaml according to review comments
> - address review comments on ti,am65-pci-host.yaml
> - differentiate between different compatibles in ti,am65-pci-host.yaml
> - move pvu nodes to k3-am65-main.dtsi
> - reorder patch series, pulling bindings and generic DT bits to the front
>
> Changes in v2:
> - fix dt_bindings_check issues (patch 1)
> - address first review comments (patch 2)
> - extend ti,am65-pci-host bindings for PVU (new patch 3)
>
> Only few of the K3 SoCs have an IOMMU and, thus, can isolate the system
> against DMA-based attacks of external PCI devices. The AM65 is without
> an IOMMU, but it comes with something close to it: the Peripheral
> Virtualization Unit (PVU).
>
> The PVU was originally designed to establish static compartments via a
> hypervisor, isolate those DMA-wise against each other and the host and
> even allow remapping of guest-physical addresses. But it only provides
> a static translation region, not page-granular mappings. Thus, it cannot
> be handled transparently like an IOMMU.
>
> Now, to use the PVU for the purpose of isolated PCI devices from the
> Linux host, this series takes a different approach. It defines a
> restricted-dma-pool for the PCI host, using swiotlb to map all DMA
> buffers from a static memory carve-out. And to enforce that the devices
> actually follow this, a special PVU soc driver is introduced. The driver
> permits access to the GIC ITS and otherwise waits for other drivers that
> detect devices with constrained DMA to register pools with the PVU.
>
> For the AM65, the first (and possibly only) driver where this is
> introduced is the pci-keystone host controller. Finally, this series
> provides a DT overlay for the IOT2050 Advanced devices (all have
> MiniPCIe or M.2 extension slots) to make use of this protection scheme.
> Application of this overlay will be handled by firmware.
>
> Due to the cross-cutting nature of these changes, multiple subsystems
> are affected. However, I wanted to present the whole thing in one series
> to allow everyone to review with the complete picture in hands. If
> preferred, I can also split the series up, of course.
>
> Jan
>
>
> Jan Kiszka (7):
> dt-bindings: soc: ti: Add AM65 peripheral virtualization unit
> dt-bindings: PCI: ti,am65: Extend for use with PVU
> soc: ti: Add IOMMU-like PVU driver
> PCI: keystone: Add support for PVU-based DMA isolation on AM654
> arm64: dts: ti: k3-am65-main: Add PVU nodes
> arm64: dts: ti: k3-am65-main: Add VMAP registers to PCI root complexes
> arm64: dts: ti: iot2050: Add overlay for DMA isolation for devices
> behind PCI RC
>
> Li Hua Qian (1):
> swiotlb: Make IO_TLB_SEGSIZE configurable
>
> .../bindings/pci/ti,am65-pci-host.yaml | 34 +-
> .../bindings/soc/ti/ti,am654-pvu.yaml | 51 ++
> arch/arm64/boot/dts/ti/Makefile | 5 +
> arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 38 +-
> ...am6548-iot2050-advanced-dma-isolation.dtso | 33 ++
> drivers/pci/controller/dwc/pci-keystone.c | 106 ++++
> drivers/soc/ti/Kconfig | 4 +
> drivers/soc/ti/Makefile | 1 +
> drivers/soc/ti/ti-pvu.c | 500 ++++++++++++++++++
> include/linux/swiotlb.h | 2 +-
> include/linux/ti-pvu.h | 28 +
> kernel/dma/Kconfig | 7 +
> 12 files changed, 801 insertions(+), 8 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,am654-pvu.yaml
> create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-dma-isolation.dtso
> create mode 100644 drivers/soc/ti/ti-pvu.c
> create mode 100644 include/linux/ti-pvu.h
>
> --
> 2.34.1
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
This patch series was applied (using b4) to base:
Base: attempting to guess base-commit...
Base: tags/next-20250417 (exact match)
If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)
New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/ti/' for 20250418073026.2418728-1-huaqian.li@siemens.com:
arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-pg2.dtb: pcie@5600000 (ti,am654-pcie-rc): 'memory-region' is a required property
from schema $id: http://devicetree.org/schemas/pci/ti,am65-pci-host.yaml#
arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dtb: pcie@5600000 (ti,am654-pcie-rc): 'memory-region' is a required property
from schema $id: http://devicetree.org/schemas/pci/ti,am65-pci-host.yaml#
arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dtb: pcie@5500000 (ti,am654-pcie-rc): 'memory-region' is a required property
from schema $id: http://devicetree.org/schemas/pci/ti,am65-pci-host.yaml#
arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dtb: pcie@5600000 (ti,am654-pcie-rc): 'memory-region' is a required property
from schema $id: http://devicetree.org/schemas/pci/ti,am65-pci-host.yaml#
arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dtb: pcie@5600000 (ti,am654-pcie-rc): 'memory-region' is a required property
from schema $id: http://devicetree.org/schemas/pci/ti,am65-pci-host.yaml#
arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dtb: pcie@5500000 (ti,am654-pcie-rc): 'memory-region' is a required property
from schema $id: http://devicetree.org/schemas/pci/ti,am65-pci-host.yaml#
^ permalink raw reply [flat|nested] 58+ messages in thread