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 v3 2/8] iommu/sva: Use iopf domain attach/detach interface
Date: Thu, 14 Mar 2024 15:41:23 +0800 [thread overview]
Message-ID: <b33bf29b-2fe5-4a2a-a2ce-9fd8d67c5f6f@linux.intel.com> (raw)
In-Reply-To: <20240308174605.GV9225@ziepe.ca>
On 2024/3/9 1:46, Jason Gunthorpe wrote:
> On Mon, Jan 22, 2024 at 03:38:57PM +0800, Lu Baolu wrote:
>> @@ -215,7 +202,23 @@ static struct iopf_group *iopf_group_alloc(struct iommu_fault_param *iopf_param,
>> group = abort_group;
>> }
>>
>> + cookie = iopf_pasid_cookie_get(iopf_param->dev, pasid);
>> + if (!cookie && pasid != IOMMU_NO_PASID)
>> + cookie = iopf_pasid_cookie_get(iopf_param->dev, IOMMU_NO_PASID);
>> + if (IS_ERR(cookie) || !cookie) {
>> + /*
>> + * The PASID of this device was not attached by an I/O-capable
>> + * domain. Ask the caller to abort handling of this fault.
>> + * Otherwise, the reference count will be switched to the new
>> + * iopf group and will be released in iopf_free_group().
>> + */
>> + kfree(group);
>> + group = abort_group;
>> + cookie = NULL;
>> + }
>
> If this is the main point of the cookie mechansim - why not just have
> a refcount inside the domain itself?
>
> I'm really having a hard time making sense of this cookie thing, we
> have a lifetime issue on the domain pointer, why is adding another
> structure the answer?
The whole cookie mechanism aims to address two things:
- Extend the domain lifetime until all pending page faults are resolved.
- Associate information about the iommu device with each attachment of
the domain so that the iommufd device object ID could be quickly
retrieved in the fault delivering path.
> I see we also need to stick a pointer in the domain for iommufd to get
> back to the hwpt, but that doesn't seem to need such a big system to
> accomplish - just add a void *. It would make sense for the domain to
> have some optional pointer to a struct for all the fault related data
> that becomes allocated when a PRI domain is created..
It's not getting back hwpt from domain, just getting the iommufd_device
in the fault delivering path. The iommufd_device is not per-domain, but
per-domain-attachment.
>
> Also, I thought we'd basically said that domain detatch is supposed to
> flush any open PRIs before returning, what happened to that as a
> solution to the lifetime problem?
If I remember it correctly, what we discussed was to flush all pending
page faults when disabling PRI. Anyway, the current driver behavior is
to flush faults during domain detachment. And if we keep this behavior,
we no longer need to worry about domain lifetime anymore.
>
> Regardless I think we should split this into two series - improve the PRI
> lifetime model for domains and then put iommufd on top of it..
Yes, agreed. Let's tackle those two points in a separate series.
Best regards,
baolu
next prev parent reply other threads:[~2024-03-14 7:41 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 7:38 [PATCH v3 0/8] IOMMUFD: Deliver IO page faults to user space Lu Baolu
2024-01-22 7:38 ` [PATCH v3 1/8] iommu: Add iopf domain attach/detach/replace interface Lu Baolu
2024-02-07 8:11 ` Tian, Kevin
2024-02-21 5:52 ` Baolu Lu
2024-02-21 6:49 ` Tian, Kevin
2024-02-21 7:21 ` Baolu Lu
2024-02-21 7:22 ` Tian, Kevin
2024-01-22 7:38 ` [PATCH v3 2/8] iommu/sva: Use iopf domain attach/detach interface Lu Baolu
2024-03-08 17:46 ` Jason Gunthorpe
2024-03-14 7:41 ` Baolu Lu [this message]
2024-03-22 16:59 ` Jason Gunthorpe
2024-03-25 3:52 ` Baolu Lu
2024-01-22 7:38 ` [PATCH v3 3/8] iommufd: Add fault and response message definitions Lu Baolu
2024-03-08 17:50 ` Jason Gunthorpe
2024-03-14 13:41 ` Baolu Lu
2024-03-22 17:04 ` Jason Gunthorpe
2024-03-25 3:57 ` Baolu Lu
2024-01-22 7:38 ` [PATCH v3 4/8] iommufd: Add iommufd fault object Lu Baolu
2024-03-08 18:03 ` Jason Gunthorpe
2024-03-15 1:46 ` Baolu Lu
2024-03-22 17:09 ` Jason Gunthorpe
2024-03-25 5:01 ` Baolu Lu
2024-03-20 16:18 ` Shameerali Kolothum Thodi
2024-03-22 17:22 ` Jason Gunthorpe
2024-03-25 3:26 ` Baolu Lu
2024-03-25 4:02 ` Baolu Lu
2024-01-22 7:39 ` [PATCH v3 5/8] iommufd: Associate fault object with iommufd_hw_pgtable Lu Baolu
2024-02-07 8:14 ` Tian, Kevin
2024-02-21 6:06 ` Baolu Lu
2024-03-02 2:36 ` Zhangfei Gao
2024-03-06 15:15 ` Zhangfei Gao
2024-03-06 16:01 ` Jason Gunthorpe
2024-03-07 1:54 ` Baolu Lu
2024-03-08 17:19 ` Jason Gunthorpe
2024-03-08 19:05 ` Jason Gunthorpe
2024-03-15 1:16 ` Baolu Lu
2024-03-22 17:06 ` Jason Gunthorpe
2024-03-25 4:59 ` Baolu Lu
2024-01-22 7:39 ` [PATCH v3 6/8] iommufd: IOPF-capable hw page table attach/detach/replace Lu Baolu
2024-02-20 13:57 ` Joel Granados
2024-02-21 6:15 ` Baolu Lu
2024-01-22 7:39 ` [PATCH v3 7/8] iommufd/selftest: Add IOPF support for mock device Lu Baolu
2024-01-22 7:39 ` [PATCH v3 8/8] 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=b33bf29b-2fe5-4a2a-a2ce-9fd8d67c5f6f@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