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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260203180725.GD3931454@nvidia.com>
Date: Tue, 3 Feb 2026 14:07:25 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Shivaprasad G Bhat <sbhat@...ux.ibm.com>
Cc: linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
	kvm@...r.kernel.org, iommu@...ts.linux.dev, chleroy@...nel.org,
	mpe@...erman.id.au, maddy@...ux.ibm.com, npiggin@...il.com,
	alex@...zbot.org, joerg.roedel@....com, kevin.tian@...el.com,
	gbatra@...ux.ibm.com, clg@...d.org, vaibhav@...ux.ibm.com,
	brking@...ux.vnet.ibm.com, nnmlinux@...ux.ibm.com,
	amachhiw@...ux.ibm.com, tpearson@...torengineering.com
Subject: Re: [RFC PATCH] powerpc: iommu: Initial IOMMUFD support for PPC64

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