Re: [kvm-unit-tests PATCH v4 3/5] x86: move USERBASE to 32Mb in smap/pku/pks tests

[Peter Xu <peterx@redhat.com>]

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@redhat.com>

Reviewed-by: Peter Xu <peterx@redhat.com>

> ---
>  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