linux-kernel - Re: [PATCH 1/2] powerpc: iommu: Bring back table group release

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: <1453449220.10126352.1706283596477.JavaMail.zimbra@raptorengineeringinc.com>
Date: Fri, 26 Jan 2024 09:39:56 -0600 (CST)
From: Timothy Pearson <tpearson@...torengineering.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Timothy Pearson <tpearson@...torengineering.com>, 
	Shivaprasad G Bhat <sbhat@...ux.ibm.com>, 
	iommu <iommu@...ts.linux.dev>, 
	linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>, 
	linux-kernel <linux-kernel@...r.kernel.org>, 
	Michael Ellerman <mpe@...erman.id.au>, npiggin <npiggin@...il.com>, 
	christophe leroy <christophe.leroy@...roup.eu>, 
	aneesh kumar <aneesh.kumar@...nel.org>, 
	naveen n rao <naveen.n.rao@...ux.ibm.com>, jroedel <jroedel@...e.de>, 
	aik <aik@....com>, bgray <bgray@...ux.ibm.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	gbatra <gbatra@...ux.vnet.ibm.com>, vaibhav <vaibhav@...ux.ibm.com>
Subject: Re: [PATCH 1/2] powerpc: iommu: Bring back table group
 release_ownership() call



----- Original Message -----
> From: "Jason Gunthorpe" <jgg@...pe.ca>
> To: "Timothy Pearson" <tpearson@...torengineering.com>
> Cc: "Shivaprasad G Bhat" <sbhat@...ux.ibm.com>, "iommu" <iommu@...ts.linux.dev>, "linuxppc-dev"
> <linuxppc-dev@...ts.ozlabs.org>, "linux-kernel" <linux-kernel@...r.kernel.org>, "Michael Ellerman"
> <mpe@...erman.id.au>, "npiggin" <npiggin@...il.com>, "christophe leroy" <christophe.leroy@...roup.eu>, "aneesh kumar"
> <aneesh.kumar@...nel.org>, "naveen n rao" <naveen.n.rao@...ux.ibm.com>, "jroedel" <jroedel@...e.de>, "aik"
> <aik@....com>, "bgray" <bgray@...ux.ibm.com>, "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, "gbatra"
> <gbatra@...ux.vnet.ibm.com>, "vaibhav" <vaibhav@...ux.ibm.com>
> Sent: Friday, January 26, 2024 9:38:06 AM
> Subject: Re: [PATCH 1/2] powerpc: iommu: Bring back table group release_ownership() call

> On Fri, Jan 26, 2024 at 09:29:55AM -0600, Timothy Pearson wrote:
>> > On Fri, Jan 26, 2024 at 08:43:12PM +0530, Shivaprasad G Bhat wrote:
>> >> > Also, is there any chance someone can work on actually fixing this to
>> >> > be a proper iommu driver? I think that will become important for power
>> >> > to use the common dma_iommu code in the next year...
>> >> We are looking into it.
>> > 
>> > Okay, let me know, I can possibly help make parts of this happen
>> > 
>> > power is the last still-current architecture to be outside the modern
>> > IOMMU and DMA API design and I'm going to start proposing things that
>> > will not be efficient on power because of this.
>> 
>> I can get development resources on this fairly rapidly, including
>> testing.  We should figure out the best way forward and how to deal
>> with the VFIO side of things, even if that's a rewrite at the end of
>> the day the machine-specific codebase isn't *that* large for our two
>> target flavors (64-bit PowerNV and 64-bit pSeries).
> 
> I have a feeling the way forward is to just start a power driver under
> drivers/iommu/ and use kconfig to make the user exclusively select
> either the legacy arch or the modern iommu.
> 
> Get that working to a level where dma_iommu is happy.
> 
> Get iommufd support in the new driver good enough to run your
> application.
> 
> Just forget about the weird KVM and SPAPR stuff, leave it under the
> kconfig of the old code and nobody will run it. Almost nobody already
> runs it, apparently.

We actually use QEMU/KVM/VFIO extensively at Raptor, so need the support and need it to be performant...

> Remove it in a few years
> 
> From what I remember the code under the arch directory is already very
> nearly almost an iommu driver. I think someone could fairly quickly
> get to something working and using dma_iommu.c. If s390 is any
> experience there is some benchmarking and tweaking to get performance
> equal to the arch's tweaked dma_iommu copy.
> 
> Jason