From: Baolu Lu <baolu.lu@linux.intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: baolu.lu@linux.intel.com, Kevin Tian <kevin.tian@intel.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Nicolin Chen <nicolinc@nvidia.com>, Yi Liu <yi.l.liu@intel.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
Joel Granados <j.granados@samsung.com>,
iommu@lists.linux.dev, virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 3/9] iommu: Add attachment handle to struct iopf_group
Date: Fri, 10 May 2024 22:30:10 +0800 [thread overview]
Message-ID: <0de7c71f-571a-4800-8f2b-9eda0c6b75de@linux.intel.com> (raw)
In-Reply-To: <20240510133824.GW4718@ziepe.ca>
On 2024/5/10 21:38, Jason Gunthorpe wrote:
> On Fri, May 10, 2024 at 11:14:20AM +0800, Baolu Lu wrote:
>> On 5/8/24 8:04 AM, Jason Gunthorpe wrote:
>>> On Tue, Apr 30, 2024 at 10:57:04PM +0800, Lu Baolu wrote:
>>>> @@ -206,8 +197,11 @@ void iommu_report_device_fault(struct device *dev, struct iopf_fault *evt)
>>>> if (group == &abort_group)
>>>> goto err_abort;
>>>> - group->domain = get_domain_for_iopf(dev, fault);
>>>> - if (!group->domain)
>>>> + if (!(fault->prm.flags & IOMMU_FAULT_PAGE_REQUEST_PASID_VALID) ||
>>>> + get_attach_handle_for_iopf(dev, fault->prm.pasid, group))
>>>> + get_attach_handle_for_iopf(dev, IOMMU_NO_PASID, group);
>>> That seems a bit weird looking?
>> Agreed.
>>
>>> get_attach_handle_for_iopf(dev,
>>> (fault->prm.flags &
>>> IOMMU_FAULT_PAGE_REQUEST_PASID_VALID) ? fault->prm.pasid : IOMMU_NO_PASID,
>>> group);
>> The logic here is that it tries the PASID domain and if it doesn't
>> exist, then tries the RID domain as well. I explained this in the commit
>> message:
>>
>> "
>> ... if the pasid table of a device is wholly managed by user space,
>> there is no domain attached to the PASID of the device ...
>> "
> Okay, it needs a comment in the code, and the RID fallback should be
> based aroudn checking for a NESTING domain type which includes the
> PASID table. (ie ARM and AMD not Intel)
It appears that Intel is just special. ARM, AMD, and RISC-V all support
a NESTING domain which includes the PASID table. So, how about defining
a special NESTING domain type for Intel? Like this,
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 35ae9a6f73d3..09b4e671dcee 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -173,6 +173,8 @@ struct iommu_domain_geometry {
#define __IOMMU_DOMAIN_NESTED (1U << 6) /* User-managed address
space nested
on a stage-2 translation
*/
+#define __IOMMU_DOMAIN_PASID (1U << 7) /* User-managed domain for a
+ specific PASID*/
#define IOMMU_DOMAIN_ALLOC_FLAGS ~__IOMMU_DOMAIN_DMA_FQ
/*
@@ -204,6 +206,9 @@ struct iommu_domain_geometry {
#define IOMMU_DOMAIN_SVA (__IOMMU_DOMAIN_SVA)
#define IOMMU_DOMAIN_PLATFORM (__IOMMU_DOMAIN_PLATFORM)
#define IOMMU_DOMAIN_NESTED (__IOMMU_DOMAIN_NESTED)
+#define IOMMU_DOMAIN_NESTED_PASID \
+ (__IOMMU_DOMAIN_NESTED | \
+ __IOMMU_DOMAIN_PASID)
And current IOMMU_DOMAIN_NESTED domain type is just for a nesting domain
with PASID table.
The Intel IOMMU driver will convert to use IOMMU_DOMAIN_NESTED_PASID in
the PASID interface series.
> We shouldn't just elevate a random PASID to the RID if it isn't
> approprite..
If above propose looks good to you, then I just need to add a domain
type check before RID fallback.
Best regards,
baolu
next prev parent reply other threads:[~2024-05-10 14:30 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 14:57 [PATCH v5 0/9] IOMMUFD: Deliver IO page faults to user space Lu Baolu
2024-04-30 14:57 ` [PATCH v5 1/9] iommu: Introduce domain attachment handle Lu Baolu
2024-05-15 7:17 ` Tian, Kevin
2024-05-19 10:07 ` Baolu Lu
2024-04-30 14:57 ` [PATCH v5 2/9] iommu: Replace sva_iommu with iommu_attach_handle Lu Baolu
2024-05-07 23:58 ` Jason Gunthorpe
2024-05-15 7:21 ` Tian, Kevin
2024-05-19 10:14 ` Baolu Lu
2024-05-20 3:18 ` Tian, Kevin
2024-04-30 14:57 ` [PATCH v5 3/9] iommu: Add attachment handle to struct iopf_group Lu Baolu
2024-05-08 0:04 ` Jason Gunthorpe
2024-05-10 3:14 ` Baolu Lu
2024-05-10 13:38 ` Jason Gunthorpe
2024-05-10 14:30 ` Baolu Lu [this message]
2024-05-10 16:28 ` Jason Gunthorpe
2024-05-15 7:28 ` Tian, Kevin
2024-05-15 7:31 ` Tian, Kevin
2024-05-19 14:03 ` Baolu Lu
2024-05-20 3:20 ` Tian, Kevin
2024-04-30 14:57 ` [PATCH v5 4/9] iommufd: Add fault and response message definitions Lu Baolu
2024-05-15 7:43 ` Tian, Kevin
2024-05-19 14:37 ` Baolu Lu
2024-05-20 3:24 ` Tian, Kevin
2024-05-20 3:33 ` Baolu Lu
2024-05-20 4:59 ` Tian, Kevin
2024-05-24 14:15 ` Jason Gunthorpe
2024-05-27 1:27 ` Tian, Kevin
2024-04-30 14:57 ` [PATCH v5 5/9] iommufd: Add iommufd fault object Lu Baolu
2024-05-08 0:11 ` Jason Gunthorpe
2024-05-08 10:05 ` Baolu Lu
2024-05-15 7:57 ` Tian, Kevin
2024-05-20 0:41 ` Baolu Lu
2024-05-20 3:26 ` Tian, Kevin
2024-05-20 3:28 ` Baolu Lu
2024-05-08 0:22 ` Jason Gunthorpe
2024-05-10 9:13 ` Baolu Lu
2024-05-15 8:37 ` Tian, Kevin
2024-05-20 1:15 ` Baolu Lu
2024-05-20 1:24 ` Baolu Lu
2024-05-24 14:16 ` Jason Gunthorpe
2024-05-20 1:33 ` Baolu Lu
2024-05-20 3:33 ` Tian, Kevin
2024-05-20 1:38 ` Baolu Lu
2024-04-30 14:57 ` [PATCH v5 6/9] iommufd: Fault-capable hwpt attach/detach/replace Lu Baolu
2024-05-08 0:18 ` Jason Gunthorpe
2024-05-10 3:20 ` Baolu Lu
2024-05-10 13:39 ` Jason Gunthorpe
2024-05-15 8:43 ` Tian, Kevin
2024-05-20 2:10 ` Baolu Lu
2024-05-20 3:35 ` Tian, Kevin
2024-05-20 3:55 ` Baolu Lu
2024-04-30 14:57 ` [PATCH v5 7/9] iommufd: Associate fault object with iommufd_hw_pgtable Lu Baolu
2024-05-08 0:25 ` Jason Gunthorpe
2024-05-10 3:23 ` Baolu Lu
2024-05-15 8:50 ` Tian, Kevin
2024-05-20 2:18 ` Baolu Lu
2024-05-20 3:39 ` Tian, Kevin
2024-05-20 4:00 ` Baolu Lu
2024-05-24 14:24 ` Jason Gunthorpe
2024-05-27 1:33 ` Tian, Kevin
2024-05-27 3:16 ` Baolu Lu
2024-04-30 14:57 ` [PATCH v5 8/9] iommufd/selftest: Add IOPF support for mock device Lu Baolu
2024-04-30 14:57 ` [PATCH v5 9/9] iommufd/selftest: Add coverage for IOPF test 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=0de7c71f-571a-4800-8f2b-9eda0c6b75de@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=j.granados@samsung.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=jean-philippe@linaro.org \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.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).