All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
To: devel@acpica.org
Subject: Re: [Devel] [PATCH v4 1/2] acpi:iort: Add an IORT helper function to reserve HW ITS address regions for IOMMU drivers
Date: Thu, 27 Jul 2017 11:12:55 +0100	[thread overview]
Message-ID: <20170727101255.GA15067@red-moon> (raw)
In-Reply-To: 5FC3163CFD30C246ABAA99954A238FA8383C0268@FRAEML521-MBX.china.huawei.com

[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]

On Thu, Jul 27, 2017 at 09:13:42AM +0000, Shameerali Kolothum Thodi wrote:

[...]

> > > >> +int iort_iommu_its_get_resv_regions(struct device *dev, struct
> > list_head *head)
> > > >> +{
> > > >> +	int i;
> > > >> +	struct acpi_iort_its_group *its;
> > > >> +	struct acpi_iort_node *node, *its_node = NULL;
> > > >> +	int resv = 0;
> > > >
> > > > Nit: int i, resv = 0;
> > > >
> > > > I can make these changes but I suspect this series will go via IOMMU
> > > > tree, let me know how you want to handle it.
> > > >
> > > > Lorenzo
> > > >
> > > >> +	node = iort_find_dev_node(dev);
> > > >> +	if (!node)
> > > >> +		return -ENODEV;
> > > >> +
> > >
> > > I'd suggest we also want a comment here to clarify that we're currently
> > > assuming straightforward topologies where all mappings for a given root
> > > complex/named component target the same ITS group. Otherwise we're
> > going
> > > to need somewhat more logic to iterate the its_node processing over
> > > every mapping (or every alias in the PCI case), but avoid creating
> > > duplicate entries.
> > 
> > You have a point and we have time to update the code. Short of reserving
> > all ITS regions for every device that maps to one at least, we could (even
> > pre-compute instead of looking it up on the fly) create a list of ITS
> > identifiers a given IORT node may map to and use that to reserve the
> > regions.
> 
> I am trying to understand the use case scenario discussed here.
> Apologies if it is a dumb query. 
> 
> My understanding is that, it is possible to have a PCI  RC iort node
> mapped to multiple ITS group nodes.  That is perfectly fine and given
> a dev input RID we can identify the ITS group the device points to
> using - iort_node_map_id().
> 
> But the above discussion seems to suggest that there might be
> situations where we have to go through all the mapped ITS groups and
> identify all the ITSs associated with the RC.  Clearly I am missing
> something.

I reckon Robin was referring to this:

https://patchwork.kernel.org/patch/9757911/

Does this help ?

Thanks,
Lorenzo

WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
	"marc.zyngier@arm.com" <marc.zyngier@arm.com>,
	"sudeep.holla@arm.com" <sudeep.holla@arm.com>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"hanjun.guo@linaro.org" <hanjun.guo@linaro.org>,
	Gabriele Paoloni <gabriele.paoloni@huawei.com>,
	John Garry <john.garry@huawei.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"devel@acpica.org" <devel@acpica.org>,
	Linuxarm <linuxarm@huawei.com>,
	"Wangzhou (B)" <wangzhou1@hisilicon.com>,
	"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>
Subject: Re: [PATCH v4 1/2] acpi:iort: Add an IORT helper function to reserve HW ITS address regions for IOMMU drivers
Date: Thu, 27 Jul 2017 11:12:55 +0100	[thread overview]
Message-ID: <20170727101255.GA15067@red-moon> (raw)
In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA8383C0268@FRAEML521-MBX.china.huawei.com>

On Thu, Jul 27, 2017 at 09:13:42AM +0000, Shameerali Kolothum Thodi wrote:

[...]

> > > >> +int iort_iommu_its_get_resv_regions(struct device *dev, struct
> > list_head *head)
> > > >> +{
> > > >> +	int i;
> > > >> +	struct acpi_iort_its_group *its;
> > > >> +	struct acpi_iort_node *node, *its_node = NULL;
> > > >> +	int resv = 0;
> > > >
> > > > Nit: int i, resv = 0;
> > > >
> > > > I can make these changes but I suspect this series will go via IOMMU
> > > > tree, let me know how you want to handle it.
> > > >
> > > > Lorenzo
> > > >
> > > >> +	node = iort_find_dev_node(dev);
> > > >> +	if (!node)
> > > >> +		return -ENODEV;
> > > >> +
> > >
> > > I'd suggest we also want a comment here to clarify that we're currently
> > > assuming straightforward topologies where all mappings for a given root
> > > complex/named component target the same ITS group. Otherwise we're
> > going
> > > to need somewhat more logic to iterate the its_node processing over
> > > every mapping (or every alias in the PCI case), but avoid creating
> > > duplicate entries.
> > 
> > You have a point and we have time to update the code. Short of reserving
> > all ITS regions for every device that maps to one at least, we could (even
> > pre-compute instead of looking it up on the fly) create a list of ITS
> > identifiers a given IORT node may map to and use that to reserve the
> > regions.
> 
> I am trying to understand the use case scenario discussed here.
> Apologies if it is a dumb query. 
> 
> My understanding is that, it is possible to have a PCI  RC iort node
> mapped to multiple ITS group nodes.  That is perfectly fine and given
> a dev input RID we can identify the ITS group the device points to
> using - iort_node_map_id().
> 
> But the above discussion seems to suggest that there might be
> situations where we have to go through all the mapped ITS groups and
> identify all the ITSs associated with the RC.  Clearly I am missing
> something.

I reckon Robin was referring to this:

https://patchwork.kernel.org/patch/9757911/

Does this help ?

Thanks,
Lorenzo

WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/2] acpi:iort: Add an IORT helper function to reserve HW ITS address regions for IOMMU drivers
Date: Thu, 27 Jul 2017 11:12:55 +0100	[thread overview]
Message-ID: <20170727101255.GA15067@red-moon> (raw)
In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA8383C0268@FRAEML521-MBX.china.huawei.com>

On Thu, Jul 27, 2017 at 09:13:42AM +0000, Shameerali Kolothum Thodi wrote:

[...]

> > > >> +int iort_iommu_its_get_resv_regions(struct device *dev, struct
> > list_head *head)
> > > >> +{
> > > >> +	int i;
> > > >> +	struct acpi_iort_its_group *its;
> > > >> +	struct acpi_iort_node *node, *its_node = NULL;
> > > >> +	int resv = 0;
> > > >
> > > > Nit: int i, resv = 0;
> > > >
> > > > I can make these changes but I suspect this series will go via IOMMU
> > > > tree, let me know how you want to handle it.
> > > >
> > > > Lorenzo
> > > >
> > > >> +	node = iort_find_dev_node(dev);
> > > >> +	if (!node)
> > > >> +		return -ENODEV;
> > > >> +
> > >
> > > I'd suggest we also want a comment here to clarify that we're currently
> > > assuming straightforward topologies where all mappings for a given root
> > > complex/named component target the same ITS group. Otherwise we're
> > going
> > > to need somewhat more logic to iterate the its_node processing over
> > > every mapping (or every alias in the PCI case), but avoid creating
> > > duplicate entries.
> > 
> > You have a point and we have time to update the code. Short of reserving
> > all ITS regions for every device that maps to one at least, we could (even
> > pre-compute instead of looking it up on the fly) create a list of ITS
> > identifiers a given IORT node may map to and use that to reserve the
> > regions.
> 
> I am trying to understand the use case scenario discussed here.
> Apologies if it is a dumb query. 
> 
> My understanding is that, it is possible to have a PCI  RC iort node
> mapped to multiple ITS group nodes.  That is perfectly fine and given
> a dev input RID we can identify the ITS group the device points to
> using - iort_node_map_id().
> 
> But the above discussion seems to suggest that there might be
> situations where we have to go through all the mapped ITS groups and
> identify all the ITSs associated with the RC.  Clearly I am missing
> something.

I reckon Robin was referring to this:

https://patchwork.kernel.org/patch/9757911/

Does this help ?

Thanks,
Lorenzo

             reply	other threads:[~2017-07-27 10:12 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-27 10:12 Lorenzo Pieralisi [this message]
2017-07-27 10:12 ` [PATCH v4 1/2] acpi:iort: Add an IORT helper function to reserve HW ITS address regions for IOMMU drivers Lorenzo Pieralisi
2017-07-27 10:12 ` Lorenzo Pieralisi
  -- strict thread matches above, loose matches on Subject: below --
2017-07-28 15:48 [Devel] " Shameerali Kolothum Thodi
2017-07-28 15:48 ` Shameerali Kolothum Thodi
2017-07-28 15:48 ` Shameerali Kolothum Thodi
2017-07-28  9:57 [Devel] " Lorenzo Pieralisi
2017-07-28  9:57 ` Lorenzo Pieralisi
2017-07-28  9:57 ` Lorenzo Pieralisi
2017-07-27 13:26 [Devel] " Shameerali Kolothum Thodi
2017-07-27 13:26 ` Shameerali Kolothum Thodi
2017-07-27 13:26 ` Shameerali Kolothum Thodi
2017-07-27 11:13 [Devel] " Robin Murphy
2017-07-27 11:13 ` Robin Murphy
2017-07-27 11:13 ` Robin Murphy
2017-07-27  9:13 [Devel] " Shameerali Kolothum Thodi
2017-07-27  9:13 ` Shameerali Kolothum Thodi
2017-07-27  9:13 ` Shameerali Kolothum Thodi
2017-07-26  9:52 [Devel] " Lorenzo Pieralisi
2017-07-26  9:52 ` Lorenzo Pieralisi
2017-07-26  9:52 ` Lorenzo Pieralisi
2017-07-25 17:32 [Devel] " Robin Murphy
2017-07-25 17:32 ` Robin Murphy
2017-07-25 17:32 ` Robin Murphy
2017-07-25 17:11 [Devel] " Lorenzo Pieralisi
2017-07-25 17:11 ` Lorenzo Pieralisi
2017-07-25 17:11 ` Lorenzo Pieralisi
2017-07-25 11:17 [Devel] [PATCH v4 2/2] iommu/dma: Add HW MSI address regions reservation " Shameer Kolothum
2017-07-25 11:17 ` Shameer Kolothum
2017-07-25 11:17 ` Shameer Kolothum
2017-07-25 11:17 [Devel] [PATCH v4 1/2] acpi:iort: Add an IORT helper function to reserve HW ITS address regions " Shameer Kolothum
2017-07-25 11:17 ` Shameer Kolothum
2017-07-25 11:17 ` Shameer Kolothum
2017-07-25 11:17 [Devel] [PATCH v4 0/2] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI) Shameer Kolothum
2017-07-25 11:17 ` Shameer Kolothum
2017-07-25 11:17 ` Shameer Kolothum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170727101255.GA15067@red-moon \
    --to=devel@acpica.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.