Re: [PATCH 05/22] x86/srat: vmap the pages for acpi_slit

[Julien Grall <julien@xxxxxxx>]

Hi Jan,

On 23/12/2022 11:31, Julien Grall wrote:
> On 20/12/2022 15:30, Jan Beulich wrote:
> > On 16.12.2022 12:48, Julien Grall wrote:
> > > From: Hongyan Xia <hongyxia@xxxxxxxxxx>
> > >
> > > This avoids the assumption that boot pages are in the direct map.
> > >
> > > Signed-off-by: Hongyan Xia <hongyxia@xxxxxxxxxx>
> > > Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx>
> > Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> >
> > However, ...
> >
> > > --- a/xen/arch/x86/srat.c
> > > +++ b/xen/arch/x86/srat.c
> > > @@ -139,7 +139,8 @@ void __init acpi_numa_slit_init(struct 
> > > acpi_table_slit *slit)
> > >           return;
> > >       }
> > >       mfn = alloc_boot_pages(PFN_UP(slit->header.length), 1);
> > > -    acpi_slit = mfn_to_virt(mfn_x(mfn));
> > > +    acpi_slit = vmap_contig_pages(mfn, PFN_UP(slit->header.length));
> > ... with the increased use of vmap space the VA range used will need
> > growing. And that's perhaps better done ahead of time than late.
> I will have a look to increase the vmap().
I have started to look at this. The current size of VMAP is 64GB.

At least in the setup I have I didn't see any particular issue with the 
existing size of the vmap. Looking through the history, the last time it 
was bumped by one of your commit (see b0581b9214d2) but it is not clear 
what was the setup.
Given I don't have a setup where the VMAP is exhausted it is not clear 
to me what would be an acceptable bump.
AFAICT, in PML4 slot 261, we still have 62GB reserved for future. So I 
was thinking to add an extra 32GB which would bring the VMAP to 96GB. 
This is just a number that doesn't use all the reserved space but still 
a power of two.
Are you fine with that?

Cheers,

--
Julien Grall