Re: [RFC PATCH] powerpc: iommu: Initial IOMMUFD support for PPC64

[Shivaprasad G Bhat]

On 2/3/26 11:37 PM, Jason Gunthorpe wrote:
> 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 :)


Sure. Thanks!


> > 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.


I agree, the additional PPC specific ioctls can be selectively handled based

on arch.


> > 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.


I see there is some more history around this being discussed before on 
the patch here,

https://lore.kernel.org/all/20220701061751.1955857-1-aik@xxxxxxxxx/

Will try to dig more and address this in future.

Thanks,

Shivaprasad

> Jason