On 13/03/2025 11:32, Luca Fancellu wrote:
>
>
> Hi Michal,
>
>> On 13 Mar 2025, at 10:19, Orzel, Michal <michal.or...@amd.com> wrote:
>>
>>
>>
>> On 12/03/2025 14:52, Luca Fancellu wrote:
>>>
>>>
>>> Rename the setup_pagetables function to setup_mappings in
>>> order to be implemented also for MPU system that does not
>>> have page tables.
>>
>> mappings is better than pagetables, so:
>> Reviewed-by: Michal Orzel <michal.or...@amd.com>
>>
>> but I'd like to understand what will be implementation of setup_mappings for
>> MPU. I suppose regions setup such that the following call to early_fdt_map
>> can
>> succeed and doing this in setup_mm is already too late?
>
> So on the MPU side, mappings are well defined in HW by registers, so we don’t
> need to
> allocate pagetables, so setup_mappings in reality will only prepare our
> logical data structure
> that tracks the MPU region state (few regions are already written by the asm
> early code and
> needs to be tracked).
>
> early_fdt_map won’t use this logical view of the MPU (as it’s called early),
> it will use low level
> API to access the MPU registers, like the early asm code did, basically to
> map the DTB.
>
> Doing that, we ensure that the current code flow in start_xen can be reused
> as it.
Then the question is: can the MPU part be moved to setup_mm if early_fdt_map
does not need setup_mappings? If so, we can avoid introducing a function with a
name that is at least odd in MPU context and leave setup_pagetables only for
MMU. Adding a function with not ideal name just for the sake of avoiding #ifdef
MMU does not sound like a good idea for me.
You can check with others on this one.
~Michal