linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>
Cc: Linuxarm <linuxarm@huawei.com>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	wanghuiqiang <wanghuiqiang@huawei.com>,
	"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>,
	"steven.price@arm.com" <steven.price@arm.com>,
	"Sami.Mujawar@arm.com" <Sami.Mujawar@arm.com>,
	"jon@solid-run.com" <jon@solid-run.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>
Subject: Re: [PATCH v3 08/10] iommu/arm-smmu-v3: Reserve any RMR regions associated with a dev
Date: Mon, 10 May 2021 15:22:24 +0100	[thread overview]
Message-ID: <f7b586e4-f77c-e20b-dcf6-c383d7a7f2f4@arm.com> (raw)
In-Reply-To: <241042b6d1ea45f790e0766c6f5d3542@huawei.com>

On 2021-05-10 10:19, Shameerali Kolothum Thodi wrote:
> Hi Robin,
> 
>> -----Original Message-----
>> From: Robin Murphy [mailto:robin.murphy@arm.com]
>> Sent: 07 May 2021 11:02
>> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
>> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
>> iommu@lists.linux-foundation.org
>> Cc: Linuxarm <linuxarm@huawei.com>; lorenzo.pieralisi@arm.com;
>> joro@8bytes.org; wanghuiqiang <wanghuiqiang@huawei.com>; Guohanjun
>> (Hanjun Guo) <guohanjun@huawei.com>; steven.price@arm.com;
>> Sami.Mujawar@arm.com; jon@solid-run.com; eric.auger@redhat.com
>> Subject: Re: [PATCH v3 08/10] iommu/arm-smmu-v3: Reserve any RMR regions
>> associated with a dev
>>
>> On 2021-04-20 09:27, Shameer Kolothum wrote:
>>> Get RMR regions associated with a dev reserved so that there is
>>> a unity mapping for them in SMMU.
>>>
>>> Signed-off-by: Shameer Kolothum
>> <shameerali.kolothum.thodi@huawei.com>
>>> ---
>>>    drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 29
>> +++++++++++++++++++++
>>>    1 file changed, 29 insertions(+)
>>>
>>> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>> index 14e9c7034c04..8bacedf7bb34 100644
>>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>> @@ -2531,6 +2531,34 @@ static int arm_smmu_of_xlate(struct device *dev,
>> struct of_phandle_args *args)
>>>    	return iommu_fwspec_add_ids(dev, args->args, 1);
>>>    }
>>>
>>> +static bool arm_smmu_dev_has_rmr(struct arm_smmu_master *master,
>>> +				 struct iommu_rmr *e)
>>> +{
>>> +	int i;
>>> +
>>> +	for (i = 0; i < master->num_sids; i++) {
>>> +		if (e->sid == master->sids[i])
>>> +			return true;
>>> +	}
>>> +
>>> +	return false;
>>> +}
>>> +
>>> +static void arm_smmu_rmr_get_resv_regions(struct device *dev,
>>> +					  struct list_head *head)
>>> +{
>>> +	struct arm_smmu_master *master = dev_iommu_priv_get(dev);
>>> +	struct arm_smmu_device *smmu = master->smmu;
>>> +	struct iommu_rmr *rmr;
>>> +
>>> +	list_for_each_entry(rmr, &smmu->rmr_list, list) {
>>> +		if (!arm_smmu_dev_has_rmr(master, rmr))
>>> +			continue;
>>> +
>>> +		iommu_dma_get_rmr_resv_regions(dev, rmr, head);
>>> +	}
>>> +}
>>> +
>>
>> TBH I wouldn't have thought we need a driver-specific hook for this, or
>> is it too painful to correlate fwspec->iommu_fwnode back to the relevant
>> IORT node generically?
> 
>  From a quick look, I think I could get rid of the above with something like below,
> 
> ------8<----
> +static bool iommu_dma_dev_has_rmr(struct iommu_fwspec *fwspec,
> +                                 struct iommu_rmr *e)
> +{
> +       int i;
> +
> +       for (i = 0; i < fwspec->num_ids; i++) {
> +                if (e->sid == fwspec->ids[i])
> +                        return true;
> +        }
> +
> +        return false;
> +}
> +
> +
> +void iommu_dma_get_rmr_resv_regions(struct device *dev, struct list_head *list)
> +{
> +       struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> +       struct list_head rmr_list;
> +       struct iommu_rmr *rmr;
> +
> +       INIT_LIST_HEAD(&rmr_list);
> +       if (iommu_dma_get_rmrs(fwspec->iommu_fwnode, &rmr_list))
> +               return;
>          ...
> +       list_for_each_entry(rmr, &rmr_list, list) {
> +
> +       if (!iommu_dma_dev_has_rmr(fwspec, rmr)
> +           continue;
> +          ...
> +               region = iommu_alloc_resv_region(rmr->base_address,
> +                                                rmr->length, prot,
> +                                                type);
>           ...
> +       }
> +}
>   /**
>    * iommu_dma_get_resv_regions - Reserved region driver helper
>    * @dev: Device from iommu_get_resv_regions()
> @@ -188,10 +242,11 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
>          if (!is_of_node(dev_iommu_fwspec_get(dev)->iommu_fwnode))
>                  iort_iommu_msi_get_resv_regions(dev, list);
>   
> +       iommu_dma_get_rmr_resv_regions(dev, list);
>   }
> 
> ----8<----
> 
> But looking at the SMMUv2 code, the fwspec->ids is MASK:SID, so I am not
> sure the RMR sid can be compared directly to fwspec->ids above. Right? Or
> is there a better way here?

Ah, but consider how the IDs got there in the first place ;)

A mask will never be set on ACPI systems, since IORT (intentionally) 
only caters for straightforward mappings rather than arbitrary 
complexity, so the assumption of fwspec ID == SID is already baked in by 
virtue of arm_smmu_iort_xlate(). The IORT code is free to assume its own 
behaviour!

Robin.

> 
> Thanks,
> Shameer
> 
> 
>>
>>>    static void arm_smmu_get_resv_regions(struct device *dev,
>>>    				      struct list_head *head)
>>>    {
>>> @@ -2545,6 +2573,7 @@ static void arm_smmu_get_resv_regions(struct
>> device *dev,
>>>    	list_add_tail(&region->list, head);
>>>
>>>    	iommu_dma_get_resv_regions(dev, head);
>>> +	arm_smmu_rmr_get_resv_regions(dev, head);
>>>    }
>>>
>>>    static bool arm_smmu_dev_has_feature(struct device *dev,
>>>

  reply	other threads:[~2021-05-10 14:25 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-20  8:27 [PATCH v3 00/10] ACPI/IORT: Support for IORT RMR node Shameer Kolothum
2021-04-20  8:27 ` [PATCH v3 01/10] ACPI/IORT: Add support for RMR node parsing Shameer Kolothum
2021-04-20  8:27 ` [PATCH v3 02/10] iommu/dma: Introduce generic helper to retrieve RMR info Shameer Kolothum
2021-04-20 12:04   ` kernel test robot
2021-04-20 12:32   ` kernel test robot
2021-04-20 12:59   ` kernel test robot
2021-04-20  8:27 ` [PATCH v3 03/10] ACPI/IORT: Add a helper to retrieve RMR memory regions Shameer Kolothum
2021-04-20  8:27 ` [PATCH v3 04/10] iommu/dma: Add a helper function to reserve RMRs for IOMMU drivers Shameer Kolothum
2021-04-20 12:07   ` kernel test robot
2021-04-20 13:32   ` kernel test robot
2021-04-20  8:27 ` [PATCH v3 05/10] iommu/arm-smmu-v3: Introduce strtab init helper Shameer Kolothum
2021-04-20  8:27 ` [PATCH v3 06/10] iommu/arm-smmu-v3: Add bypass flag to arm_smmu_write_strtab_ent() Shameer Kolothum
2021-04-20  8:27 ` [PATCH v3 07/10] iommu/arm-smmu-v3: Get associated RMR info and install bypass STE Shameer Kolothum
2021-04-20  8:27 ` [PATCH v3 08/10] iommu/arm-smmu-v3: Reserve any RMR regions associated with a dev Shameer Kolothum
2021-05-07 10:01   ` Robin Murphy
2021-05-10  9:19     ` Shameerali Kolothum Thodi
2021-05-10 14:22       ` Robin Murphy [this message]
2021-04-20  8:27 ` [PATCH v3 09/10] iommu/arm-smmu: Get associated RMR info and install bypass SMR Shameer Kolothum
2021-05-06 15:17   ` Steven Price
2021-05-07  9:52     ` Robin Murphy
2021-05-10  8:40     ` Shameerali Kolothum Thodi
2021-05-10 11:51       ` Jon Nettleton
2021-04-20  8:27 ` [PATCH v3 10/10] iommu/arm-smmu: Reserve any RMR regions associated with a dev Shameer Kolothum
2021-04-20 14:18   ` kernel test robot

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=f7b586e4-f77c-e20b-dcf6-c383d7a7f2f4@arm.com \
    --to=robin.murphy@arm.com \
    --cc=Sami.Mujawar@arm.com \
    --cc=eric.auger@redhat.com \
    --cc=guohanjun@huawei.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jon@solid-run.com \
    --cc=joro@8bytes.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linuxarm@huawei.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=steven.price@arm.com \
    --cc=wanghuiqiang@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).