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] [day] [month] [year] [list]

Message-ID: <918060d2-3ccc-4c7b-a7f1-65c110e124aa@linux.ibm.com>
Date: Wed, 4 Feb 2026 20:53:48 +0530
From: Shivaprasad G Bhat <sbhat@...ux.ibm.com>
To: Jason Gunthorpe <jgg@...dia.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 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@ozlabs.ru/

Will try to dig more and address this in future.

Thanks,

Shivaprasad

> Jason