From: Baolu Lu <baolu.lu@linux.intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>
Cc: "Jiang, Dave" <dave.jiang@intel.com>,
Will Deacon <will@kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
Vinod Koul <vkoul@kernel.org>,
"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
Jason Gunthorpe <jgg@nvidia.com>,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v8 02/11] iommu: Add max_pasids field in struct dev_iommu
Date: Fri, 10 Jun 2022 17:07:10 +0800 [thread overview]
Message-ID: <79c41aab-ec9c-3f5e-65d1-ff857f57816e@linux.intel.com> (raw)
In-Reply-To: <BN9PR11MB5276C7B4FAC55C58A5466EFC8CA69@BN9PR11MB5276.namprd11.prod.outlook.com>
On 2022/6/10 17:01, Tian, Kevin wrote:
>> From: Baolu Lu <baolu.lu@linux.intel.com>
>> Sent: Friday, June 10, 2022 2:47 PM
>>
>> On 2022/6/10 03:01, Raj, Ashok wrote:
>>> On Tue, Jun 07, 2022 at 09:49:33AM +0800, Lu Baolu wrote:
>>>> @@ -218,6 +219,30 @@ static void dev_iommu_free(struct device *dev)
>>>> kfree(param);
>>>> }
>>>>
>>>> +static u32 dev_iommu_get_max_pasids(struct device *dev)
>>>> +{
>>>> + u32 max_pasids = dev->iommu->iommu_dev->max_pasids;
>>>> + u32 num_bits;
>>>> + int ret;
>>>> +
>>>> + if (!max_pasids)
>>>> + return 0;
>>>> +
>>>> + if (dev_is_pci(dev)) {
>>>> + ret = pci_max_pasids(to_pci_dev(dev));
>>>> + if (ret < 0)
>>>> + return 0;
>>>> +
>>>> + return min_t(u32, max_pasids, ret);
>>>
>>> Ah.. that answers my other question to consider device pasid-max. I guess
>>> if we need any enforcement of restricting devices that aren't supporting
>>> the full PASID, that will be done by some higher layer?
>>
>> The mm->pasid style of SVA is explicitly enabled through
>> iommu_dev_enable_feature(IOMMU_DEV_FEAT_SVA). The IOMMU driver
>> specific
>> restriction might be put there?
>>
>>>
>>> too many returns in this function, maybe setup all returns to the end of
>>> the function might be elegant?
>>
>> I didn't find cleanup room after a quick scan of the code. But sure, let
>> me go through code again offline.
>>
>
> If we do care:
>
> +static u32 dev_iommu_get_max_pasids(struct device *dev)
> +{
> + u32 max_pasids = 0,
> + u32 num_bits = 0;
> + int ret;
> +
> + if (dev_is_pci(dev)) {
> + ret = pci_max_pasids(to_pci_dev(dev));
> + if (ret > 0)
> + max_pasids = ret;
> + } else {
> + ret = device_property_read_u32(dev, "pasid-num-bits", &num_bits);
> + if (!ret)
> + max_pasids = 1UL << num_bits;
> + }
> +
> + return min_t(u32, max_pasids, dev->iommu->iommu_dev->max_pasids);
> +}
Great! Cleaner and more compact than mine. Thank you!
Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Baolu Lu <baolu.lu@linux.intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>, "Raj, Ashok" <ashok.raj@intel.com>
Cc: baolu.lu@linux.intel.com, Joerg Roedel <joro@8bytes.org>,
Jason Gunthorpe <jgg@nvidia.com>,
Christoph Hellwig <hch@infradead.org>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
"Jiang, Dave" <dave.jiang@intel.com>,
Vinod Koul <vkoul@kernel.org>, Eric Auger <eric.auger@redhat.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 02/11] iommu: Add max_pasids field in struct dev_iommu
Date: Fri, 10 Jun 2022 17:07:10 +0800 [thread overview]
Message-ID: <79c41aab-ec9c-3f5e-65d1-ff857f57816e@linux.intel.com> (raw)
In-Reply-To: <BN9PR11MB5276C7B4FAC55C58A5466EFC8CA69@BN9PR11MB5276.namprd11.prod.outlook.com>
On 2022/6/10 17:01, Tian, Kevin wrote:
>> From: Baolu Lu <baolu.lu@linux.intel.com>
>> Sent: Friday, June 10, 2022 2:47 PM
>>
>> On 2022/6/10 03:01, Raj, Ashok wrote:
>>> On Tue, Jun 07, 2022 at 09:49:33AM +0800, Lu Baolu wrote:
>>>> @@ -218,6 +219,30 @@ static void dev_iommu_free(struct device *dev)
>>>> kfree(param);
>>>> }
>>>>
>>>> +static u32 dev_iommu_get_max_pasids(struct device *dev)
>>>> +{
>>>> + u32 max_pasids = dev->iommu->iommu_dev->max_pasids;
>>>> + u32 num_bits;
>>>> + int ret;
>>>> +
>>>> + if (!max_pasids)
>>>> + return 0;
>>>> +
>>>> + if (dev_is_pci(dev)) {
>>>> + ret = pci_max_pasids(to_pci_dev(dev));
>>>> + if (ret < 0)
>>>> + return 0;
>>>> +
>>>> + return min_t(u32, max_pasids, ret);
>>>
>>> Ah.. that answers my other question to consider device pasid-max. I guess
>>> if we need any enforcement of restricting devices that aren't supporting
>>> the full PASID, that will be done by some higher layer?
>>
>> The mm->pasid style of SVA is explicitly enabled through
>> iommu_dev_enable_feature(IOMMU_DEV_FEAT_SVA). The IOMMU driver
>> specific
>> restriction might be put there?
>>
>>>
>>> too many returns in this function, maybe setup all returns to the end of
>>> the function might be elegant?
>>
>> I didn't find cleanup room after a quick scan of the code. But sure, let
>> me go through code again offline.
>>
>
> If we do care:
>
> +static u32 dev_iommu_get_max_pasids(struct device *dev)
> +{
> + u32 max_pasids = 0,
> + u32 num_bits = 0;
> + int ret;
> +
> + if (dev_is_pci(dev)) {
> + ret = pci_max_pasids(to_pci_dev(dev));
> + if (ret > 0)
> + max_pasids = ret;
> + } else {
> + ret = device_property_read_u32(dev, "pasid-num-bits", &num_bits);
> + if (!ret)
> + max_pasids = 1UL << num_bits;
> + }
> +
> + return min_t(u32, max_pasids, dev->iommu->iommu_dev->max_pasids);
> +}
Great! Cleaner and more compact than mine. Thank you!
Best regards,
baolu
next prev parent reply other threads:[~2022-06-10 9:07 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-07 1:49 [PATCH v8 00/11] iommu: SVA and IOPF refactoring Lu Baolu
2022-06-07 1:49 ` Lu Baolu
2022-06-07 1:49 ` [PATCH v8 01/11] iommu: Add max_pasids field in struct iommu_device Lu Baolu
2022-06-07 1:49 ` Lu Baolu
2022-06-09 17:25 ` Raj, Ashok
2022-06-09 17:25 ` Raj, Ashok
2022-06-09 23:53 ` Jason Gunthorpe via iommu
2022-06-09 23:53 ` Jason Gunthorpe
2022-06-10 8:45 ` Tian, Kevin
2022-06-10 8:45 ` Tian, Kevin
2022-06-10 6:33 ` Baolu Lu
2022-06-10 6:33 ` Baolu Lu
2022-06-07 1:49 ` [PATCH v8 02/11] iommu: Add max_pasids field in struct dev_iommu Lu Baolu
2022-06-07 1:49 ` Lu Baolu
2022-06-09 19:01 ` Raj, Ashok
2022-06-09 19:01 ` Raj, Ashok
2022-06-10 6:46 ` Baolu Lu
2022-06-10 6:46 ` Baolu Lu
2022-06-10 9:01 ` Tian, Kevin
2022-06-10 9:01 ` Tian, Kevin
2022-06-10 9:07 ` Baolu Lu [this message]
2022-06-10 9:07 ` Baolu Lu
2022-06-07 1:49 ` [PATCH v8 03/11] iommu: Remove SVM_FLAG_SUPERVISOR_MODE support Lu Baolu
2022-06-07 1:49 ` Lu Baolu
2022-06-07 1:49 ` [PATCH v8 04/11] iommu: Add sva iommu_domain support Lu Baolu
2022-06-07 1:49 ` Lu Baolu
2022-06-09 20:25 ` Raj, Ashok
2022-06-09 20:25 ` Raj, Ashok
2022-06-10 7:16 ` Baolu Lu
2022-06-10 7:16 ` Baolu Lu
2022-06-17 7:43 ` Tian, Kevin
2022-06-17 7:43 ` Tian, Kevin
2022-06-20 0:34 ` Baolu Lu
2022-06-20 0:34 ` Baolu Lu
2022-06-07 1:49 ` [PATCH v8 05/11] iommu/vt-d: Add SVA domain support Lu Baolu
2022-06-07 1:49 ` Lu Baolu
2022-06-17 7:47 ` Tian, Kevin
2022-06-17 7:47 ` Tian, Kevin
2022-06-20 0:35 ` Baolu Lu
2022-06-20 0:35 ` Baolu Lu
2022-06-07 1:49 ` [PATCH v8 06/11] arm-smmu-v3/sva: " Lu Baolu
2022-06-07 1:49 ` Lu Baolu
2022-06-07 1:49 ` [PATCH v8 07/11] iommu/sva: Refactoring iommu_sva_bind/unbind_device() Lu Baolu
2022-06-07 1:49 ` Lu Baolu
2022-06-07 1:49 ` [PATCH v8 08/11] iommu: Remove SVA related callbacks from iommu ops Lu Baolu
2022-06-07 1:49 ` Lu Baolu
2022-06-07 1:49 ` [PATCH v8 09/11] iommu: Prepare IOMMU domain for IOPF Lu Baolu
2022-06-07 1:49 ` Lu Baolu
2022-06-07 1:49 ` [PATCH v8 10/11] iommu: Per-domain I/O page fault handling Lu Baolu
2022-06-07 1:49 ` Lu Baolu
2022-06-07 1:49 ` [PATCH v8 11/11] iommu: Rename iommu-sva-lib.{c,h} Lu Baolu
2022-06-07 1:49 ` Lu Baolu
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=79c41aab-ec9c-3f5e-65d1-ff857f57816e@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=dave.jiang@intel.com \
--cc=hch@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@intel.com \
--cc=jean-philippe@linaro.com \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=vkoul@kernel.org \
--cc=will@kernel.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.