On Fri, Jul 25, 2025 at 11:54:27AM +0200, Igor Mammedov wrote: > If number of CPUs is increased up to 2048, it will push > available pages above 16Mb range and make smap/pku/pks > tests fail with 'Could not reserve memory' error. > > Move pages used by tests to 32Mb to fix it. > > Signed-off-by: Igor Mammedov <imammedo@xxxxxxxxxx> Reviewed-by: Peter Xu <peterx@xxxxxxxxxx> > --- > x86/pks.c | 2 +- > x86/pku.c | 2 +- > x86/smap.c | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/x86/pks.c b/x86/pks.c > index f4d6ac83..9b9519ba 100644 > --- a/x86/pks.c > +++ b/x86/pks.c > @@ -6,7 +6,7 @@ > #include "x86/msr.h" > > #define PTE_PKEY_BIT 59 > -#define SUPER_BASE (1 << 23) > +#define SUPER_BASE (2 << 24) Nitpick: maybe 1<<25 would be easier to read. Below are some random thoughts when reading these tests.. I'm not sure whether I understand them correctly here: all of them so far depend on the "test" var present in the .bss section, and they all assumed that the var's physical address (likely together with the whole .bss) will be under SUPER_BASE after loaded in the VM. Based on that, there's yet another restriction versus the need to reserve (SUPER_BASE, SUPER_BASE*2), because the tests want to map the same (0, SUPER_BASE) memory twice in that virtual address range, so here the tests do not really need the phys pages in the back but kind of a way to reserve virtual addresses.. Instead of these tricks, I wonder whether we can do alloc_page() once, then put the test var on the page allocated. Then we can build the required PKU/PKS/SMAP special pgtables on top, mapping to the page allocated. It should make sure system changes (like growing num_cpus) never affect it anymore. That (even if feasible.. or maybe I missed something) can definitely involve more changes, so not something to ask for on adding the hpet test / x2apic support. Just some pure thoughts when reading it.. Thanks, -- Peter Xu
