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

[Jan Beulich <jbeulich@suse.com>]

On 30.01.2023 20:27, Julien Grall wrote:
> 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@amazon.com>
>>>>
>>>> This avoids the assumption that boot pages are in the direct map.
>>>>
>>>> Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
>>>> Signed-off-by: Julien Grall <jgrall@amazon.com>
>>>
>>> Reviewed-by: Jan Beulich <jbeulich@suse.com>
>>>
>>> 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?

Hmm. Leaving aside that 96Gb isn't a power of two, my comment saying
"ahead of time" was under the (wrong, as it now looks) impression that
the goal of your series was to truly do away with the directmap. I was
therefore expecting a much larger bump in size, perhaps moving the
vmap area into space presently occupied by the directmap. IOW for the
time being, with no _significant_ increase of space consumption, we
may well be fine with the 64Gb range.

Jan