linux-kernel - Re: [PATCH RFCv2 09/13] iommufd: Add IOMMU_OPTION_SW_MSI

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: <20250207152801.GV2960738@nvidia.com>
Date: Fri, 7 Feb 2025 11:28:01 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: Eric Auger <eric.auger@...hat.com>, will@...nel.org,
	robin.murphy@....com, kevin.tian@...el.com, tglx@...utronix.de,
	maz@...nel.org, alex.williamson@...hat.com, joro@...tes.org,
	shuah@...nel.org, reinette.chatre@...el.com, yebin10@...wei.com,
	apatel@...tanamicro.com, shivamurthy.shastri@...utronix.de,
	bhelgaas@...gle.com, anna-maria@...utronix.de, yury.norov@...il.com,
	nipun.gupta@....com, iommu@...ts.linux.dev,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	kvm@...r.kernel.org, linux-kselftest@...r.kernel.org,
	patches@...ts.linux.dev, jean-philippe@...aro.org, mdf@...nel.org,
	mshavit@...gle.com, shameerali.kolothum.thodi@...wei.com,
	smostafa@...gle.com, ddutile@...hat.com
Subject: Re: [PATCH RFCv2 09/13] iommufd: Add IOMMU_OPTION_SW_MSI_START/SIZE
 ioctls

On Fri, Feb 07, 2025 at 10:30:20AM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 06, 2025 at 08:26:05PM -0800, Nicolin Chen wrote:
> > Yea, I found iopt_reserve_iova() is actually missed entirely...
> > 
> > While fixing this, I see a way to turn the OPTIONs back to per-
> > idev, if you still prefer them to be per-idev(?). Then, we can
> > check a given input in the set_option() against the device's
> > reserved region list from the driver, prior to device attaching
> > to any HWPT.
> 
> I didn't have a strong opinion, if the idev works without complexity
> then I'd stick with that on the basis of narrower scope is usually
> better.

If you make it per-idev then it is also implicitly per-GIC as well
since each idev has exactly one GIC

This would make it useful as a way to get each ITS page mapped into a
single fixed location.. 

Really hard to use from the VMM though

Jason