Re: [PATCH 22/22] xen/arm64: Allow the admin to enable/disable the directmap

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 24 Jan 2023, Julien Grall wrote:
> Hi Stefano,
> 
> On 24/01/2023 00:12, Stefano Stabellini wrote:
> > On Mon, 23 Jan 2023, Julien Grall wrote:
> > Ah yes! I see it now that we are relying on the same area
> > (alloc_xenheap_pages calls page_to_virt() then map_pages_to_xen()).
> > 
> > map_pages_to_xen() is able to create pagetable entries at every level,
> > but we need to make sure they are shared across per-cpu pagetables. To
> > make that happen, we are pre-creating the L0/L1 entries here so that
> > they become common across all per-cpu pagetables and then we let
> > map_pages_to_xen() do its job.
> > 
> > Did I understand it right?
> 
> Your understanding is correct.

Great!


> > > I can add summary in the commit message.
> > 
> > I would suggest to improve a bit the in-code comment on top of
> > setup_directmap_mappings. I might also be able to help with the text
> > once I am sure I understood what is going on :-)

How about this comment (feel free to edit/improve it as well, just a
suggestion):

In the !arch_has_directmap() case this function allocates empty L1
tables and creates the L0 entries for the direct map region.

When the direct map is disabled, alloc_xenheap_pages results in the page
being temporarily mapped in the usual xenheap address range via
map_pages_to_xen(). map_pages_to_xen() is able to create pagetable
entries at every level, but we need to make sure they are shared across
per-cpu pagetables. For this reason, here in this function we are
creating the L0 entries and empty L1 tables in advance, so that they
become common across all per-cpu pagetables.