On Wed, Jul 05, 2017 at 09:48:53AM +0000, Shameerali Kolothum Thodi wrote:

quoted

-----Original Message-----
From: Will Deacon [mailto:will.deacon at arm.com]
Sent: Tuesday, July 04, 2017 6:38 PM
To: Shameerali Kolothum Thodi
Cc: lorenzo.pieralisi at arm.com; marc.zyngier at arm.com;
sudeep.holla at arm.com; robin.murphy at arm.com; hanjun.guo at linaro.org;
Gabriele Paoloni; John Garry; Linuxarm; linux-acpi at vger.kernel.org;
iommu at lists.linux-foundation.org; Wangzhou (B); Guohanjun (Hanjun Guo);
linux-arm-kernel at lists.infradead.org; devel at acpica.org
Subject: Re: [PATCH v3 2/2] iommu/arm-smmu-v3:Enable ACPI based
HiSilicon erratum 161010801

On Fri, Jun 23, 2017 at 03:58:01PM +0100, shameer wrote:

quoted

The HiSilicon erratum 161010801 describes the limitation of HiSilicon
platforms Hip06/Hip07 to support the SMMU mappings for MSI

transactions.

quoted

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.

quoted

This basically makes it difficult for this platforms to have a SMMU
translation for MSI.

This patch implements a ACPI table 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.

Signed-off-by: shameer <redacted>
---
 drivers/iommu/arm-smmu-v3.c | 30 ++++++++++++++++++++++++++----
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-

v3.c

quoted

index abe4b88..c9346f2 100644

--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c

@@ -597,6 +597,7 @@ struct arm_smmu_device {
 	u32				features;

 #define ARM_SMMU_OPT_SKIP_PREFETCH	(1 << 0)
+#define ARM_SMMU_OPT_RESV_HW_MSI	(1 << 1)
 	u32				options;

 	struct arm_smmu_cmdq		cmdq;

@@ -1904,14 +1905,34 @@ static void arm_smmu_get_resv_regions(struct

device *dev,

quoted

 				      struct list_head *head)
 {
 	struct iommu_resv_region *region;
+	struct arm_smmu_device *smmu;
+	struct iommu_fwspec *fwspec = dev->iommu_fwspec;
 	int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+	int resv = 0;

-	region = iommu_alloc_resv_region(MSI_IOVA_BASE,

MSI_IOVA_LENGTH,

quoted

-					 prot, IOMMU_RESV_SW_MSI);
-	if (!region)
+	smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);

Does this callback actually get called without a prior ->add_device callback
for the master in question? If not, then we can already claw the structure
out via the iommu_priv field in the fwspec.

Thanks Will for going through this.

Yes, from the logs I have, it looks like _resv callback is always called after
 ->add_device. I will double check this with vfio bind case as well.

And I guess, this is what you are proposing to retrieve the smmu,

master = dev->iommu_fwspec->iommu_priv;
smmu = master->smmu;

quoted

quoted

+	if (WARN_ON(!smmu))

Again, how does this trigger?

quoted

 		return;

-	list_add_tail(&region->list, head);
+	if ((smmu->options & ARM_SMMU_OPT_RESV_HW_MSI)) {
+
+		if (!is_of_node(smmu->dev->fwnode))
+			resv = iort_iommu_its_get_resv_regions(dev, head);

How does this work when we're not using ACPI? Shouldn't of vs ACPI be
abstracted from the driver?

At present ARM_SMMU_OPT_RESV_HW_MSI is only set for ACPI and  DT support for
this is a low priority for us at the moment. Is the suggestion is to have a common function
outside the smmu driver for _iommu_its_get_resv_regions() ? I am not sure what
is the best way here. 

Right, something like that. The driver shouldn't need to care whether or not
it's using ACPI or DT when setting these options.

Will