[PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameer Kolothum]

On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
deviates from the standard implementation and this breaks PCIe MSI
functionality when SMMU is enabled.

The HiSilicon erratum 161010801 describes this limitation of certain
HiSilicon platforms to support the SMMU mappings for MSI transactions.
On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCIe controller on this platforms has to differentiate the MSI
payload against other DMA payload and has to modify the MSI payload.
This basically makes it difficult for this platforms to have a SMMU
translation for MSI.

This patch implements an ACPI based quirk to reserve the hw msi regions
in the smmu-v3 driver which means these address regions will not be
translated and will be excluded from iova allocations.

To implement this quirk, the following changes are incorporated:
1. Added a generic helper function to IORT code to retrieve and reserve
   the associated ITS base address from a device IORT node. The function
   has a check for smmu model to determine whether the platform requires
   the HW MSI reservation or not.
2. Added smmu node entries and explicitly disabled them in hip06/hip07
    dts files so that users are warned about the non-DT support for this
    erratum.

Changelog:

v11--> v12
-Thanks to Lorenzo, Fixed !CONFIG_IOMMU_API compile error(patch #1).

v10 --> v11
-Addressed comments from Lorenzo(patch#1)
-Added Robin's Reviewed-by to patch #2

v9 --> v10
Addressed comments:
-Moved smmu model check to iort helper function to selectively apply
 the msi reservation which will make the fn call generic from iommu-dma.
-Removed PCI blacklisting patch, instead added smmu nodes(disabled)
 with comments to hip06/hip07 dts file.

v8 --> v9
-Thanks to Marc, fixed IORT helper function to reserve the ITS
 translater region only.
-Removed the DT support for MSI reservation and blacklisted
 HiSilicon PCIe controllers on DT based systems when SMMUv3 is
 enabled.

v7 --> v8
Addressed comments from Rob and Lorenzo:
 -Modified to use DT compatible string for errata.
 -Changed logic to retrieve the msi-parent for DT case.

v6 --> v7
Addressed request from Will to add DT support for the erratum:
 - added bt binding
 - add of_iommu_msi_get_resv_regions()
New arm64 silicon errata entry
Rename iort_iommu_{its->msi}_get_resv_regions

v5 --> v6
Addressed comments from Robin and Lorenzo:
-No change to patch#1 .
-Reverted v5 patch#2 as this might break the platforms where this quirk
  is not applicable. Provided a generic function in iommu code and added
  back the quirk implementation in SMMU v3 driver(patch#3)

v4 --> v5
Addressed comments from Robin and Lorenzo:
-Added a comment to make it clear that, for now, only straightforward
  HW topologies are handled while reserving ITS regions(patch #1).

v3 --> v4
Rebased on 4.13-rc1.
Addressed comments from Robin, Will and Lorenzo:
-As suggested by Robin, moved the ITS msi reservation into
  iommu_dma_get_resv_regions().
-Added its_count != resv region failure case(patch #1).

v2 --> v3
Addressed comments from Lorenzo and Robin:
-Removed dev_is_pci() check in smmuV3 driver.
-Don't treat device not having an ITS mapping as an error in
  iort helper function.

v1 --> v2
-patch 2/2: Invoke iort helper fn based on fwnode type(acpi).

RFCv2 -->PATCH
-Incorporated Lorenzo's review comments.

RFC v1 --> RFC v2
Based on Robin's review comments,
-Removed  the generic erratum framework.
-Using IORT/MADT tables to retrieve the ITS base addr instead
 of vendor specific CSRT table.

Shameer Kolothum (3):
  ACPI/IORT: Add msi address regions reservation helper
  iommu/dma: Add HW MSI(GICv3 ITS) address regions reservation
  arm64:dts:hisilicon Disable hisilicon smmu node on hip06/hip07

 arch/arm64/boot/dts/hisilicon/hip06.dtsi |  56 ++++++++++++++++
 arch/arm64/boot/dts/hisilicon/hip07.dtsi |  25 +++++++
 drivers/acpi/arm64/iort.c                | 111 ++++++++++++++++++++++++++++++-
 drivers/iommu/dma-iommu.c                |   8 ++-
 drivers/irqchip/irq-gic-v3-its.c         |   3 +-
 include/linux/acpi_iort.h                |   7 +-
 6 files changed, 204 insertions(+), 6 deletions(-)

-- 
1.9.1

[PATCH v12 1/3] ACPI/IORT: Add msi address regions reservation helper

[Shameer Kolothum]

On some platforms msi parent address regions have to be excluded from
normal IOVA allocation in that they are detected and decoded in a HW
specific way by system components and so they cannot be considered normal
IOVA address space.

Add a helper function that retrieves ITS address regions - the msi
parent - through IORT device <-> ITS mappings and reserves it so that
these regions will not be translated by IOMMU and will be excluded from
IOVA allocations. The function checks for the smmu model number and
only applies the msi reservation if the platform requires it.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
 drivers/acpi/arm64/iort.c        | 111 +++++++++++++++++++++++++++++++++++++--
 drivers/irqchip/irq-gic-v3-its.c |   3 +-
 include/linux/acpi_iort.h        |   7 ++-
 3 files changed, 116 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 95255ec..e2f7bdd 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -39,6 +39,7 @@
 struct iort_its_msi_chip {
 	struct list_head	list;
 	struct fwnode_handle	*fw_node;
+	phys_addr_t		base_addr;
 	u32			translation_id;
 };
 
@@ -161,14 +162,16 @@ typedef acpi_status (*iort_find_node_callback)
 static DEFINE_SPINLOCK(iort_msi_chip_lock);
 
 /**
- * iort_register_domain_token() - register domain token and related ITS ID
- * to the list from where we can get it back later on.
+ * iort_register_domain_token() - register domain token along with related
+ * ITS ID and base address to the list from where we can get it back later on.
  * @trans_id: ITS ID.
+ * @base: ITS base address.
  * @fw_node: Domain token.
  *
  * Returns: 0 on success, -ENOMEM if no memory when allocating list element
  */
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
+int iort_register_domain_token(int trans_id, phys_addr_t base,
+			       struct fwnode_handle *fw_node)
 {
 	struct iort_its_msi_chip *its_msi_chip;
 
@@ -178,6 +181,7 @@ int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
 
 	its_msi_chip->fw_node = fw_node;
 	its_msi_chip->translation_id = trans_id;
+	its_msi_chip->base_addr = base;
 
 	spin_lock(&iort_msi_chip_lock);
 	list_add(&its_msi_chip->list, &iort_msi_chip_list);
@@ -581,6 +585,24 @@ int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
 	return -ENODEV;
 }
 
+static int __maybe_unused iort_find_its_base(u32 its_id, phys_addr_t *base)
+{
+	struct iort_its_msi_chip *its_msi_chip;
+	int ret = -ENODEV;
+
+	spin_lock(&iort_msi_chip_lock);
+	list_for_each_entry(its_msi_chip, &iort_msi_chip_list, list) {
+		if (its_msi_chip->translation_id == its_id) {
+			*base = its_msi_chip->base_addr;
+			ret = 0;
+			break;
+		}
+	}
+	spin_unlock(&iort_msi_chip_lock);
+
+	return ret;
+}
+
 /**
  * iort_dev_find_its_id() - Find the ITS identifier for a device
  * @dev: The device.
@@ -766,6 +788,24 @@ static inline bool iort_iommu_driver_enabled(u8 type)
 }
 
 #ifdef CONFIG_IOMMU_API
+static struct acpi_iort_node *iort_get_msi_resv_iommu(struct device *dev)
+{
+	struct acpi_iort_node *iommu;
+	struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+	iommu = iort_get_iort_node(fwspec->iommu_fwnode);
+
+	if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
+		struct acpi_iort_smmu_v3 *smmu;
+
+		smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
+		if (smmu->model == ACPI_IORT_SMMU_V3_HISILICON_HI161X)
+			return iommu;
+	}
+
+	return NULL;
+}
+
 static inline const struct iommu_ops *iort_fwspec_iommu_ops(
 				struct iommu_fwspec *fwspec)
 {
@@ -782,6 +822,69 @@ static inline int iort_add_device_replay(const struct iommu_ops *ops,
 
 	return err;
 }
+
+/**
+ * iort_iommu_msi_get_resv_regions - Reserved region driver helper
+ * @dev: Device from iommu_get_resv_regions()
+ * @head: Reserved region list from iommu_get_resv_regions()
+ *
+ * Returns: Number of msi reserved regions on success (0 if platform
+ *          doesn't require the reservation or no associated msi regions),
+ *          appropriate error value otherwise. The ITS interrupt translation
+ *          spaces (ITS_base + SZ_64K, SZ_64K) associated with the device
+ *          are the msi reserved regions.
+ */
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{
+	struct acpi_iort_its_group *its;
+	struct acpi_iort_node *iommu_node, *its_node = NULL;
+	int i, resv = 0;
+
+	iommu_node = iort_get_msi_resv_iommu(dev);
+	if (!iommu_node)
+		return 0;
+
+	/*
+	 * Current logic to reserve ITS regions relies on HW topologies
+	 * where a given PCI or named component maps its IDs to only one
+	 * ITS group; if a PCI or named component can map its IDs to
+	 * different ITS groups through IORT mappings this function has
+	 * to be reworked to ensure we reserve regions for all ITS groups
+	 * a given PCI or named component may map IDs to.
+	 */
+
+	for (i = 0; i < dev->iommu_fwspec->num_ids; i++) {
+		its_node = iort_node_map_id(iommu_node,
+					dev->iommu_fwspec->ids[i],
+					NULL, IORT_MSI_TYPE);
+		if (its_node)
+			break;
+	}
+
+	if (!its_node)
+		return 0;
+
+	/* Move to ITS specific data */
+	its = (struct acpi_iort_its_group *)its_node->node_data;
+
+	for (i = 0; i < its->its_count; i++) {
+		phys_addr_t base;
+
+		if (!iort_find_its_base(its->identifiers[i], &base)) {
+			int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+			struct iommu_resv_region *region;
+
+			region = iommu_alloc_resv_region(base + SZ_64K, SZ_64K,
+							 prot, IOMMU_RESV_MSI);
+			if (region) {
+				list_add_tail(&region->list, head);
+				resv++;
+			}
+		}
+	}
+
+	return (resv == its->its_count) ? resv : -ENODEV;
+}
 #else
 static inline const struct iommu_ops *iort_fwspec_iommu_ops(
 				struct iommu_fwspec *fwspec)
@@ -789,6 +892,8 @@ static inline const struct iommu_ops *iort_fwspec_iommu_ops(
 static inline int iort_add_device_replay(const struct iommu_ops *ops,
 					 struct device *dev)
 { return 0; }
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{ return 0; }
 #endif
 
 static int iort_iommu_xlate(struct device *dev, struct acpi_iort_node *node,
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 4039e64..d4cff12 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3450,7 +3450,8 @@ static int __init gic_acpi_parse_madt_its(struct acpi_subtable_header *header,
 		return -ENOMEM;
 	}
 
-	err = iort_register_domain_token(its_entry->translation_id, dom_handle);
+	err = iort_register_domain_token(its_entry->translation_id, res.start,
+					 dom_handle);
 	if (err) {
 		pr_err("ITS@%pa: Unable to register GICv3 ITS domain token (ITS ID %d) to IORT\n",
 		       &res.start, its_entry->translation_id);
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 2f7a292..38cd77b 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -26,7 +26,8 @@
 #define IORT_IRQ_MASK(irq)		(irq & 0xffffffffULL)
 #define IORT_IRQ_TRIGGER_MASK(irq)	((irq >> 32) & 0xffffffffULL)
 
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node);
+int iort_register_domain_token(int trans_id, phys_addr_t base,
+			       struct fwnode_handle *fw_node);
 void iort_deregister_domain_token(int trans_id);
 struct fwnode_handle *iort_find_domain_token(int trans_id);
 #ifdef CONFIG_ACPI_IORT
@@ -38,6 +39,7 @@
 /* IOMMU interface */
 void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *size);
 const struct iommu_ops *iort_iommu_configure(struct device *dev);
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
 #else
 static inline void acpi_iort_init(void) { }
 static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
@@ -52,6 +54,9 @@ static inline void iort_dma_setup(struct device *dev, u64 *dma_addr,
 static inline const struct iommu_ops *iort_iommu_configure(
 				      struct device *dev)
 { return NULL; }
+static inline
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{ return 0; }
 #endif
 
 #endif /* __ACPI_IORT_H__ */
-- 
1.9.1

[PATCH v12 2/3] iommu/dma: Add HW MSI(GICv3 ITS) address regions reservation

[Shameer Kolothum]

Modified iommu_dma_get_resv_regions() to include GICv3 ITS
region on ACPI based ARM platfiorms which may require HW MSI
reservations.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Reviewed-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
---
 drivers/iommu/dma-iommu.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 25914d3..f05f3cf 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -19,6 +19,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/acpi_iort.h>
 #include <linux/device.h>
 #include <linux/dma-iommu.h>
 #include <linux/gfp.h>
@@ -167,13 +168,18 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
  *
  * IOMMU drivers can use this to implement their .get_resv_regions callback
  * for general non-IOMMU-specific reservations. Currently, this covers host
- * bridge windows for PCI devices.
+ * bridge windows for PCI devices and GICv3 ITS region reservation on ACPI
+ * based ARM platforms that may require HW MSI reservation.
  */
 void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
 {
 	struct pci_host_bridge *bridge;
 	struct resource_entry *window;
 
+	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode) &&
+		iort_iommu_msi_get_resv_regions(dev, list) < 0)
+		return;
+
 	if (!dev_is_pci(dev))
 		return;
 
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v12 3/3] arm64:dts:hisilicon Disable hisilicon smmu node on hip06/hip07

[Shameer Kolothum]

The HiSilicon erratum 161010801 describes the limitation of
HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
for MSI transactions.

PCIe controller on these platforms has to differentiate the
MSI payload against other DMA payload and has to modify the
MSI  payload. This makes it difficult for these platforms to
have SMMU translation for MSI. In order to workaround this,
ARM SMMUv3 driver requires a quirk to treat the MSI regions
separately. Such a quirk is currently missing for DT based
systems and therefore we need to explicitly disable the
hip06/hip07 smmu entries in dts.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
---
 arch/arm64/boot/dts/hisilicon/hip06.dtsi | 56 ++++++++++++++++++++++++++++++++
 arch/arm64/boot/dts/hisilicon/hip07.dtsi | 25 ++++++++++++++
 2 files changed, 81 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index a049b64..35202eb 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -291,6 +291,13 @@
 			#interrupt-cells = <2>;
 			num-pins = <128>;
 		};
+
+		mbigen_pcie0: intc_pcie0 {
+			msi-parent = <&its_dsa 0x40085>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			num-pins = <10>;
+		};
 	};
 
 	mbigen_dsa@c0080000 {
@@ -312,6 +319,31 @@
 		};
 	};
 
+	/**
+	 *  HiSilicon erratum 161010801: This describes the limitation
+	 *  of HiSilicon platforms hip06/hip07 to support the SMMUv3
+	 *  mappings for PCIe MSI transactions.
+	 *  PCIe controller on these platforms has to differentiate the
+	 *  MSI payload against other DMA payload and has to modify the
+	 *  MSI payload. This makes it difficult for these platforms to
+	 *  have a SMMU translation for MSI. In order to workaround this,
+	 *  ARM SMMUv3 driver requires a quirk to treat the MSI regions
+	 *  separately. Such a quirk is currently missing for DT based
+	 *  systems. Hence please make sure that the smmu pcie node on
+	 *  hip06 is disabled as this will break the PCIe functionality
+	 *  when iommu-map entry is used along with the PCIe node.
+	 *  Refer:https://www.spinics.net/lists/arm-kernel/msg602812.html
+	 */
+	smmu0: smmu_pcie {
+		compatible = "arm,smmu-v3";
+		reg = <0x0 0xa0040000 0x0 0x20000>;
+		#iommu-cells = <1>;
+		dma-coherent;
+		smmu-cb-memtype = <0x0 0x1>;
+		hisilicon,broken-prefetch-cmd;
+		status = "disabled";
+	};
+
 	soc {
 		compatible = "simple-bus";
 		#address-cells = <2>;
@@ -676,6 +708,30 @@
 				     <637 1>,<638 1>,<639 1>;
 			status = "disabled";
 		};
+
+		pcie0: pcie@a0090000 {
+			compatible = "hisilicon,hip06-pcie-ecam";
+			reg = <0 0xb0000000 0 0x2000000>,
+			      <0 0xa0090000 0 0x10000>;
+			bus-range = <0  31>;
+			msi-map = <0x0000 &its_dsa 0x0000 0x2000>;
+			msi-map-mask = <0xffff>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			dma-coherent;
+			ranges = <0x02000000 0 0xb2000000 0x0 0xb2000000 0
+				 0x5ff0000 0x01000000 0 0 0 0xb7ff0000
+				 0 0x10000>;
+			#interrupt-cells = <1>;
+			interrupt-map-mask = <0xf800 0 0 7>;
+			interrupt-map = <0x0 0 0 1 &mbigen_pcie0 650 4
+					0x0 0 0 2 &mbigen_pcie0 650 4
+					0x0 0 0 3 &mbigen_pcie0 650 4
+					0x0 0 0 4 &mbigen_pcie0 650 4>;
+			status = "disabled";
+		};
+
 	};
 
 };
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 2c01a21..3e80bf3 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1083,6 +1083,31 @@
 		};
 	};
 
