diff mbox series

[v3,2/2] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801

Message ID 20170623145801.325244-3-shameerali.kolothum.thodi@huawei.com
State New
Headers show
Series iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI) | expand

Commit Message

Shameerali Kolothum Thodi June 23, 2017, 2:58 p.m. UTC 
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 | 30 ++++++++++++++++++++++++++----
 1 file changed, 26 insertions(+), 4 deletions(-)

-- 
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

Comments

Will Deacon July 4, 2017, 5:38 p.m. UTC | #1 
On Fri, Jun 23, 2017 at 03:58:01PM +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 | 30 ++++++++++++++++++++++++++----

>  1 file changed, 26 insertions(+), 4 deletions(-)

> 

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

> 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,

>  				      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,

> -					 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.

> +	if (WARN_ON(!smmu))


Again, how does this trigger?

>  		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?

Will
--
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
Shameerali Kolothum Thodi July 5, 2017, 9:48 a.m. UTC | #2 
> -----Original Message-----

> From: Will Deacon [mailto:will.deacon@arm.com]

> Sent: Tuesday, July 04, 2017 6:38 PM

> To: Shameerali Kolothum Thodi

> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;

> sudeep.holla@arm.com; robin.murphy@arm.com; hanjun.guo@linaro.org;

> Gabriele Paoloni; John Garry; Linuxarm; linux-acpi@vger.kernel.org;

> iommu@lists.linux-foundation.org; Wangzhou (B); Guohanjun (Hanjun Guo);

> linux-arm-kernel@lists.infradead.org; devel@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:

> > 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 | 30 ++++++++++++++++++++++++++----

> >  1 file changed, 26 insertions(+), 4 deletions(-)

> >

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

> v3.c

> > 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,

> >  				      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,

> > -					 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;

> > +	if (WARN_ON(!smmu))

>

> Again, how does this trigger?

> >  		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. 

Thanks,
Shameer



--
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
Will Deacon July 14, 2017, 7:33 p.m. UTC | #3 
On Wed, Jul 05, 2017 at 09:48:53AM +0000, Shameerali Kolothum Thodi wrote:
> 

> 

> > -----Original Message-----

> > From: Will Deacon [mailto:will.deacon@arm.com]

> > Sent: Tuesday, July 04, 2017 6:38 PM

> > To: Shameerali Kolothum Thodi

> > Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;

> > sudeep.holla@arm.com; robin.murphy@arm.com; hanjun.guo@linaro.org;

> > Gabriele Paoloni; John Garry; Linuxarm; linux-acpi@vger.kernel.org;

> > iommu@lists.linux-foundation.org; Wangzhou (B); Guohanjun (Hanjun Guo);

> > linux-arm-kernel@lists.infradead.org; devel@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:

> > > 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 | 30 ++++++++++++++++++++++++++----

> > >  1 file changed, 26 insertions(+), 4 deletions(-)

> > >

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

> > v3.c

> > > 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,

> > >  				      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,

> > > -					 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;

> 

> > > +	if (WARN_ON(!smmu))

> >

> > Again, how does this trigger?

> > >  		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
--
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
Shameerali Kolothum Thodi July 19, 2017, 10:48 a.m. UTC | #4 
> -----Original Message-----

> From: Will Deacon [mailto:will.deacon@arm.com]

> Sent: Friday, July 14, 2017 8:33 PM

> To: Shameerali Kolothum Thodi

> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;

> sudeep.holla@arm.com; robin.murphy@arm.com; hanjun.guo@linaro.org;

> Gabriele Paoloni; John Garry; Linuxarm; linux-acpi@vger.kernel.org;

> iommu@lists.linux-foundation.org; Wangzhou (B); Guohanjun (Hanjun Guo);

> linux-arm-kernel@lists.infradead.org; devel@acpica.org

> Subject: Re: [PATCH v3 2/2] iommu/arm-smmu-v3:Enable ACPI based

> HiSilicon erratum 161010801

> 

[...]
> > > > -	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.


Below is what I have in mind for the common function for msi reserve.
But just wondering invoking iort_ functions from iommu code 
is acceptable or not . Could you please take a look and let me know.

Many thanks,
Shameer--- 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>
@@ -198,6 +199,24 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
 }
 EXPORT_SYMBOL(iommu_dma_get_resv_regions);
 
+/**
+ * iommu_dma_get_msi_resv_regions - Reserved region driver helper
+ * @dev: Device from iommu_get_resv_regions()
+ * @list: Reserved region list from iommu_get_resv_regions()
+ *
+ * IOMMU drivers can use this to implement their .get_resv_regions
+ * callback for HW MSI specific reservations. For now, this only
+ * covers ITS MSI region reservation using ACPI IORT helper function.
+ */
+int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
+{
+	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
+		return iort_iommu_its_get_resv_regions(dev, list);
+
+	return -ENODEV;
+}
+EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
--
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
Robin Murphy July 20, 2017, 2:31 p.m. UTC | #5 
On 19/07/17 11:48, Shameerali Kolothum Thodi wrote:
> 

> 

>> -----Original Message-----

>> From: Will Deacon [mailto:will.deacon@arm.com]

>> Sent: Friday, July 14, 2017 8:33 PM

>> To: Shameerali Kolothum Thodi

>> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;

