From: Jason Gunthorpe <jgg@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Christian Benvenuti <benve@cisco.com>,
Heiko Stuebner <heiko@sntech.de>,
iommu@lists.linux.dev, Jernej Skrabec <jernej.skrabec@gmail.com>,
Joerg Roedel <joro@8bytes.org>, Leon Romanovsky <leon@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org,
linux-mediatek@lists.infradead.org, linux-rdma@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-sunxi@lists.linux.dev,
Matthias Brugger <matthias.bgg@gmail.com>,
Nelson Escobar <neescoba@cisco.com>,
Rob Clark <robin.clark@oss.qualcomm.com>,
Samuel Holland <samuel@sholland.org>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Chen-Yu Tsai <wens@csie.org>, Will Deacon <will@kernel.org>,
Yong Wu <yong.wu@mediatek.com>,
patches@lists.linux.dev
Subject: Re: [PATCH 3/3] iommu: Allow drivers to say if they use report_iommu_fault()
Date: Thu, 23 Oct 2025 13:58:54 -0300 [thread overview]
Message-ID: <20251023165854.GA742380@nvidia.com> (raw)
In-Reply-To: <20251023145434.GJ262900@nvidia.com>
On Thu, Oct 23, 2025 at 11:54:34AM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 23, 2025 at 12:24:01PM +0100, Robin Murphy wrote:
> > On 2025-10-22 6:12 pm, Jason Gunthorpe wrote:
> > > report_iommu_fault() is an older API that has been superseded by
> > > iommu_report_device_fault() which is capable to support PRI.
> > >
> > > Only two external drivers consume this, drivers/remoteproc and
> > > drivers/gpu/drm/msm. Ideally they would move over to the new APIs, but for
> > > now protect against accidentally mix and matching the wrong components.
> > >
> > > The iommu drivers support either the old iommu_set_fault_handler() via the
> > > driver calling report_iommu_fault(), or they are newer server focused
> > > drivers that call iommu_report_device_fault().
> > >
> > > Include a flag in the domain_ops if it calls report_iommu_fault() and
> > > block iommu_set_fault_handler() on iommu's that can't support it.
> >
> > This isn't a domain operation though; depending on how you look at it,
> > supporting a legacy fault_handler is either a capability of the IOMMU driver
> > (that would be reachable via domain->owner->capable) or a property of the
> > iommu_domain itself that the drivers can set at allocation time (basically
> > this same patch just with the lines in slightly different places).
>
> That's right, the issue is:
>
> void iommu_set_fault_handler(struct iommu_domain *domain,
> iommu_fault_handler_t handler,
> void *token)
>
> We can't get to the iommu instance starting from a domain pointer
>
> Do you think we should change the above signature to include a
> struct device *?
Reading this again, it is easy to move it to the domain->owner, which
is an *ops* pointer. It would still be driver global and not
per-instance. Lets try that then
I like adding a iommu_paging_domain_alloc_flags() option too..
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Christian Benvenuti <benve@cisco.com>,
Heiko Stuebner <heiko@sntech.de>,
iommu@lists.linux.dev, Jernej Skrabec <jernej.skrabec@gmail.com>,
Joerg Roedel <joro@8bytes.org>, Leon Romanovsky <leon@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org,
linux-mediatek@lists.infradead.org, linux-rdma@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-sunxi@lists.linux.dev,
Matthias Brugger <matthias.bgg@gmail.com>,
Nelson Escobar <neescoba@cisco.com>,
Rob Clark <robin.clark@oss.qualcomm.com>,
Samuel Holland <samuel@sholland.org>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Chen-Yu Tsai <wens@csie.org>, Will Deacon <will@kernel.org>,
Yong Wu <yong.wu@mediatek.com>,
patches@lists.linux.dev
Subject: Re: [PATCH 3/3] iommu: Allow drivers to say if they use report_iommu_fault()
Date: Thu, 23 Oct 2025 13:58:54 -0300 [thread overview]
Message-ID: <20251023165854.GA742380@nvidia.com> (raw)
In-Reply-To: <20251023145434.GJ262900@nvidia.com>
On Thu, Oct 23, 2025 at 11:54:34AM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 23, 2025 at 12:24:01PM +0100, Robin Murphy wrote:
> > On 2025-10-22 6:12 pm, Jason Gunthorpe wrote:
> > > report_iommu_fault() is an older API that has been superseded by
> > > iommu_report_device_fault() which is capable to support PRI.
> > >
> > > Only two external drivers consume this, drivers/remoteproc and
> > > drivers/gpu/drm/msm. Ideally they would move over to the new APIs, but for
> > > now protect against accidentally mix and matching the wrong components.
> > >
> > > The iommu drivers support either the old iommu_set_fault_handler() via the
> > > driver calling report_iommu_fault(), or they are newer server focused
> > > drivers that call iommu_report_device_fault().
> > >
> > > Include a flag in the domain_ops if it calls report_iommu_fault() and
> > > block iommu_set_fault_handler() on iommu's that can't support it.
> >
> > This isn't a domain operation though; depending on how you look at it,
> > supporting a legacy fault_handler is either a capability of the IOMMU driver
> > (that would be reachable via domain->owner->capable) or a property of the
> > iommu_domain itself that the drivers can set at allocation time (basically
> > this same patch just with the lines in slightly different places).
>
> That's right, the issue is:
>
> void iommu_set_fault_handler(struct iommu_domain *domain,
> iommu_fault_handler_t handler,
> void *token)
>
> We can't get to the iommu instance starting from a domain pointer
>
> Do you think we should change the above signature to include a
> struct device *?
Reading this again, it is easy to move it to the domain->owner, which
is an *ops* pointer. It would still be driver global and not
per-instance. Lets try that then
I like adding a iommu_paging_domain_alloc_flags() option too..
Jason
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-10-23 16:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-22 17:12 [PATCH 0/3] Cleanup around iommu_set_fault_handler() Jason Gunthorpe
2025-10-22 17:12 ` Jason Gunthorpe
2025-10-22 17:12 ` [PATCH 1/3] RDMA/usnic: Remove iommu_set_fault_handler() Jason Gunthorpe
2025-10-22 17:12 ` Jason Gunthorpe
2025-10-23 5:02 ` Baolu Lu
2025-10-23 5:02 ` Baolu Lu
2025-10-22 17:12 ` [PATCH 2/3] iommu/amd: Don't call report_iommu_fault() Jason Gunthorpe
2025-10-22 17:12 ` Jason Gunthorpe
2025-10-23 12:34 ` Robin Murphy
2025-10-23 12:34 ` Robin Murphy
2025-10-23 14:26 ` Jason Gunthorpe
2025-10-23 14:26 ` Jason Gunthorpe
2025-11-20 19:26 ` Jason Gunthorpe
2025-11-20 19:26 ` Jason Gunthorpe
2025-10-22 17:12 ` [PATCH 3/3] iommu: Allow drivers to say if they use report_iommu_fault() Jason Gunthorpe
2025-10-22 17:12 ` Jason Gunthorpe
2025-10-23 5:06 ` Baolu Lu
2025-10-23 5:06 ` Baolu Lu
2025-10-23 11:24 ` Robin Murphy
2025-10-23 11:24 ` Robin Murphy
2025-10-23 14:54 ` Jason Gunthorpe
2025-10-23 14:54 ` Jason Gunthorpe
2025-10-23 16:58 ` Jason Gunthorpe [this message]
2025-10-23 16:58 ` Jason Gunthorpe
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=20251023165854.GA742380@nvidia.com \
--to=jgg@nvidia.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=benve@cisco.com \
--cc=heiko@sntech.de \
--cc=iommu@lists.linux.dev \
--cc=jernej.skrabec@gmail.com \
--cc=joro@8bytes.org \
--cc=leon@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=matthias.bgg@gmail.com \
--cc=neescoba@cisco.com \
--cc=patches@lists.linux.dev \
--cc=robin.clark@oss.qualcomm.com \
--cc=robin.murphy@arm.com \
--cc=samuel@sholland.org \
--cc=suravee.suthikulpanit@amd.com \
--cc=wens@csie.org \
--cc=will@kernel.org \
--cc=yong.wu@mediatek.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.