+	/**
+	 *  HiSilicon erratum 161010801: This describes the limitation
+	 *  of HiSilicon platforms hip06/hip07 to support the SMMUv3
+	 *  mappings for PCIe MSI transactions.
+	 *  PCIe controller on these platforms has to differentiate the
+	 *  MSI payload against other DMA payload and has to modify the
+	 *  MSI payload. This makes it difficult for these platforms to
+	 *  have a SMMU translation for MSI. In order to workaround this,
+	 *  ARM SMMUv3 driver requires a quirk to treat the MSI regions
+	 *  separately. Such a quirk is currently missing for DT based
+	 *  systems. Hence please make sure that the smmu pcie node on
+	 *  hip07 is disabled as this will break the PCIe functionality
+	 *  when iommu-map entry is used along with the PCIe node.
+	 *  Refer:https://www.spinics.net/lists/arm-kernel/msg602812.html
+	 */
+	smmu0: smmu_pcie {
+		compatible = "arm,smmu-v3";
+		reg = <0x0 0xa0040000 0x0 0x20000>;
+		#iommu-cells = <1>;
+		dma-coherent;
+		smmu-cb-memtype = <0x0 0x1>;
+		hisilicon,broken-prefetch-cmd;
+		status = "disabled";
+	};
+
 	soc {
 		compatible = "simple-bus";
 		#address-cells = <2>;
-- 
1.9.1

Re: [PATCH v12 1/3] ACPI/IORT: Add msi address regions reservation helper

[Lorenzo Pieralisi]

On Thu, Dec 14, 2017 at 04:09:55PM +0000, Shameer Kolothum wrote:
> On some platforms msi parent address regions have to be excluded from
> normal IOVA allocation in that they are detected and decoded in a HW
> specific way by system components and so they cannot be considered normal
> IOVA address space.
> 
> Add a helper function that retrieves ITS address regions - the msi
> parent - through IORT device <-> ITS mappings and reserves it so that
> these regions will not be translated by IOMMU and will be excluded from
> IOVA allocations. The function checks for the smmu model number and
> only applies the msi reservation if the platform requires it.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/acpi/arm64/iort.c        | 111 +++++++++++++++++++++++++++++++++++++--
>  drivers/irqchip/irq-gic-v3-its.c |   3 +-
>  include/linux/acpi_iort.h        |   7 ++-
>  3 files changed, 116 insertions(+), 5 deletions(-)

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 95255ec..e2f7bdd 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -39,6 +39,7 @@
>  struct iort_its_msi_chip {
>  	struct list_head	list;
>  	struct fwnode_handle	*fw_node;
> +	phys_addr_t		base_addr;
>  	u32			translation_id;
>  };
>  
> @@ -161,14 +162,16 @@ typedef acpi_status (*iort_find_node_callback)
>  static DEFINE_SPINLOCK(iort_msi_chip_lock);
>  
>  /**
> - * iort_register_domain_token() - register domain token and related ITS ID
> - * to the list from where we can get it back later on.
> + * iort_register_domain_token() - register domain token along with related
> + * ITS ID and base address to the list from where we can get it back later on.
>   * @trans_id: ITS ID.
> + * @base: ITS base address.
>   * @fw_node: Domain token.
>   *
>   * Returns: 0 on success, -ENOMEM if no memory when allocating list element
>   */
> -int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
> +int iort_register_domain_token(int trans_id, phys_addr_t base,
> +			       struct fwnode_handle *fw_node)
>  {
>  	struct iort_its_msi_chip *its_msi_chip;
>  
> @@ -178,6 +181,7 @@ int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
>  
>  	its_msi_chip->fw_node = fw_node;
>  	its_msi_chip->translation_id = trans_id;
> +	its_msi_chip->base_addr = base;
>  
>  	spin_lock(&iort_msi_chip_lock);
>  	list_add(&its_msi_chip->list, &iort_msi_chip_list);
> @@ -581,6 +585,24 @@ int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
>  	return -ENODEV;
>  }
>  
> +static int __maybe_unused iort_find_its_base(u32 its_id, phys_addr_t *base)
> +{
> +	struct iort_its_msi_chip *its_msi_chip;
> +	int ret = -ENODEV;
> +
> +	spin_lock(&iort_msi_chip_lock);
> +	list_for_each_entry(its_msi_chip, &iort_msi_chip_list, list) {
> +		if (its_msi_chip->translation_id == its_id) {
> +			*base = its_msi_chip->base_addr;
> +			ret = 0;
> +			break;
> +		}
> +	}
> +	spin_unlock(&iort_msi_chip_lock);
> +
> +	return ret;
> +}
> +
>  /**
>   * iort_dev_find_its_id() - Find the ITS identifier for a device
>   * @dev: The device.
> @@ -766,6 +788,24 @@ static inline bool iort_iommu_driver_enabled(u8 type)
>  }
>  
>  #ifdef CONFIG_IOMMU_API
> +static struct acpi_iort_node *iort_get_msi_resv_iommu(struct device *dev)
> +{
> +	struct acpi_iort_node *iommu;
> +	struct iommu_fwspec *fwspec = dev->iommu_fwspec;
> +
> +	iommu = iort_get_iort_node(fwspec->iommu_fwnode);
> +
> +	if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
> +		struct acpi_iort_smmu_v3 *smmu;
> +
> +		smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
> +		if (smmu->model == ACPI_IORT_SMMU_V3_HISILICON_HI161X)
> +			return iommu;
> +	}
> +
> +	return NULL;
> +}
> +
>  static inline const struct iommu_ops *iort_fwspec_iommu_ops(
>  				struct iommu_fwspec *fwspec)
>  {
> @@ -782,6 +822,69 @@ static inline int iort_add_device_replay(const struct iommu_ops *ops,
>  
>  	return err;
>  }
> +
> +/**
> + * iort_iommu_msi_get_resv_regions - Reserved region driver helper
> + * @dev: Device from iommu_get_resv_regions()
> + * @head: Reserved region list from iommu_get_resv_regions()
> + *
> + * Returns: Number of msi reserved regions on success (0 if platform
> + *          doesn't require the reservation or no associated msi regions),
> + *          appropriate error value otherwise. The ITS interrupt translation
> + *          spaces (ITS_base + SZ_64K, SZ_64K) associated with the device
> + *          are the msi reserved regions.
> + */
> +int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
> +{
> +	struct acpi_iort_its_group *its;
> +	struct acpi_iort_node *iommu_node, *its_node = NULL;
> +	int i, resv = 0;
> +
> +	iommu_node = iort_get_msi_resv_iommu(dev);
> +	if (!iommu_node)
> +		return 0;
> +
> +	/*
> +	 * Current logic to reserve ITS regions relies on HW topologies
> +	 * where a given PCI or named component maps its IDs to only one
> +	 * ITS group; if a PCI or named component can map its IDs to
> +	 * different ITS groups through IORT mappings this function has
> +	 * to be reworked to ensure we reserve regions for all ITS groups
> +	 * a given PCI or named component may map IDs to.
> +	 */
> +
> +	for (i = 0; i < dev->iommu_fwspec->num_ids; i++) {
> +		its_node = iort_node_map_id(iommu_node,
> +					dev->iommu_fwspec->ids[i],
> +					NULL, IORT_MSI_TYPE);
> +		if (its_node)
> +			break;
> +	}
> +
> +	if (!its_node)
> +		return 0;
> +
> +	/* Move to ITS specific data */
> +	its = (struct acpi_iort_its_group *)its_node->node_data;
> +
> +	for (i = 0; i < its->its_count; i++) {
> +		phys_addr_t base;
> +
> +		if (!iort_find_its_base(its->identifiers[i], &base)) {
> +			int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
> +			struct iommu_resv_region *region;
> +
> +			region = iommu_alloc_resv_region(base + SZ_64K, SZ_64K,
> +							 prot, IOMMU_RESV_MSI);
> +			if (region) {
> +				list_add_tail(&region->list, head);
> +				resv++;
> +			}
> +		}
> +	}
> +
> +	return (resv == its->its_count) ? resv : -ENODEV;
> +}
>  #else
>  static inline const struct iommu_ops *iort_fwspec_iommu_ops(
>  				struct iommu_fwspec *fwspec)
> @@ -789,6 +892,8 @@ static inline const struct iommu_ops *iort_fwspec_iommu_ops(
>  static inline int iort_add_device_replay(const struct iommu_ops *ops,
>  					 struct device *dev)
>  { return 0; }
> +int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
> +{ return 0; }
>  #endif
>  
>  static int iort_iommu_xlate(struct device *dev, struct acpi_iort_node *node,
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 4039e64..d4cff12 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -3450,7 +3450,8 @@ static int __init gic_acpi_parse_madt_its(struct acpi_subtable_header *header,
>  		return -ENOMEM;
>  	}
>  
> -	err = iort_register_domain_token(its_entry->translation_id, dom_handle);
> +	err = iort_register_domain_token(its_entry->translation_id, res.start,
> +					 dom_handle);
>  	if (err) {
>  		pr_err("ITS@%pa: Unable to register GICv3 ITS domain token (ITS ID %d) to IORT\n",
>  		       &res.start, its_entry->translation_id);
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 2f7a292..38cd77b 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -26,7 +26,8 @@
>  #define IORT_IRQ_MASK(irq)		(irq & 0xffffffffULL)
>  #define IORT_IRQ_TRIGGER_MASK(irq)	((irq >> 32) & 0xffffffffULL)
>  
> -int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node);
> +int iort_register_domain_token(int trans_id, phys_addr_t base,
> +			       struct fwnode_handle *fw_node);
>  void iort_deregister_domain_token(int trans_id);
>  struct fwnode_handle *iort_find_domain_token(int trans_id);
>  #ifdef CONFIG_ACPI_IORT
> @@ -38,6 +39,7 @@
>  /* IOMMU interface */
>  void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *size);
>  const struct iommu_ops *iort_iommu_configure(struct device *dev);
> +int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
>  #else
>  static inline void acpi_iort_init(void) { }
>  static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
> @@ -52,6 +54,9 @@ static inline void iort_dma_setup(struct device *dev, u64 *dma_addr,
>  static inline const struct iommu_ops *iort_iommu_configure(
>  				      struct device *dev)
>  { return NULL; }
> +static inline
> +int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
> +{ return 0; }
>  #endif
>  
>  #endif /* __ACPI_IORT_H__ */
> -- 
> 1.9.1
> 
> 

Re: [PATCH v12 1/3] ACPI/IORT: Add msi address regions reservation helper

[Marc Zyngier]

On Thu, 14 Dec 2017 16:09:55 +0000,
Shameer Kolothum wrote:
> 
> On some platforms msi parent address regions have to be excluded from
> normal IOVA allocation in that they are detected and decoded in a HW
> specific way by system components and so they cannot be considered normal
> IOVA address space.
> 
> Add a helper function that retrieves ITS address regions - the msi
> parent - through IORT device <-> ITS mappings and reserves it so that
> these regions will not be translated by IOMMU and will be excluded from
> IOVA allocations. The function checks for the smmu model number and
> only applies the msi reservation if the platform requires it.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/acpi/arm64/iort.c        | 111 +++++++++++++++++++++++++++++++++++++--
>  drivers/irqchip/irq-gic-v3-its.c |   3 +-
>  include/linux/acpi_iort.h        |   7 ++-
>  3 files changed, 116 insertions(+), 5 deletions(-)

For the ITS part:

Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>

	M.

RE: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameerali Kolothum Thodi]

Hi Lorenzo/Robin/Will,

Since this has all the necessary reviewed-by from all concerned now(Thanks to all),
just wondering how this will be picked up? through iort or iommu?

Please let me know.

Thanks,
Shameer

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Thursday, December 14, 2017 4:10 PM
> To: lorenzo.pieralisi@arm.com; robin.murphy@arm.com;
> marc.zyngier@arm.com; will.deacon@arm.com
> Cc: joro@8bytes.org; John Garry <john.garry@huawei.com>; xuwei (O)
> <xuwei5@hisilicon.com>; Guohanjun (Hanjun Guo) <guohanjun@huawei.com>;
> iommu@lists.linux-foundation.org; linux-arm-kernel@lists.infradead.org; linux-
> acpi@vger.kernel.org; devicetree@vger.kernel.org; Linuxarm
> <linuxarm@huawei.com>; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>
> Subject: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon
> 161010801 erratum(reserve HW MSI)
> 
> On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> deviates from the standard implementation and this breaks PCIe MSI
> functionality when SMMU is enabled.
> 
> The HiSilicon erratum 161010801 describes this limitation of certain
> HiSilicon platforms to support the SMMU mappings for MSI transactions.
> On these platforms GICv3 ITS translator is presented with the deviceID
> by extending the MSI payload data to 64 bits to include the deviceID.
> Hence, the PCIe controller on this platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI payload.
> This basically makes it difficult for this platforms to have a SMMU
> translation for MSI.
> 
> This patch implements an ACPI based quirk to reserve the hw msi regions
> in the smmu-v3 driver which means these address regions will not be
> translated and will be excluded from iova allocations.
> 
> To implement this quirk, the following changes are incorporated:
> 1. Added a generic helper function to IORT code to retrieve and reserve
>    the associated ITS base address from a device IORT node. The function
>    has a check for smmu model to determine whether the platform requires
>    the HW MSI reservation or not.
> 2. Added smmu node entries and explicitly disabled them in hip06/hip07
>     dts files so that users are warned about the non-DT support for this
>     erratum.
> 
> Changelog:
> 
> v11--> v12
> -Thanks to Lorenzo, Fixed !CONFIG_IOMMU_API compile error(patch #1).
> 
> v10 --> v11
> -Addressed comments from Lorenzo(patch#1)
> -Added Robin's Reviewed-by to patch #2
> 
> v9 --> v10
> Addressed comments:
> -Moved smmu model check to iort helper function to selectively apply
>  the msi reservation which will make the fn call generic from iommu-dma.
> -Removed PCI blacklisting patch, instead added smmu nodes(disabled)
>  with comments to hip06/hip07 dts file.
> 
> v8 --> v9
> -Thanks to Marc, fixed IORT helper function to reserve the ITS
>  translater region only.
> -Removed the DT support for MSI reservation and blacklisted
>  HiSilicon PCIe controllers on DT based systems when SMMUv3 is
>  enabled.
> 
> v7 --> v8
> Addressed comments from Rob and Lorenzo:
>  -Modified to use DT compatible string for errata.
>  -Changed logic to retrieve the msi-parent for DT case.
> 
> v6 --> v7
> Addressed request from Will to add DT support for the erratum:
>  - added bt binding
>  - add of_iommu_msi_get_resv_regions()
> New arm64 silicon errata entry
> Rename iort_iommu_{its->msi}_get_resv_regions
> 
> v5 --> v6
> Addressed comments from Robin and Lorenzo:
> -No change to patch#1 .
> -Reverted v5 patch#2 as this might break the platforms where this quirk
>   is not applicable. Provided a generic function in iommu code and added
>   back the quirk implementation in SMMU v3 driver(patch#3)
> 
> v4 --> v5
> Addressed comments from Robin and Lorenzo:
> -Added a comment to make it clear that, for now, only straightforward
>   HW topologies are handled while reserving ITS regions(patch #1).
> 
> v3 --> v4
> Rebased on 4.13-rc1.
> Addressed comments from Robin, Will and Lorenzo:
> -As suggested by Robin, moved the ITS msi reservation into
>   iommu_dma_get_resv_regions().
> -Added its_count != resv region failure case(patch #1).
> 
> v2 --> v3
> Addressed comments from Lorenzo and Robin:
> -Removed dev_is_pci() check in smmuV3 driver.
> -Don't treat device not having an ITS mapping as an error in
>   iort helper function.
> 
> v1 --> v2
> -patch 2/2: Invoke iort helper fn based on fwnode type(acpi).
> 
> RFCv2 -->PATCH
> -Incorporated Lorenzo's review comments.
> 
> RFC v1 --> RFC v2
> Based on Robin's review comments,
> -Removed  the generic erratum framework.
> -Using IORT/MADT tables to retrieve the ITS base addr instead
>  of vendor specific CSRT table.
> 
> Shameer Kolothum (3):
>   ACPI/IORT: Add msi address regions reservation helper
>   iommu/dma: Add HW MSI(GICv3 ITS) address regions reservation
>   arm64:dts:hisilicon Disable hisilicon smmu node on hip06/hip07
> 
>  arch/arm64/boot/dts/hisilicon/hip06.dtsi |  56 ++++++++++++++++
>  arch/arm64/boot/dts/hisilicon/hip07.dtsi |  25 +++++++
>  drivers/acpi/arm64/iort.c                | 111 ++++++++++++++++++++++++++++++-
>  drivers/iommu/dma-iommu.c                |   8 ++-
>  drivers/irqchip/irq-gic-v3-its.c         |   3 +-
>  include/linux/acpi_iort.h                |   7 +-
>  6 files changed, 204 insertions(+), 6 deletions(-)
> 
> --
> 1.9.1
> 

RE: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameerali Kolothum Thodi]

Hi,

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Friday, December 15, 2017 3:01 PM
> To: lorenzo.pieralisi@arm.com; robin.murphy@arm.com;
> marc.zyngier@arm.com; will.deacon@arm.com
> Cc: joro@8bytes.org; John Garry <john.garry@huawei.com>; xuwei (O)
> <xuwei5@hisilicon.com>; Guohanjun (Hanjun Guo) <guohanjun@huawei.com>;
> iommu@lists.linux-foundation.org; linux-arm-kernel@lists.infradead.org; linux-
> acpi@vger.kernel.org; devicetree@vger.kernel.org; Linuxarm
> <linuxarm@huawei.com>
> Subject: RE: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon
> 161010801 erratum(reserve HW MSI)
> 
> Hi Lorenzo/Robin/Will,
> 
> Since this has all the necessary reviewed-by from all concerned now(Thanks to
> all),
> just wondering how this will be picked up? through iort or iommu?
> 
> Please let me know.
> 

A gentle ping on this series...

Thanks,
Shameer

> 
> > -----Original Message-----
> > From: Shameerali Kolothum Thodi
> > Sent: Thursday, December 14, 2017 4:10 PM
> > To: lorenzo.pieralisi@arm.com; robin.murphy@arm.com;
> > marc.zyngier@arm.com; will.deacon@arm.com
> > Cc: joro@8bytes.org; John Garry <john.garry@huawei.com>; xuwei (O)
> > <xuwei5@hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun@huawei.com>;
> > iommu@lists.linux-foundation.org; linux-arm-kernel@lists.infradead.org;
> linux-
> > acpi@vger.kernel.org; devicetree@vger.kernel.org; Linuxarm
> > <linuxarm@huawei.com>; Shameerali Kolothum Thodi
> > <shameerali.kolothum.thodi@huawei.com>
> > Subject: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon
> > 161010801 erratum(reserve HW MSI)
> >
> > On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> > deviates from the standard implementation and this breaks PCIe MSI
> > functionality when SMMU is enabled.
> >
> > The HiSilicon erratum 161010801 describes this limitation of certain
> > HiSilicon platforms to support the SMMU mappings for MSI transactions.
> > On these platforms GICv3 ITS translator is presented with the deviceID
> > by extending the MSI payload data to 64 bits to include the deviceID.
> > Hence, the PCIe controller on this platforms has to differentiate the MSI
> > payload against other DMA payload and has to modify the MSI payload.
> > This basically makes it difficult for this platforms to have a SMMU
> > translation for MSI.
> >
> > This patch implements an ACPI based quirk to reserve the hw msi regions
> > in the smmu-v3 driver which means these address regions will not be
> > translated and will be excluded from iova allocations.
> >
> > To implement this quirk, the following changes are incorporated:
> > 1. Added a generic helper function to IORT code to retrieve and reserve
> >    the associated ITS base address from a device IORT node. The function
> >    has a check for smmu model to determine whether the platform requires
> >    the HW MSI reservation or not.
> > 2. Added smmu node entries and explicitly disabled them in hip06/hip07
> >     dts files so that users are warned about the non-DT support for this
> >     erratum.
> >
> > Changelog:
> >
> > v11--> v12
> > -Thanks to Lorenzo, Fixed !CONFIG_IOMMU_API compile error(patch #1).
> >
> > v10 --> v11
> > -Addressed comments from Lorenzo(patch#1)
> > -Added Robin's Reviewed-by to patch #2
> >
> > v9 --> v10
> > Addressed comments:
> > -Moved smmu model check to iort helper function to selectively apply
> >  the msi reservation which will make the fn call generic from iommu-dma.
> > -Removed PCI blacklisting patch, instead added smmu nodes(disabled)
> >  with comments to hip06/hip07 dts file.
> >
> > v8 --> v9
> > -Thanks to Marc, fixed IORT helper function to reserve the ITS
> >  translater region only.
> > -Removed the DT support for MSI reservation and blacklisted
> >  HiSilicon PCIe controllers on DT based systems when SMMUv3 is
> >  enabled.
> >
> > v7 --> v8
> > Addressed comments from Rob and Lorenzo:
> >  -Modified to use DT compatible string for errata.
> >  -Changed logic to retrieve the msi-parent for DT case.
> >
> > v6 --> v7
> > Addressed request from Will to add DT support for the erratum:
> >  - added bt binding
> >  - add of_iommu_msi_get_resv_regions()
> > New arm64 silicon errata entry
> > Rename iort_iommu_{its->msi}_get_resv_regions
> >
> > v5 --> v6
> > Addressed comments from Robin and Lorenzo:
> > -No change to patch#1 .
> > -Reverted v5 patch#2 as this might break the platforms where this quirk
> >   is not applicable. Provided a generic function in iommu code and added
> >   back the quirk implementation in SMMU v3 driver(patch#3)
> >
> > v4 --> v5
> > Addressed comments from Robin and Lorenzo:
> > -Added a comment to make it clear that, for now, only straightforward
> >   HW topologies are handled while reserving ITS regions(patch #1).
> >
> > v3 --> v4
> > Rebased on 4.13-rc1.
> > Addressed comments from Robin, Will and Lorenzo:
> > -As suggested by Robin, moved the ITS msi reservation into
> >   iommu_dma_get_resv_regions().
> > -Added its_count != resv region failure case(patch #1).
> >
> > v2 --> v3
> > Addressed comments from Lorenzo and Robin:
> > -Removed dev_is_pci() check in smmuV3 driver.
> > -Don't treat device not having an ITS mapping as an error in
> >   iort helper function.
> >
> > v1 --> v2
> > -patch 2/2: Invoke iort helper fn based on fwnode type(acpi).
> >
> > RFCv2 -->PATCH
> > -Incorporated Lorenzo's review comments.
> >
> > RFC v1 --> RFC v2
> > Based on Robin's review comments,
> > -Removed  the generic erratum framework.
> > -Using IORT/MADT tables to retrieve the ITS base addr instead
> >  of vendor specific CSRT table.
> >
> > Shameer Kolothum (3):
> >   ACPI/IORT: Add msi address regions reservation helper
> >   iommu/dma: Add HW MSI(GICv3 ITS) address regions reservation
> >   arm64:dts:hisilicon Disable hisilicon smmu node on hip06/hip07
> >
> >  arch/arm64/boot/dts/hisilicon/hip06.dtsi |  56 ++++++++++++++++
> >  arch/arm64/boot/dts/hisilicon/hip07.dtsi |  25 +++++++
> >  drivers/acpi/arm64/iort.c                | 111
> ++++++++++++++++++++++++++++++-
> >  drivers/iommu/dma-iommu.c                |   8 ++-
> >  drivers/irqchip/irq-gic-v3-its.c         |   3 +-
> >  include/linux/acpi_iort.h                |   7 +-
> >  6 files changed, 204 insertions(+), 6 deletions(-)
> >
> > --
> > 1.9.1
> >

Re: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Will Deacon]

Hi Shameer,

On Thu, Dec 14, 2017 at 04:09:54PM +0000, Shameer Kolothum wrote:
> On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> deviates from the standard implementation and this breaks PCIe MSI
> functionality when SMMU is enabled.
> 
> The HiSilicon erratum 161010801 describes this limitation of certain
> HiSilicon platforms to support the SMMU mappings for MSI transactions.
> On these platforms GICv3 ITS translator is presented with the deviceID
> by extending the MSI payload data to 64 bits to include the deviceID.
> Hence, the PCIe controller on this platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI payload.
> This basically makes it difficult for this platforms to have a SMMU
> translation for MSI.
> 
> This patch implements an ACPI based quirk to reserve the hw msi regions
> in the smmu-v3 driver which means these address regions will not be
> translated and will be excluded from iova allocations.
> 
> To implement this quirk, the following changes are incorporated:
> 1. Added a generic helper function to IORT code to retrieve and reserve
>    the associated ITS base address from a device IORT node. The function
>    has a check for smmu model to determine whether the platform requires
>    the HW MSI reservation or not.
> 2. Added smmu node entries and explicitly disabled them in hip06/hip07
>     dts files so that users are warned about the non-DT support for this
>     erratum.

[...]

>  arch/arm64/boot/dts/hisilicon/hip06.dtsi |  56 ++++++++++++++++
>  arch/arm64/boot/dts/hisilicon/hip07.dtsi |  25 +++++++
>  drivers/acpi/arm64/iort.c                | 111 ++++++++++++++++++++++++++++++-
>  drivers/iommu/dma-iommu.c                |   8 ++-
>  drivers/irqchip/irq-gic-v3-its.c         |   3 +-
>  include/linux/acpi_iort.h                |   7 +-
>  6 files changed, 204 insertions(+), 6 deletions(-)

It occurred to me this morning that this series probably isn't queued
anywhere because it's not obvious which tree is supposed to take it and
I can't see it in -next.

Is this one for arm64, IOMMU, irqchip or something else? It's probably
missed the boat for 4.16 now...

Will

RE: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameerali Kolothum Thodi]

Hi Will,

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon-5wv7dgnIgG8@public.gmane.org]
> Sent: Monday, January 29, 2018 3:40 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Cc: lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org;
> marc.zyngier-5wv7dgnIgG8@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; John Garry
> <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; xuwei (O) <xuwei5-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; Guohanjun
> (Hanjun Guo) <guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org;
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm <linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Subject: Re: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon
> 161010801 erratum(reserve HW MSI)
> 
> Hi Shameer,
> 
> On Thu, Dec 14, 2017 at 04:09:54PM +0000, Shameer Kolothum wrote:
> > On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> > deviates from the standard implementation and this breaks PCIe MSI
> > functionality when SMMU is enabled.
> >
> > The HiSilicon erratum 161010801 describes this limitation of certain
> > HiSilicon platforms to support the SMMU mappings for MSI transactions.
> > On these platforms GICv3 ITS translator is presented with the deviceID
> > by extending the MSI payload data to 64 bits to include the deviceID.
> > Hence, the PCIe controller on this platforms has to differentiate the
> > MSI payload against other DMA payload and has to modify the MSI payload.
> > This basically makes it difficult for this platforms to have a SMMU
> > translation for MSI.
> >
> > This patch implements an ACPI based quirk to reserve the hw msi
> > regions in the smmu-v3 driver which means these address regions will
> > not be translated and will be excluded from iova allocations.
> >
> > To implement this quirk, the following changes are incorporated:
> > 1. Added a generic helper function to IORT code to retrieve and reserve
> >    the associated ITS base address from a device IORT node. The function
> >    has a check for smmu model to determine whether the platform requires
> >    the HW MSI reservation or not.
> > 2. Added smmu node entries and explicitly disabled them in hip06/hip07
> >     dts files so that users are warned about the non-DT support for this
> >     erratum.
> 
> [...]
> 
> >  arch/arm64/boot/dts/hisilicon/hip06.dtsi |  56 ++++++++++++++++
> > arch/arm64/boot/dts/hisilicon/hip07.dtsi |  25 +++++++
> >  drivers/acpi/arm64/iort.c                | 111
> ++++++++++++++++++++++++++++++-
> >  drivers/iommu/dma-iommu.c                |   8 ++-
> >  drivers/irqchip/irq-gic-v3-its.c         |   3 +-
> >  include/linux/acpi_iort.h                |   7 +-
> >  6 files changed, 204 insertions(+), 6 deletions(-)
> 
> It occurred to me this morning that this series probably isn't queued anywhere
> because it's not obvious which tree is supposed to take it and I can't see it in -
> next.
> 
> Is this one for arm64, IOMMU, irqchip or something else? It's probably missed
> the boat for 4.16 now...
> 

I have been trying to ping you guys on this[1]. My expectation was that it will be
through IOMMU. Anyway missed the boat now, I will re-spin for 4.17.

Thanks,
Shameer
1. https://www.mail-archive.com/iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org/msg21391.html



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Will Deacon]

On Mon, Jan 29, 2018 at 04:16:33PM +0000, Shameerali Kolothum Thodi wrote:
> > -----Original Message-----
> > From: Will Deacon [mailto:will.deacon-5wv7dgnIgG8@public.gmane.org]
> > Sent: Monday, January 29, 2018 3:40 PM
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > Cc: lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org;
> > marc.zyngier-5wv7dgnIgG8@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; John Garry
> > <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; xuwei (O) <xuwei5-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; Guohanjun
> > (Hanjun Guo) <guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org;
> > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm <linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > Subject: Re: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon
> > 161010801 erratum(reserve HW MSI)
> > On Thu, Dec 14, 2017 at 04:09:54PM +0000, Shameer Kolothum wrote:
> > > On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> > > deviates from the standard implementation and this breaks PCIe MSI
> > > functionality when SMMU is enabled.
> > >
> > > The HiSilicon erratum 161010801 describes this limitation of certain
> > > HiSilicon platforms to support the SMMU mappings for MSI transactions.
> > > On these platforms GICv3 ITS translator is presented with the deviceID
> > > by extending the MSI payload data to 64 bits to include the deviceID.
> > > Hence, the PCIe controller on this platforms has to differentiate the
> > > MSI payload against other DMA payload and has to modify the MSI payload.
> > > This basically makes it difficult for this platforms to have a SMMU
> > > translation for MSI.
> > >
> > > This patch implements an ACPI based quirk to reserve the hw msi
> > > regions in the smmu-v3 driver which means these address regions will
> > > not be translated and will be excluded from iova allocations.
> > >
> > > To implement this quirk, the following changes are incorporated:
> > > 1. Added a generic helper function to IORT code to retrieve and reserve
> > >    the associated ITS base address from a device IORT node. The function
> > >    has a check for smmu model to determine whether the platform requires
> > >    the HW MSI reservation or not.
> > > 2. Added smmu node entries and explicitly disabled them in hip06/hip07
> > >     dts files so that users are warned about the non-DT support for this
> > >     erratum.
> > 
> > [...]
> > 
> > >  arch/arm64/boot/dts/hisilicon/hip06.dtsi |  56 ++++++++++++++++
> > > arch/arm64/boot/dts/hisilicon/hip07.dtsi |  25 +++++++
> > >  drivers/acpi/arm64/iort.c                | 111
> > ++++++++++++++++++++++++++++++-
> > >  drivers/iommu/dma-iommu.c                |   8 ++-
> > >  drivers/irqchip/irq-gic-v3-its.c         |   3 +-
> > >  include/linux/acpi_iort.h                |   7 +-
> > >  6 files changed, 204 insertions(+), 6 deletions(-)
> > 
> > It occurred to me this morning that this series probably isn't queued anywhere
> > because it's not obvious which tree is supposed to take it and I can't see it in -
> > next.
> > 
> > Is this one for arm64, IOMMU, irqchip or something else? It's probably missed
> > the boat for 4.16 now...
> > 
> 
> I have been trying to ping you guys on this[1]. My expectation was that it will be
> through IOMMU. Anyway missed the boat now, I will re-spin for 4.17.

The problem with "ping" emails is that they don't really mean anything. In
this case, everybody probably assumed somebody else was picking it up so you
didn't get a reply.

Joerg may be ok pulling this, but it's odd to have dts changes going via his
tree. You might want to split those out, at least. Talk to him.

Will
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameerali Kolothum Thodi]

Hi Joerg,

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon@arm.com]
> Sent: Monday, January 29, 2018 4:21 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: lorenzo.pieralisi@arm.com; robin.murphy@arm.com;
> marc.zyngier@arm.com; joro@8bytes.org; John Garry
> <john.garry@huawei.com>; xuwei (O) <xuwei5@huawei.com>; Guohanjun
> (Hanjun Guo) <guohanjun@huawei.com>; iommu@lists.linux-foundation.org;
> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
> devicetree@vger.kernel.org; Linuxarm <linuxarm@huawei.com>
> Subject: Re: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon
> 161010801 erratum(reserve HW MSI)
> 
> On Mon, Jan 29, 2018 at 04:16:33PM +0000, Shameerali Kolothum Thodi wrote:
> > > -----Original Message-----
> > > From: Will Deacon [mailto:will.deacon@arm.com]
> > > Sent: Monday, January 29, 2018 3:40 PM
> > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> > > Cc: lorenzo.pieralisi@arm.com; robin.murphy@arm.com;
> > > marc.zyngier@arm.com; joro@8bytes.org; John Garry
> > > <john.garry@huawei.com>; xuwei (O) <xuwei5@huawei.com>; Guohanjun
> > > (Hanjun Guo) <guohanjun@huawei.com>; iommu@lists.linux-
> foundation.org;
> > > linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
> > > devicetree@vger.kernel.org; Linuxarm <linuxarm@huawei.com>
> > > Subject: Re: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon
> > > 161010801 erratum(reserve HW MSI)
> > > On Thu, Dec 14, 2017 at 04:09:54PM +0000, Shameer Kolothum wrote:
> > > > On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> > > > deviates from the standard implementation and this breaks PCIe MSI
> > > > functionality when SMMU is enabled.
> > > >
> > > > The HiSilicon erratum 161010801 describes this limitation of certain
> > > > HiSilicon platforms to support the SMMU mappings for MSI transactions.
> > > > On these platforms GICv3 ITS translator is presented with the deviceID
> > > > by extending the MSI payload data to 64 bits to include the deviceID.
> > > > Hence, the PCIe controller on this platforms has to differentiate the
> > > > MSI payload against other DMA payload and has to modify the MSI
> payload.
> > > > This basically makes it difficult for this platforms to have a SMMU
> > > > translation for MSI.
> > > >
> > > > This patch implements an ACPI based quirk to reserve the hw msi
> > > > regions in the smmu-v3 driver which means these address regions will
> > > > not be translated and will be excluded from iova allocations.
> > > >
> > > > To implement this quirk, the following changes are incorporated:
> > > > 1. Added a generic helper function to IORT code to retrieve and reserve
> > > >    the associated ITS base address from a device IORT node. The function
> > > >    has a check for smmu model to determine whether the platform
> requires
> > > >    the HW MSI reservation or not.
> > > > 2. Added smmu node entries and explicitly disabled them in hip06/hip07
> > > >     dts files so that users are warned about the non-DT support for this
> > > >     erratum.
> > >
> > > [...]
> > >
> > > >  arch/arm64/boot/dts/hisilicon/hip06.dtsi |  56 ++++++++++++++++
> > > > arch/arm64/boot/dts/hisilicon/hip07.dtsi |  25 +++++++
> > > >  drivers/acpi/arm64/iort.c                | 111
> > > ++++++++++++++++++++++++++++++-
> > > >  drivers/iommu/dma-iommu.c                |   8 ++-
> > > >  drivers/irqchip/irq-gic-v3-its.c         |   3 +-
> > > >  include/linux/acpi_iort.h                |   7 +-
> > > >  6 files changed, 204 insertions(+), 6 deletions(-)
> > >
> > > It occurred to me this morning that this series probably isn't queued
> anywhere
> > > because it's not obvious which tree is supposed to take it and I can't see it in
> -
> > > next.
> > >
> > > Is this one for arm64, IOMMU, irqchip or something else? It's probably
> missed
> > > the boat for 4.16 now...
> > >
> >
> > I have been trying to ping you guys on this[1]. My expectation was that it will
> be
> > through IOMMU. Anyway missed the boat now, I will re-spin for 4.17.
> 
> The problem with "ping" emails is that they don't really mean anything. In
> this case, everybody probably assumed somebody else was picking it up so you
> didn't get a reply.
> 
> Joerg may be ok pulling this, but it's odd to have dts changes going via his
> tree. You might want to split those out, at least. Talk to him.
> 

This series has all the necessary ACKs from all concerned and as mentioned above
somehow created a confusion regarding the pull request. My apologies.

Could you please take a look and send out a pull request, if it is ok.

Many thanks,
Shameer

RE: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameerali Kolothum Thodi]

Hi Joerg,

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Monday, January 29, 2018 4:42 PM
> To: 'Will Deacon' <will.deacon-5wv7dgnIgG8@public.gmane.org>; Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
> Cc: lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org;
> marc.zyngier-5wv7dgnIgG8@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; John Garry
> <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; xuwei (O) <xuwei5-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; Guohanjun
> (Hanjun Guo) <guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org;
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm <linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Subject: RE: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon
> 161010801 erratum(reserve HW MSI)
> 
> Hi Joerg,
> 
> > -----Original Message-----
> > From: Will Deacon [mailto:will.deacon-5wv7dgnIgG8@public.gmane.org]
> > Sent: Monday, January 29, 2018 4:21 PM
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > Cc: lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org;
> > marc.zyngier-5wv7dgnIgG8@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; John Garry
> > <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; xuwei (O) <xuwei5-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; Guohanjun
> > (Hanjun Guo) <guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org;
> > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm <linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > Subject: Re: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon
> > 161010801 erratum(reserve HW MSI)
> >
> > On Mon, Jan 29, 2018 at 04:16:33PM +0000, Shameerali Kolothum Thodi
> wrote:
> > > > -----Original Message-----
> > > > From: Will Deacon [mailto:will.deacon-5wv7dgnIgG8@public.gmane.org]
> > > > Sent: Monday, January 29, 2018 3:40 PM
> > > > To: Shameerali Kolothum Thodi
> > > > <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > > Cc: lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org;
> > > > marc.zyngier-5wv7dgnIgG8@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; John Garry
> > > > <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; xuwei (O) <xuwei5-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>;
> Guohanjun
> > > > (Hanjun Guo) <guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> > foundation.org;
> > > > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm <linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > > Subject: Re: [PATCH v12 0/3] iommu/smmu-v3: Workaround for
> > > > hisilicon
> > > > 161010801 erratum(reserve HW MSI)
> > > > On Thu, Dec 14, 2017 at 04:09:54PM +0000, Shameer Kolothum wrote:
> > > > > On certain HiSilicon platforms (hip06/hip07) the GIC ITS and
> > > > > PCIe RC deviates from the standard implementation and this
> > > > > breaks PCIe MSI functionality when SMMU is enabled.
> > > > >
> > > > > The HiSilicon erratum 161010801 describes this limitation of
> > > > > certain HiSilicon platforms to support the SMMU mappings for MSI
> transactions.
> > > > > On these platforms GICv3 ITS translator is presented with the
> > > > > deviceID by extending the MSI payload data to 64 bits to include the
> deviceID.
> > > > > Hence, the PCIe controller on this platforms has to
> > > > > differentiate the MSI payload against other DMA payload and has
> > > > > to modify the MSI
> > payload.
> > > > > This basically makes it difficult for this platforms to have a
> > > > > SMMU translation for MSI.
> > > > >
> > > > > This patch implements an ACPI based quirk to reserve the hw msi
> > > > > regions in the smmu-v3 driver which means these address regions
> > > > > will not be translated and will be excluded from iova allocations.
> > > > >
> > > > > To implement this quirk, the following changes are incorporated:
> > > > > 1. Added a generic helper function to IORT code to retrieve and reserve
> > > > >    the associated ITS base address from a device IORT node. The function
> > > > >    has a check for smmu model to determine whether the platform
> > requires
> > > > >    the HW MSI reservation or not.
> > > > > 2. Added smmu node entries and explicitly disabled them in hip06/hip07
> > > > >     dts files so that users are warned about the non-DT support for this
> > > > >     erratum.
> > > >
> > > > [...]
> > > >
> > > > >  arch/arm64/boot/dts/hisilicon/hip06.dtsi |  56 ++++++++++++++++
> > > > > arch/arm64/boot/dts/hisilicon/hip07.dtsi |  25 +++++++
> > > > >  drivers/acpi/arm64/iort.c                | 111
> > > > ++++++++++++++++++++++++++++++-
> > > > >  drivers/iommu/dma-iommu.c                |   8 ++-
> > > > >  drivers/irqchip/irq-gic-v3-its.c         |   3 +-
> > > > >  include/linux/acpi_iort.h                |   7 +-
> > > > >  6 files changed, 204 insertions(+), 6 deletions(-)
> > > >
> > > > It occurred to me this morning that this series probably isn't
> > > > queued
> > anywhere
> > > > because it's not obvious which tree is supposed to take it and I
> > > > can't see it in
> > -
> > > > next.
> > > >
> > > > Is this one for arm64, IOMMU, irqchip or something else? It's
> > > > probably
> > missed
> > > > the boat for 4.16 now...
> > > >
> > >
> > > I have been trying to ping you guys on this[1]. My expectation was
> > > that it will
> > be
> > > through IOMMU. Anyway missed the boat now, I will re-spin for 4.17.
> >
> > The problem with "ping" emails is that they don't really mean
> > anything. In this case, everybody probably assumed somebody else was
> > picking it up so you didn't get a reply.
> >
> > Joerg may be ok pulling this, but it's odd to have dts changes going
> > via his tree. You might want to split those out, at least. Talk to him.
> >
> 
> This series has all the necessary ACKs from all concerned and as mentioned
> above somehow created a confusion regarding the pull request. My apologies.
> 
> Could you please take a look and send out a pull request, if it is ok.
> 

Not sure you got a chance to go through this and sorry for asking again.
Please let me know if you can pull this still or it's too late for now.

Thanks,
Shameer

RE: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameerali Kolothum Thodi]

Hi Will,

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon-5wv7dgnIgG8@public.gmane.org]
> Sent: Monday, January 29, 2018 4:21 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Cc: lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org;
> marc.zyngier-5wv7dgnIgG8@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; John Garry
> <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; xuwei (O) <xuwei5-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; Guohanjun
> (Hanjun Guo) <guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org;
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm <linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Subject: Re: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon
> 161010801 erratum(reserve HW MSI)
> 
> On Mon, Jan 29, 2018 at 04:16:33PM +0000, Shameerali Kolothum Thodi wrote:
> > > -----Original Message-----
> > > From: Will Deacon [mailto:will.deacon-5wv7dgnIgG8@public.gmane.org]
> > > Sent: Monday, January 29, 2018 3:40 PM
> > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > Cc: lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org;
> > > marc.zyngier-5wv7dgnIgG8@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; John Garry
> > > <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; xuwei (O) <xuwei5-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; Guohanjun
> > > (Hanjun Guo) <guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> foundation.org;
> > > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Linuxarm <linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > Subject: Re: [PATCH v12 0/3] iommu/smmu-v3: Workaround for hisilicon
> > > 161010801 erratum(reserve HW MSI)
> > > On Thu, Dec 14, 2017 at 04:09:54PM +0000, Shameer Kolothum wrote:
> > > > On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> > > > deviates from the standard implementation and this breaks PCIe MSI
> > > > functionality when SMMU is enabled.
> > > >
[...]

> > > It occurred to me this morning that this series probably isn't queued
> anywhere
> > > because it's not obvious which tree is supposed to take it and I can't see it in
> -
> > > next.
> > >
> > > Is this one for arm64, IOMMU, irqchip or something else? It's probably
> missed
> > > the boat for 4.16 now...
> > >
> >
> > I have been trying to ping you guys on this[1]. My expectation was that it will
> be
> > through IOMMU. Anyway missed the boat now, I will re-spin for 4.17.
> 
> The problem with "ping" emails is that they don't really mean anything. In
> this case, everybody probably assumed somebody else was picking it up so you
> didn't get a reply.
> 
> Joerg may be ok pulling this, but it's odd to have dts changes going via his
> tree. You might want to split those out, at least. Talk to him.

As this series missed out from the PULL request, I am preparing to send this again.
Please let me know, you are ok with the dts changes being part of this or would like
to split it.

Thanks,
Shameer

Re: [PATCH v12 3/3] arm64:dts:hisilicon Disable hisilicon smmu node on hip06/hip07

[Wei Xu]

Hi Shameer,

On 2017/12/14 16:09, Shameer Kolothum wrote:
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.
> 
> PCIe controller on these platforms has to differentiate the
> MSI payload against other DMA payload and has to modify the
> MSI  payload. This makes it difficult for these platforms to
> have SMMU translation for MSI. In order to workaround this,
> ARM SMMUv3 driver requires a quirk to treat the MSI regions
> separately. Such a quirk is currently missing for DT based
> systems and therefore we need to explicitly disable the
> hip06/hip07 smmu entries in dts.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
> ---

Thanks!
Applied into hisilicon dt tree.

BR,
Wei

>  arch/arm64/boot/dts/hisilicon/hip06.dtsi | 56 ++++++++++++++++++++++++++++++++
>  arch/arm64/boot/dts/hisilicon/hip07.dtsi | 25 ++++++++++++++
>  2 files changed, 81 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> index a049b64..35202eb 100644
> --- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
> @@ -291,6 +291,13 @@
>  			#interrupt-cells = <2>;
>  			num-pins = <128>;
>  		};
> +
> +		mbigen_pcie0: intc_pcie0 {
> +			msi-parent = <&its_dsa 0x40085>;
> +			interrupt-controller;
> +			#interrupt-cells = <2>;
> +			num-pins = <10>;
> +		};
>  	};
>  
>  	mbigen_dsa@c0080000 {
> @@ -312,6 +319,31 @@
>  		};
>  	};
>  
> +	/**
> +	 *  HiSilicon erratum 161010801: This describes the limitation
> +	 *  of HiSilicon platforms hip06/hip07 to support the SMMUv3
> +	 *  mappings for PCIe MSI transactions.
> +	 *  PCIe controller on these platforms has to differentiate the
> +	 *  MSI payload against other DMA payload and has to modify the
> +	 *  MSI payload. This makes it difficult for these platforms to
> +	 *  have a SMMU translation for MSI. In order to workaround this,
> +	 *  ARM SMMUv3 driver requires a quirk to treat the MSI regions
> +	 *  separately. Such a quirk is currently missing for DT based
> +	 *  systems. Hence please make sure that the smmu pcie node on
> +	 *  hip06 is disabled as this will break the PCIe functionality
> +	 *  when iommu-map entry is used along with the PCIe node.
> +	 *  Refer:https://www.spinics.net/lists/arm-kernel/msg602812.html
> +	 */
> +	smmu0: smmu_pcie {
> +		compatible = "arm,smmu-v3";
> +		reg = <0x0 0xa0040000 0x0 0x20000>;
> +		#iommu-cells = <1>;
> +		dma-coherent;
> +		smmu-cb-memtype = <0x0 0x1>;
> +		hisilicon,broken-prefetch-cmd;
> +		status = "disabled";
> +	};
> +
>  	soc {
>  		compatible = "simple-bus";
>  		#address-cells = <2>;
> @@ -676,6 +708,30 @@
>  				     <637 1>,<638 1>,<639 1>;
>  			status = "disabled";
>  		};
> +
> +		pcie0: pcie@a0090000 {
> +			compatible = "hisilicon,hip06-pcie-ecam";
> +			reg = <0 0xb0000000 0 0x2000000>,
> +			      <0 0xa0090000 0 0x10000>;
> +			bus-range = <0  31>;
> +			msi-map = <0x0000 &its_dsa 0x0000 0x2000>;
> +			msi-map-mask = <0xffff>;
> +			#address-cells = <3>;
> +			#size-cells = <2>;
> +			device_type = "pci";
> +			dma-coherent;
> +			ranges = <0x02000000 0 0xb2000000 0x0 0xb2000000 0
> +				 0x5ff0000 0x01000000 0 0 0 0xb7ff0000
> +				 0 0x10000>;
> +			#interrupt-cells = <1>;
> +			interrupt-map-mask = <0xf800 0 0 7>;
> +			interrupt-map = <0x0 0 0 1 &mbigen_pcie0 650 4
> +					0x0 0 0 2 &mbigen_pcie0 650 4
> +					0x0 0 0 3 &mbigen_pcie0 650 4
> +					0x0 0 0 4 &mbigen_pcie0 650 4>;
> +			status = "disabled";
> +		};
> +
>  	};
>  
>  };
> diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
> index 2c01a21..3e80bf3 100644
> --- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
> @@ -1083,6 +1083,31 @@
>  		};
>  	};
>  
> +	/**
> +	 *  HiSilicon erratum 161010801: This describes the limitation
> +	 *  of HiSilicon platforms hip06/hip07 to support the SMMUv3
> +	 *  mappings for PCIe MSI transactions.
> +	 *  PCIe controller on these platforms has to differentiate the
> +	 *  MSI payload against other DMA payload and has to modify the
> +	 *  MSI payload. This makes it difficult for these platforms to
> +	 *  have a SMMU translation for MSI. In order to workaround this,
> +	 *  ARM SMMUv3 driver requires a quirk to treat the MSI regions
> +	 *  separately. Such a quirk is currently missing for DT based
> +	 *  systems. Hence please make sure that the smmu pcie node on
> +	 *  hip07 is disabled as this will break the PCIe functionality
> +	 *  when iommu-map entry is used along with the PCIe node.
> +	 *  Refer:https://www.spinics.net/lists/arm-kernel/msg602812.html
> +	 */
> +	smmu0: smmu_pcie {
> +		compatible = "arm,smmu-v3";
> +		reg = <0x0 0xa0040000 0x0 0x20000>;
> +		#iommu-cells = <1>;
> +		dma-coherent;
> +		smmu-cb-memtype = <0x0 0x1>;
> +		hisilicon,broken-prefetch-cmd;
> +		status = "disabled";
> +	};
> +
>  	soc {
>  		compatible = "simple-bus";
>  		#address-cells = <2>;
>