| Message ID | 20170613114829.188036-3-shameerali.kolothum.thodi@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jun 13, 2017 at 12:48:29PM +0100, shameer wrote: > The HiSilicon erratum 161010801 describes the limitation of HiSilicon > platforms Hip06/Hip07 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 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 <shameerali.kolothum.thodi@huawei.com> > --- > drivers/iommu/arm-smmu-v3.c | 27 ++++++++++++++++++++++----- > 1 file changed, 22 insertions(+), 5 deletions(-) > > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c > index abe4b88..2636c85 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,29 @@ static void arm_smmu_get_resv_regions(struct device *dev, > 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; > > - region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH, > - prot, IOMMU_RESV_SW_MSI); > - if (!region) > - return; > + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode); > > - list_add_tail(®ion->list, head); > + if (smmu && (smmu->options & ARM_SMMU_OPT_RESV_HW_MSI) && > + dev_is_pci(dev)) { > + int ret; > + > + ret = iort_iommu_its_get_resv_regions(dev, head); This should be made fwnode dependent, it makes precious little sense to call IORT to reserve regions on a DT based platforms (I know the ARM_SMMU_OPT_RESV_HW_MSI option is only selected in ACPI (?) but comment applies regardless - have you prototyped a DT version too ?). Lorenzo > + if (ret) { > + dev_warn(dev, "HW MSI region reserve failed\n"); > + return; > + } > + } else { > + region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH, > + prot, IOMMU_RESV_SW_MSI); > + if (!region) > + return; > + > + list_add_tail(®ion->list, head); > + } > > iommu_dma_get_resv_regions(dev, head); > } > @@ -2611,6 +2627,7 @@ static void parse_driver_acpi_options(struct acpi_iort_smmu_v3 *iort_smmu, > switch (iort_smmu->model) { > case ACPI_IORT_SMMU_HISILICON_HI161X: > smmu->options |= ARM_SMMU_OPT_SKIP_PREFETCH; > + smmu->options |= ARM_SMMU_OPT_RESV_HW_MSI; > break; > default: > break; > -- > 1.9.1 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Lorenzo Pieralisi [mailto:lorenzo.pieralisi@arm.com] > Sent: Tuesday, June 13, 2017 2:13 PM > To: Shameerali Kolothum Thodi > Cc: marc.zyngier@arm.com; sudeep.holla@arm.com; will.deacon@arm.com; > robin.murphy@arm.com; hanjun.guo@linaro.org; Gabriele Paoloni; John > Garry; iommu@lists.linux-foundation.org; linux-arm- > kernel@lists.infradead.org; linux-acpi@vger.kernel.org; devel@acpica.org; > Linuxarm; Wangzhou (B); Guohanjun (Hanjun Guo) > Subject: Re: [PATCH 2/2] iommu/arm-smmu-v3:Enable ACPI based HiSilicon > erratum 161010801 > > On Tue, Jun 13, 2017 at 12:48:29PM +0100, shameer wrote: > > The HiSilicon erratum 161010801 describes the limitation of HiSilicon > > platforms Hip06/Hip07 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 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 <shameerali.kolothum.thodi@huawei.com> > > --- > > drivers/iommu/arm-smmu-v3.c | 27 ++++++++++++++++++++++----- > > 1 file changed, 22 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu- > v3.c > > index abe4b88..2636c85 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,29 @@ static void arm_smmu_get_resv_regions(struct > device *dev, > > 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; > > > > - region = iommu_alloc_resv_region(MSI_IOVA_BASE, > MSI_IOVA_LENGTH, > > - prot, IOMMU_RESV_SW_MSI); > > - if (!region) > > - return; > > + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode); > > > > - list_add_tail(®ion->list, head); > > + if (smmu && (smmu->options & ARM_SMMU_OPT_RESV_HW_MSI) > && > > + dev_is_pci(dev)) { > > + int ret; > > + > > + ret = iort_iommu_its_get_resv_regions(dev, head); > > This should be made fwnode dependent, it makes precious little sense to call > IORT to reserve regions on a DT based platforms (I know the > ARM_SMMU_OPT_RESV_HW_MSI option is only selected in ACPI (?) but > comment applies regardless - have you prototyped a DT version too ?). Ok. I will add a check here. I don't have a DT version for now as ACPI is our top priority at the moment. Thanks, Shameer
Hi Lorenzo, > -----Original Message----- > From: linuxarm-bounces@huawei.com [mailto:linuxarm- > bounces@huawei.com] On Behalf Of Shameerali Kolothum Thodi > Sent: Tuesday, June 13, 2017 3:53 PM > To: Lorenzo Pieralisi > Cc: marc.zyngier@arm.com; will.deacon@arm.com; Linuxarm; linux- > acpi@vger.kernel.org; iommu@lists.linux-foundation.org; > hanjun.guo@linaro.org; sudeep.holla@arm.com; robin.murphy@arm.com; > linux-arm-kernel@lists.infradead.org; devel@acpica.org > Subject: RE: [PATCH 2/2] iommu/arm-smmu-v3:Enable ACPI based HiSilicon > erratum 161010801 [...] > > > --- > > > drivers/iommu/arm-smmu-v3.c | 27 ++++++++++++++++++++++----- > > > 1 file changed, 22 insertions(+), 5 deletions(-) > > > > > > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu- > > v3.c > > > index abe4b88..2636c85 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,29 @@ static void > arm_smmu_get_resv_regions(struct > > device *dev, > > > 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; > > > > > > - region = iommu_alloc_resv_region(MSI_IOVA_BASE, > > MSI_IOVA_LENGTH, > > > - prot, IOMMU_RESV_SW_MSI); > > > - if (!region) > > > - return; > > > + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode); > > > > > > - list_add_tail(®ion->list, head); > > > + if (smmu && (smmu->options & ARM_SMMU_OPT_RESV_HW_MSI) > > && > > > + dev_is_pci(dev)) { > > > + int ret; > > > + > > > + ret = iort_iommu_its_get_resv_regions(dev, head); > > > > This should be made fwnode dependent, it makes precious little sense to > call > > IORT to reserve regions on a DT based platforms (I know the > > ARM_SMMU_OPT_RESV_HW_MSI option is only selected in ACPI (?) but > > comment applies regardless - have you prototyped a DT version too ?). > > Ok. I will add a check here. This is what I have in mind. Please take a look and let me know. I will send out a v2 of this series soon. .... if (smmu && (smmu->options & ARM_SMMU_OPT_RESV_HW_MSI) && dev_is_pci(dev)) { int ret = -EINVAL; if (!is_of_node(smmu->dev->fwnode)) ret = iort_iommu_its_get_resv_regions(dev, head); if (ret) { dev_warn(dev, "HW MSI region resv failed: %d\n", ret); return; } } else { --- Many thanks, Shameer
On Fri, Jun 16, 2017 at 09:43:52AM +0000, Shameerali Kolothum Thodi wrote: > Hi Lorenzo, > > > -----Original Message----- > > From: linuxarm-bounces@huawei.com [mailto:linuxarm- > > bounces@huawei.com] On Behalf Of Shameerali Kolothum Thodi > > Sent: Tuesday, June 13, 2017 3:53 PM > > To: Lorenzo Pieralisi > > Cc: marc.zyngier@arm.com; will.deacon@arm.com; Linuxarm; linux- > > acpi@vger.kernel.org; iommu@lists.linux-foundation.org; > > hanjun.guo@linaro.org; sudeep.holla@arm.com; robin.murphy@arm.com; > > linux-arm-kernel@lists.infradead.org; devel@acpica.org > > Subject: RE: [PATCH 2/2] iommu/arm-smmu-v3:Enable ACPI based HiSilicon > > erratum 161010801 > > [...] > > > > --- > > > > drivers/iommu/arm-smmu-v3.c | 27 ++++++++++++++++++++++----- > > > > 1 file changed, 22 insertions(+), 5 deletions(-) > > > > > > > > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu- > > > v3.c > > > > index abe4b88..2636c85 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,29 @@ static void > > arm_smmu_get_resv_regions(struct > > > device *dev, > > > > 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; > > > > > > > > - region = iommu_alloc_resv_region(MSI_IOVA_BASE, > > > MSI_IOVA_LENGTH, > > > > - prot, IOMMU_RESV_SW_MSI); > > > > - if (!region) > > > > - return; > > > > + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode); > > > > > > > > - list_add_tail(®ion->list, head); > > > > + if (smmu && (smmu->options & ARM_SMMU_OPT_RESV_HW_MSI) > > > && > > > > + dev_is_pci(dev)) { > > > > + int ret; > > > > + > > > > + ret = iort_iommu_its_get_resv_regions(dev, head); > > > > > > This should be made fwnode dependent, it makes precious little sense to > > call > > > IORT to reserve regions on a DT based platforms (I know the > > > ARM_SMMU_OPT_RESV_HW_MSI option is only selected in ACPI (?) but > > > comment applies regardless - have you prototyped a DT version too ?). > > > > Ok. I will add a check here. > > This is what I have in mind. Please take a look and let me know. I will send out > a v2 of this series soon. > .... > if (smmu && (smmu->options & ARM_SMMU_OPT_RESV_HW_MSI) && > dev_is_pci(dev)) { > int ret = -EINVAL; > > if (!is_of_node(smmu->dev->fwnode)) > ret = iort_iommu_its_get_resv_regions(dev, head); > > if (ret) { > dev_warn(dev, "HW MSI region resv failed: %d\n", ret); > return; > } > } else { The fwnode handling is fine, I do not like much the: dev_is_pci() check because it relies on implicit knowledge of the platform and the quirks you need (ie you know that it is _just_ a PCI RC quirk implicitly), the logic behind reserving the regions is a bit convoluted and not easy to understand at all. Let me try to rephrase it: you know, through an SMMU model number, that your PCI RC handles MSI in a specific way, but by reading the code above this is not clear at all, at least to me. This is a PCI RC quirk but it does not depend on any PCI RC specific firmware binding whatsoever, that's what is a bit hard to understand. Anyway you can post the patches and we will take it from there to see if there is a way to improve it. Thanks, Lorenzo
> -----Original Message----- > From: Lorenzo Pieralisi [mailto:lorenzo.pieralisi@arm.com] > Sent: Friday, June 16, 2017 12:17 PM > To: Shameerali Kolothum Thodi > Cc: marc.zyngier@arm.com; will.deacon@arm.com; Linuxarm; linux- > acpi@vger.kernel.org; iommu@lists.linux-foundation.org; > hanjun.guo@linaro.org; sudeep.holla@arm.com; robin.murphy@arm.com; > linux-arm-kernel@lists.infradead.org; devel@acpica.org > Subject: Re: [PATCH 2/2] iommu/arm-smmu-v3:Enable ACPI based HiSilicon > erratum 161010801 > > On Fri, Jun 16, 2017 at 09:43:52AM +0000, Shameerali Kolothum Thodi wrote: > > Hi Lorenzo, > > > > > -----Original Message----- > > > From: linuxarm-bounces@huawei.com [mailto:linuxarm- > > > bounces@huawei.com] On Behalf Of Shameerali Kolothum Thodi > > > Sent: Tuesday, June 13, 2017 3:53 PM > > > To: Lorenzo Pieralisi > > > Cc: marc.zyngier@arm.com; will.deacon@arm.com; Linuxarm; linux- > > > acpi@vger.kernel.org; iommu@lists.linux-foundation.org; > > > hanjun.guo@linaro.org; sudeep.holla@arm.com; > robin.murphy@arm.com; > > > linux-arm-kernel@lists.infradead.org; devel@acpica.org > > > Subject: RE: [PATCH 2/2] iommu/arm-smmu-v3:Enable ACPI based > HiSilicon > > > erratum 161010801 > > > > [...] > > > > > --- > > > > > drivers/iommu/arm-smmu-v3.c | 27 ++++++++++++++++++++++---- > - > > > > > 1 file changed, 22 insertions(+), 5 deletions(-) > > > > > > > > > > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm- > smmu- > > > > v3.c > > > > > index abe4b88..2636c85 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,29 @@ static void > > > arm_smmu_get_resv_regions(struct > > > > device *dev, > > > > > 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; > > > > > > > > > > - region = iommu_alloc_resv_region(MSI_IOVA_BASE, > > > > MSI_IOVA_LENGTH, > > > > > - prot, > IOMMU_RESV_SW_MSI); > > > > > - if (!region) > > > > > - return; > > > > > + smmu = arm_smmu_get_by_fwnode(fwspec- > >iommu_fwnode); > > > > > > > > > > - list_add_tail(®ion->list, head); > > > > > + if (smmu && (smmu->options & > ARM_SMMU_OPT_RESV_HW_MSI) > > > > && > > > > > + dev_is_pci(dev)) { > > > > > + int ret; > > > > > + > > > > > + ret = iort_iommu_its_get_resv_regions(dev, head); > > > > > > > > This should be made fwnode dependent, it makes precious little sense > to > > > call > > > > IORT to reserve regions on a DT based platforms (I know the > > > > ARM_SMMU_OPT_RESV_HW_MSI option is only selected in ACPI (?) > but > > > > comment applies regardless - have you prototyped a DT version too ?). > > > > > > Ok. I will add a check here. > > > > This is what I have in mind. Please take a look and let me know. I will send > out > > a v2 of this series soon. > > .... > > if (smmu && (smmu->options & ARM_SMMU_OPT_RESV_HW_MSI) && > > dev_is_pci(dev)) { > > int ret = -EINVAL; > > > > if (!is_of_node(smmu->dev->fwnode)) > > ret = iort_iommu_its_get_resv_regions(dev, head); > > > > if (ret) { > > dev_warn(dev, "HW MSI region resv failed: %d\n", ret); > > return; > > } > > } else { > > The fwnode handling is fine, I do not like much the: > > dev_is_pci() > > check because it relies on implicit knowledge of the platform and > the quirks you need (ie you know that it is _just_ a PCI RC quirk > implicitly), the logic behind reserving the regions is a bit > convoluted and not easy to understand at all. > > Let me try to rephrase it: you know, through an SMMU model number, > that your PCI RC handles MSI in a specific way, but by reading the > code above this is not clear at all, at least to me. This is a PCI > RC quirk but it does not depend on any PCI RC specific firmware binding > whatsoever, that's what is a bit hard to understand. Right. I had a thought of limiting the iort_iommu_its_get_resv_regions to pci devices only. Just like the way iommu_dma_get_resv_regions() does now. But not sure there will ever be a platform which requires this for non-pci devices as well. Thanks, Shameer
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c index abe4b88..2636c85 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,29 @@ static void arm_smmu_get_resv_regions(struct device *dev, 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; - region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH, - prot, IOMMU_RESV_SW_MSI); - if (!region) - return; + smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode); - list_add_tail(®ion->list, head); + if (smmu && (smmu->options & ARM_SMMU_OPT_RESV_HW_MSI) && + dev_is_pci(dev)) { + int ret; + + ret = iort_iommu_its_get_resv_regions(dev, head); + if (ret) { + dev_warn(dev, "HW MSI region reserve failed\n"); + return; + } + } else { + region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH, + prot, IOMMU_RESV_SW_MSI); + if (!region) + return; + + list_add_tail(®ion->list, head); + } iommu_dma_get_resv_regions(dev, head); } @@ -2611,6 +2627,7 @@ static void parse_driver_acpi_options(struct acpi_iort_smmu_v3 *iort_smmu, switch (iort_smmu->model) { case ACPI_IORT_SMMU_HISILICON_HI161X: smmu->options |= ARM_SMMU_OPT_SKIP_PREFETCH; + smmu->options |= ARM_SMMU_OPT_RESV_HW_MSI; break; default: break;
The HiSilicon erratum 161010801 describes the limitation of HiSilicon platforms Hip06/Hip07 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 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 <shameerali.kolothum.thodi@huawei.com> --- drivers/iommu/arm-smmu-v3.c | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-)