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.
