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

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..

> 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.

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

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?

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

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.

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

Jason