From: Jason Gunthorpe <jgg@nvidia.com>
To: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, iommu@lists.linux.dev, chleroy@kernel.org,
mpe@ellerman.id.au, maddy@linux.ibm.com, npiggin@gmail.com,
alex@shazbot.org, joerg.roedel@amd.com, kevin.tian@intel.com,
gbatra@linux.ibm.com, clg@kaod.org, vaibhav@linux.ibm.com,
brking@linux.vnet.ibm.com, nnmlinux@linux.ibm.com,
amachhiw@linux.ibm.com, tpearson@raptorengineering.com
Subject: Re: [RFC PATCH] powerpc: iommu: Initial IOMMUFD support for PPC64
Date: Tue, 3 Feb 2026 14:07:25 -0400 [thread overview]
Message-ID: <20260203180725.GD3931454@nvidia.com> (raw)
In-Reply-To: <2127b181-2c3a-4470-9b79-b508a18275c9@linux.ibm.com>
On Tue, Feb 03, 2026 at 09:22:13PM +0530, Shivaprasad G Bhat wrote:
> > Then you'd want to introduce a new domain op to get the apertures
> > instead of the single range hard coded into the domain struct. The new
> > op would be able to return a list. We can use this op to return
> > apertures for sign extension page tables too.
> >
> > Update iommufd to calculate the reserved regions by evaluating the
> > whole list.
> >
> > I think you'll find this pretty straight forward, I'd do it as a
> > followup patch to this one.
>
>
> Thanks. I will wait for that patch.
I think you will have to make it :)
> There are ioctl number conflicts like
>
> # grep -n "VFIO_BASE + 1[89]" include/uapi/linux/vfio.h | grep define
> 940:#defineVFIO_DEVICE_BIND_IOMMUFD_IO(VFIO_TYPE, VFIO_BASE + 18)
> 976:#defineVFIO_DEVICE_ATTACH_IOMMUFD_PT_IO(VFIO_TYPE, VFIO_BASE + 19)
> 1833:#defineVFIO_IOMMU_SPAPR_UNREGISTER_MEMORY_IO(VFIO_TYPE, VFIO_BASE + 18)
> 1856:#defineVFIO_IOMMU_SPAPR_TCE_CREATE_IO(VFIO_TYPE, VFIO_BASE + 19)
> # grep -n "VFIO_BASE + 20" include/uapi/linux/vfio.h | grep define
> 999:#defineVFIO_DEVICE_DETACH_IOMMUFD_PT_IO(VFIO_TYPE, VFIO_BASE + 20)
> 1870:#defineVFIO_IOMMU_SPAPR_TCE_REMOVE_IO(VFIO_TYPE, VFIO_BASE + 20)
It's Ok the compat codes will know what type it is operating in before
it decodes any of those.
> You are right. We do have some use cases beyond VMM, I will consider compat
> driver only if it is helpful there.
You can also use the type1 compat mode which will magically start
working with PPC..
> > You should also implement the BLOCKING domain type to make VFIO work
> > better
> I am not sure how this could help making VFIO better. May be, I am not able
> to imagine the advantages with the current platform domain approach
> in place. Could you please elaborate more on this?
VFIO always uses a BLOCKED domain when it opens the device, then it
changes to a paging domain. If the driver doesn't support a native
BLOCKED domain then it allocates an empty page table and uses that.
A proper native BLOCKED domain has better error handling
characteristics since it is not allowed to fail attach and it doesn't
require allocation.
I think you will also find what you are doing easier if you push the
iommu_domain down through the PPC iommu ops instead of retaining these
unnecessary historical layers.
Jason
next prev parent reply other threads:[~2026-02-03 18:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-27 18:35 [RFC PATCH] powerpc: iommu: Initial IOMMUFD support for PPC64 Shivaprasad G Bhat
2026-01-27 19:16 ` Jason Gunthorpe
2026-02-03 15:52 ` Shivaprasad G Bhat
2026-02-03 18:07 ` Jason Gunthorpe [this message]
2026-02-04 15:23 ` Shivaprasad G Bhat
2026-01-28 10:53 ` Christophe Leroy (CS GROUP)
2026-02-03 15:54 ` Shivaprasad G Bhat
2026-02-01 22:44 ` kernel test robot
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=20260203180725.GD3931454@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex@shazbot.org \
--cc=amachhiw@linux.ibm.com \
--cc=brking@linux.vnet.ibm.com \
--cc=chleroy@kernel.org \
--cc=clg@kaod.org \
--cc=gbatra@linux.ibm.com \
--cc=iommu@lists.linux.dev \
--cc=joerg.roedel@amd.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=nnmlinux@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=sbhat@linux.ibm.com \
--cc=tpearson@raptorengineering.com \
--cc=vaibhav@linux.ibm.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.