>> sudeep.holla@arm.com; robin.murphy@arm.com; hanjun.guo@linaro.org;

>> Gabriele Paoloni; John Garry; Linuxarm; linux-acpi@vger.kernel.org;

>> iommu@lists.linux-foundation.org; Wangzhou (B); Guohanjun (Hanjun Guo);

>> linux-arm-kernel@lists.infradead.org; devel@acpica.org

>> Subject: Re: [PATCH v3 2/2] iommu/arm-smmu-v3:Enable ACPI based

>> HiSilicon erratum 161010801

>>

> [...]

>>>>> -	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.

> 

> Below is what I have in mind for the common function for msi reserve.

> But just wondering invoking iort_ functions from iommu code 

> is acceptable or not . Could you please take a look and let me know.


At that point, it seems like we might as well just roll it into
iommu_dma_get_resv_regions() directly[1]. It probably makes sense for
any DT equivalent to be described generically, rather than
SMMU-specific, so parsing that would fit into common code as well.

Then in the SMMU drivers we can skip creating the SW_MSI region if
iommu-dma gave us back any real ones (and remove the apparently
unnecessary resv_msi check in VFIO). Or be lazy and just leave it, as it
doesn't seem to do much harm to have both.

Robin.

[1] This is what I hacked up locally on top of patch #1:
----->8-----

--
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.htmldiff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 9d1cebe7f6cb..50292827da49 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>
@@ -174,6 +175,10 @@ 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_its_get_resv_regions(dev, list) < 0)
+		return;
+
 	if (!dev_is_pci(dev))
 		return;
Shameerali Kolothum Thodi July 20, 2017, 3:30 p.m. UTC | #6 
> -----Original Message-----

> From: Robin Murphy [mailto:robin.murphy@arm.com]

> Sent: Thursday, July 20, 2017 3:32 PM

> To: Shameerali Kolothum Thodi; Will Deacon

> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;

> sudeep.holla@arm.com; hanjun.guo@linaro.org; Gabriele Paoloni; John

> Garry; Linuxarm; linux-acpi@vger.kernel.org; iommu@lists.linux-

> foundation.org; Wangzhou (B); Guohanjun (Hanjun Guo); linux-arm-

> kernel@lists.infradead.org; devel@acpica.org

> Subject: Re: [PATCH v3 2/2] iommu/arm-smmu-v3:Enable ACPI based

> HiSilicon erratum 161010801

> 

> On 19/07/17 11:48, Shameerali Kolothum Thodi wrote:

> >

> >

> >> -----Original Message-----

> >> From: Will Deacon [mailto:will.deacon@arm.com]

> >> Sent: Friday, July 14, 2017 8:33 PM

> >> To: Shameerali Kolothum Thodi

> >> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;

> >> sudeep.holla@arm.com; robin.murphy@arm.com;

> hanjun.guo@linaro.org;

> >> Gabriele Paoloni; John Garry; Linuxarm; linux-acpi@vger.kernel.org;

> >> iommu@lists.linux-foundation.org; Wangzhou (B); Guohanjun (Hanjun

> Guo);

> >> linux-arm-kernel@lists.infradead.org; devel@acpica.org

> >> Subject: Re: [PATCH v3 2/2] iommu/arm-smmu-v3:Enable ACPI based

> >> HiSilicon erratum 161010801

> >>

> > [...]

> >>>>> -	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.

> >

> > Below is what I have in mind for the common function for msi reserve.

> > But just wondering invoking iort_ functions from iommu code

> > is acceptable or not . Could you please take a look and let me know.

> 

> At that point, it seems like we might as well just roll it into

> iommu_dma_get_resv_regions() directly[1]. It probably makes sense for

> any DT equivalent to be described generically, rather than

> SMMU-specific, so parsing that would fit into common code as well.

> 

> Then in the SMMU drivers we can skip creating the SW_MSI region if

> iommu-dma gave us back any real ones (and remove the apparently

> unnecessary resv_msi check in VFIO). Or be lazy and just leave it, as it

> doesn't seem to do much harm to have both.


Ok, If I read that correctly, we don’t need any changes to SMMU driver for
now and this will be a generic change rather than a HiSi quirk.

So is it ok, if I just send the patch#1 rebased on 4.13-rc1?  

Thanks,
Shameer

> 

> [1] This is what I hacked up locally on top of patch #1:

> ----->8-----

> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c

> index 9d1cebe7f6cb..50292827da49 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>

> @@ -174,6 +175,10 @@ 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_its_get_resv_regions(dev, list) < 0)

> +		return;

> +

>  	if (!dev_is_pci(dev))

>  		return;
diff mbox series

Patch

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
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,
 				      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,
-					 prot, IOMMU_RESV_SW_MSI);
-	if (!region)
+	smmu = arm_smmu_get_by_fwnode(fwspec->iommu_fwnode);
+	if (WARN_ON(!smmu))
 		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);
+
+		if (resv < 0) {
+			dev_warn(dev, "HW MSI region resv failed: %d\n", resv);
+			return;
+		}
+	}
+
+	if (!resv) {
+		region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
+						 prot, IOMMU_RESV_SW_MSI);
+		if (!region)
+			return;
+
+		list_add_tail(&region->list, head);
+	}
 
 	iommu_dma_get_resv_regions(dev, head);
 }
@@ -2611,6 +2632,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;