Re: [PATCH RFCv2 10/15] xen/arm: mm: Allocate xen page tables in domheap rather than xenheap

[Julien Grall <julien@xxxxxxx>]

Hi Stefano,

On 12/05/2021 23:44, Stefano Stabellini wrote:
> On Sun, 25 Apr 2021, Julien Grall wrote:
> > From: Julien Grall <jgrall@xxxxxxxxxx>
> >
> > xen_{un,}map_table() already uses the helper to map/unmap pages
> > on-demand (note this is currently a NOP on arm64). So switching to
> > domheap don't have any disavantage.
> >
> > But this as the benefit:
> >      - to keep the page tables unmapped if an arch decided to do so
> >      - reduce xenheap use on arm32 which can be pretty small
> >
> > Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx>
> Thanks for the patch. It looks OK but let me ask a couple of questions
> to clarify my doubts.
>
> This change should have no impact to arm64, right?
>
> For arm32, I wonder why we were using map_domain_page before in
> xen_map_table: it wasn't necessary, was it? In fact, one could even say
> that it was wrong?
In xen_map_table() we need to be able to map pages from Xen binary, 
xenheap... On arm64, we would be able to use mfn_to_virt() because 
everything is mapped in Xen. But that's not the case on arm32. So we 
need a way to map anything easily.
The only difference between xenheap and domheap are the former is always 
mapped while the latter may not be. So one can also view a xenheap page 
as a glorified domheap.
I also don't really want to create yet another interface to map pages 
(we have vmap(), map_domain_page(), map_domain_global_page()...). So, 
when I implemented xen_map_table() a couple of years ago, I came to the 
conclusion that this is a convenient (ab)use of the interface.
Cheers,

--
Julien Grall