Re: [PATCH] iommu/io-pgtable-arm: Add misisng concatenated PGD cases

From: Robin Murphy
Date: Thu Dec 11 2025 - 06:05:16 EST


On 2025-12-11 2:09 am, Will Deacon wrote:
On Wed, Dec 10, 2025 at 12:06:10PM +0000, Robin Murphy wrote:
On 2025-12-10 12:42 am, Will Deacon wrote:
On Tue, Dec 09, 2025 at 01:33:36PM +0000, Robin Murphy wrote:
On 2025-12-09 12:37 pm, Mostafa Saleh wrote:
On Tue, Dec 09, 2025 at 11:34:34AM +0000, Robin Murphy wrote:
On 2025-11-30 7:45 pm, Mostafa Saleh wrote:
arm_lpae_concat_mandatory() assumes that OAS >= IAS which is not
correct for SMMUs supporting AArch32, and have OAS = 32/36 bits,
as IAS would be 40 bits.

But that is only when *using* AArch32 format. The bit in chapter 3.4 of the
SMMU architecture is talking about the maximum IAS that an SMMU
implementation needs to be able to accommodate based on its configuration,
but it does then attempt to clarify that the actual IPA size in use by any
given context should depend on the VMSA format in use:

"VMSAv8-32 LPAE always supports an IPA size of 40 bits, whereas VMSAv8-64
and VMSAv9-128 limits the maximum IPA size to the maximum PA size."

Rule R_SRKBC in the Arm ARM lays out the exact T0SZ constraints with this
AArch32/AArch64 detail.

I see, thanks a lot for the explanation, I got confused by the this
statement:
Note: If AArch32 is implemented, IAS == MAX(40, OAS), otherwise IAS == OAS.

Indeed, that appears confusingly contradictory; I've filed a bug.

I think the spec has always been worded like this. My reading is that, in
isolation:

- VMSAv8-32 LPAE always uses a 40-bit IAS
- VMSAv8-64 has IAS == OAS and this can be smaller than 40 bits

so if AArch32 is implemented, we know that the hardware supports at
least a 40-bit IAS and in that case the VMSAv8-64 IAS can be bigger
than the OAS.

No, the VMSAv8-64 IAS can never be bigger than OAS, as that would violate
VMSA (see rules R_DTLMN and R_SRKBC). The SMMU spec seems mostly fixated on
the notional maximum IAS that an SMMU must accommodate in general across all
supported formats; the limitations of using any particular format must still
apply though (similarly, the fact that AArch32 has a fixed 40-bit output
doesn't mean that OAS and S2PS don't still matter for AArch64 format.)

A VMSAv8-32 stage-1 could still input a 40-bit IAS into a VMSAv8-64
stage-2 when the OAS < 40-bit though, right? If that's the only case
where this happens, then I agree we should ditch the complexity from the
driver on the grounds that we don't ever use the 32-bit formats.

Yes, it is perfectly possible with either format to configure the S1 *output* size (CD.IPS, or 40 when CD.AA64==0) to be larger than the S2 input size (STE.S2T0SZ), and if S1 tries to use an IPA beyond the actual S2 range then it gets a S2 translation fault, per VMSA rule R_BZHGM.

Cheers,
Robin.