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

[Daniel Drake <dan@reactivated.net>]

On 31/07/2026 21:22, Daniel Drake wrote:
> The aperture could be placed anywhere, but the key idea in the current 
> driver structure is that we deliberately place it above physical memory, 
> so that we can have the bypass window operational for all regular 
> physical addresses, meaning that iommu-unaware devices can operate as 
> normal.
> 
> Each of the 3-4 IOMMUs has around 5 devices hardwired into it. When the 
> IOMMU is switched on (effectively via setting CTRL_OPERATING_FLAGS), 
> *all* of the hardwired devices are subject to the IOMMU operation, 
> uniformly. There is no gating where you can have one of the devices in 
> standard passthrough mode and the rest using the IOMMU. Also there is no 
> Stream ID in the transactions, there is no way to configure per-device 
> page tables.
> 
> Among the devices hardwired to the IOMMUs we might have:
>   - Devices already set up by the firmware and relying on regular access
>     to physical memory
>   - Devices that don't require large contiguous DMA allocations and would
>     prefer not to have the translation overhead of the iommu
>   - Devices that handle scatter-gather natively and prefer not to have
>     the translation overhead of the iommu
>   - & devices that want to use the IOMMU :) so that they can work with
>     large contiguous allocations which are actually scattered in
>     underlying physical memory
> 
> So we have multiple needs to tend to, which is why the driver currently 
> sets up the bypass in the regular address space (serving the first 3 
> above), and the IOMMU aperture in a high, unused part of the address 
> space (for the devices that do want to take advantage of the IOMMU).
> 
> Are those good enough reasons to set up the driver in this way? Or are 
> there other approaches to consider?

Reading the thread again I'm sensing that it would be preferred to go 
with a more conventional IOMMU setup, rather than trying to cover all of 
the above in a single configuration.

For the next revision I am thinking:
  1. Paging domain has the aperture at address 0, without bypass/identity
     region i.e. some degree of memory protection is present
  2. Identity domain is complete iommu bypass (as-is)

This allows the system admin to choose between the iommu benefits (and 
associated minor overhead) OR the non-iommu bypass mode. That choice 
would apply to all of the devices hardwired to the iommu in question -- 
we wouldn't attempt to support mixing identity and paging approaches at 
the same time as was originally proposed.

Regarding devices set up by the firmware that require ongoing access to 
RAM, of which the display controller is probably the only case, we can 
use the existing mechanism that allows the firmware to communicate such 
requirements.

The iommu driver will do:
	.get_resv_regions = iommu_dma_get_resv_regions,

Then on the DT side, I would ask Raspberry Pi to provide a firmware 
adjustment in future versions. It already dynamically programs the 
framebuffer as a memreserve property, a hole in the memory map and as a 
simple-framebuffer node. We would need this additionally programmed as 
reserved-memory:

  reserved-memory {
	fw_fb: framebuffer@3f800000 {
		reg = <0x0 0x3f800000 0x0 0x800000>;
		iommu-addresses = <&vc4 0x0 0x3f800000 0x0 0x800000>;
	};
  }

and also a link back from vc4:

	vc4: gpu {
		memory-region = <&fw_fb>;
	};

This will cause the iommu driver to set up the initial page tables with 
the above memory region as an identity mapping. This is done before 
paging mode is activated, so once the iommu is actually switched on, the 
display controller will enjoy uninterrupted access to that framebuffer.

Let me know if anything sounds off!

Daniel