Re: [PATCH v2 4/5] iommu: Add Broadcom BCM2712 IOMMU driver

Robin Murphy <[email protected]> Wed, 29 Jul 2026 12:21:30 +0100
Newsgroups dev.linux.lists.iommu,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 2026-07-29 1:10 am, Jason Gunthorpe wrote:
> On Tue, Jul 28, 2026 at 11:51:04AM +0100, Robin Murphy wrote:
>>> +	ret = pt_iommu_bcm2712_init(&domain->pt, &cfg, GFP_KERNEL);
>>> +	if (ret)
>>> +		goto err;
>>> +
>>> +	/* Set up a default (error) page used to catch illegal reads/writes */
>>> +	domain->default_page = iommu_alloc_pages_sz(GFP_KERNEL, PAGE_SIZE);
>>> +	if (!domain->default_page)
>>> +		goto err;
>>> +
>>> +	domain->base.geometry.aperture_start = BCM2712_APERTURE_BASE;
>>> +	domain->base.geometry.aperture_end = BCM2712_APERTURE_END - 1;
>>> +	domain->base.geometry.force_aperture = true;
>>
>> ...and thus (as things stand) this is a lie :(
> 
> Well, it shouldn't be here, the iommupt core code should be setting
> this from its own internal information. If there is something missing
> to add in the full_va_prefix we should fix it.
> 
> But, AFAIK this is the correct way to declare a page table that has a
> range of IOVA - which I think is what this is doing..

Nope, aperture_start and aperture_end already indicate the range of what 
can be used as translatable IOVAs; force_aperture is supposed to 
indicate whether addresses _outside_ that range are blocked, or may 
still be able to access memory as with a GART-style device.

Heck, a "proper" IOMMU doesn't even have an "aperture", it simply has an 
entire input address space.

>> If you want to operate like an IOMMU, then the translation aperture and the
>> bypass window should really be mutually-exclusive;
> 
> I think it is operating like an iommu..
> 
> It uses generic_single_device_group() so there is only ever one
> translation.

Also like a GART.

> If identity is attached then it clears MMMU_CTRL_OPERATING_FLAGS which
> I guess fully disables the IOVA aperture

Not unlike a GART.

> If paging is attached then it sets MMMU_CTRL_OPERATING_FLAGS and
> places the aperture at 40G. Based on the comments about blocking I
> wonder if the "bypass" even works when paging is on?

Rather like a GART.

> If blocking is attached then it sets MMMU_CTRL_OPERATING_FLAGS with
> some 0 address cap which aborts everything?

Disabling the aperture is also GART-like, but also disabling the bypass 
window would seem the be the exclusively IOMMU-like behaviour there ;)

> It looks to me like some of those comments and choices don't reflect
> what the driver actually does. Since there is only ever one
> translation we never need to be worried about where the aperture is,
> it could be anything so long as the HW gives it priority to bypass.

I'm looking at the BYPASS_START/BYPASS_END stuff, where (assuming that's 
intuitive and not completely misnamed) bcm2712_iommu_attach_dev() sure 
seems to be opening up a giant hole in all paging domains per the commit 
message, thus while they can offer the convenience of IOVA remapping, 
they aren't providing any real memory protection.

Thanks,
Robin.

> Could the aperture be placed at 0 with the bypass fully disabled? Then
> it would basically be a normal iommu.
> 
> Jason