Re: [PATCH 7/7] iommu: Restore SMMU "disable_bypass"

From: Jason Gunthorpe <jgg@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
	linux-arm-kernel@lists.infradead.org,
	Will Deacon <will@kernel.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Heiko Stuebner <heiko@sntech.de>, Joerg Roedel <jroedel@suse.de>,
	Jerry Snitselaar <jsnitsel@redhat.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	Niklas Schnelle <schnelle@linux.ibm.com>,
	Steven Price <steven.price@arm.com>
Subject: Re: [PATCH 7/7] iommu: Restore SMMU "disable_bypass"
Date: Fri, 6 Oct 2023 09:41:10 -0300	[thread overview]
Message-ID: <20231006124110.GP682044@nvidia.com> (raw)
In-Reply-To: <b496eab7-c0fe-4dcb-adf9-f5460e4a8a28@arm.com>

On Fri, Oct 06, 2023 at 01:06:08PM +0100, Robin Murphy wrote:
> On 2023-10-05 19:28, Jason Gunthorpe wrote:
> > The module parameter "disable_bypass" changes the IOMMU configuration when
> > using CONFIG_ARM_DMA_USE_IOMMU to establish a faulting/blocked domain when
> > the ARM DMA ops are not being used.
> 
> Nothing to do with ARM DMA ops, it is purely about the behaviour for
> StreamIDs not attached to domains. This includes known StreamIDs during the
> window between SMMU initialisation and those devices first being probed and
> attached to something, but these days is mostly concerned with unknown
> StreamIDs that would never be attached either way.

So, I'm happy with this explanation and we can drop this patch. Let's
still update the driver to the new API anyhow

But it does not completely match the impression I got when I went
digging in the git history. The commit messages seemed to convay a
concern that SIDs which have DT nodes and struct devices but did not
have attached drivers trigger DMA errors to flush out bad stuff.

> Also we're now tantalisingly close to having ARM use regular default domains
> anyway - the full conversion to iommu-dma still depends on significant
> changes to the IOVA allocator, but I'm 99% sure I've got a viable
> intermediate step which at least gets it out of the way from the rest of the
> core API's PoV (probe/release shenanigans etc.).

What I wanted to get to was an arrangement where arm iommu doesn't
leak out everywhere. Get it out of the GPU drivers and related, get it
out of the iommu drivers.

That seems like a necessary step before even considering replacing it
entirely.

I was going to take a break and see what your of_xlate changes look
like first :)

> that frankly the number of users of arm-smmu with 32-bit mainline kernels
> is, to within experimental error, 0, so honestly it's not worth complicating
> core code with this.

Okay! We won't worry about it for smmuv3 either then

Thanks,
Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel