On 2023-08-22 17:42, Nicolin Chen wrote:
> On Tue, Aug 22, 2023 at 10:19:21AM +0100, Robin Murphy wrote:
>
>>> out_free_data:
>>> @@ -1071,6 +1073,7 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
>>> ARM_MALI_LPAE_TTBR_ADRMODE_TABLE;
>>> if (cfg->coherent_walk)
>>> cfg->arm_mali_lpae_cfg.transtab |= ARM_MALI_LPAE_TTBR_SHARE_OUTER;
>>> + cfg->nents_per_pgtable = 1 << data->bits_per_level;
>>
>> The result of this highly complex and expensive calculation is clearly
>> redundant with the existing bits_per_level field, so why do we need to
>> waste space storing when the driver could simply use bits_per_level?
>
> bits_per_level is in the private struct arm_lpae_io_pgtable, while
> drivers can only access struct io_pgtable_cfg. Are you suggesting
> to move bits_per_level out of the private struct arm_lpae_io_pgtable
> to the public struct io_pgtable_cfg?
>
> Or am I missing another bits_per_level?
Bleh, apologies, I always confuse myself trying to remember the fiddly
design of io-pgtable data. However, I think this then ends up proving
the opposite point - the number of pages per table only happens to be a
fixed constant for certain formats like LPAE, but does not necessarily
generalise. For instance for a single v7s config it would be 1024 or 256
or 16 depending on what has actually been unmapped.
The mechanism as proposed implicitly assumes LPAE format, so I still
think we're better off making that assumption explicit. And at that
point arm-smmu-v3 can then freely admit it already knows the number is
simply 1/8th of the domain page size.
Thanks,
Robin.