From: Jason Gunthorpe <jgg@nvidia.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] iommufd: Enforce IOMMU_RESV_SW_MSI upon hwpt_paging allocation
Date: Thu, 1 Aug 2024 11:10:38 -0300 [thread overview]
Message-ID: <20240801141038.GL3371438@nvidia.com> (raw)
In-Reply-To: <Zqqq5JYFswS49z2L@Asurada-Nvidia>
On Wed, Jul 31, 2024 at 02:21:40PM -0700, Nicolin Chen wrote:
> On Wed, Jul 31, 2024 at 11:13:11AM -0700, Nicolin Chen wrote:
> > On Wed, Jul 31, 2024 at 07:45:46AM +0000, Tian, Kevin wrote:
> > > > From: Nicolin Chen <nicolinc@nvidia.com>
> > > > Sent: Monday, July 29, 2024 7:51 AM
> > > > @@ -364,7 +305,8 @@ int iommufd_hw_pagetable_attach(struct
> > > > iommufd_hw_pagetable *hwpt,
> > > > }
> > > >
> > > > if (hwpt_is_paging(hwpt)) {
> > > > - rc = iommufd_hwpt_paging_attach(to_hwpt_paging(hwpt),
> > > > idev);
> > > > + rc = iopt_table_enforce_dev_resv_regions(
> > > > + &to_hwpt_paging(hwpt)->ioas->iopt, idev-
> > > > >dev);
> > >
> > > Is it simpler to extend the original operation to the parent S2 when
> > > it's hwpt_nested?
> >
> > Likely. I recall that was what one of our WIP versions did.
> >
> > > The name iommufd_hwpt_paging_attach() is a bit misleading. The
> > > actual work there is all about reservations. It doesn't change any
> > > tracking structure about attachment between device and hwpt.
> >
> > How about iommufd_hwpt_enforce/remove_rr() taking hwpt v.s.
> > hwpt_paging.
>
> > > With that I think continuing this per-device reservation scheme is
> > > easier than adding specific reservation for SW_MSI at hwpt creation
> > > time and then further requiring check at attach time to verify
> > > the attached device is allocated with the same address as the one
> > > during allocation.
> >
> > Jason, do you agree?
>
> I came up with something plus a bit of naming alignment:
> iommufd_device_attach_reserved_iova()
> iommufd_group_remove_reserved_iova()
> iommufd_group_do_replace_reserved_iova()
>
> If it looks good to both of you, I will send a formal patch.
This seems like a more consistent direction, let's try to make
Jason
prev parent reply other threads:[~2024-08-01 14:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-28 23:51 [PATCH] iommufd: Enforce IOMMU_RESV_SW_MSI upon hwpt_paging allocation Nicolin Chen
2024-07-29 18:24 ` Jason Gunthorpe
2024-07-29 20:05 ` Nicolin Chen
2024-07-31 7:50 ` Tian, Kevin
2024-07-31 18:23 ` Nicolin Chen
2024-08-01 13:28 ` Jason Gunthorpe
2024-08-01 17:39 ` Nicolin Chen
2024-07-31 7:45 ` Tian, Kevin
2024-07-31 18:13 ` Nicolin Chen
2024-07-31 21:21 ` Nicolin Chen
2024-08-01 8:10 ` Tian, Kevin
2024-08-01 17:40 ` Nicolin Chen
2024-08-01 14:10 ` Jason Gunthorpe [this message]
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=20240801141038.GL3371438@nvidia.com \
--to=jgg@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--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 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.