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 <[email protected]>
This avoids the assumption that boot pages are in the direct map.
Signed-off-by: Hongyan Xia <[email protected]>
Signed-off-by: Julien Grall <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
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
