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