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

[Igor Mammedov <imammedo@redhat.com>]

On Wed, 30 Jul 2025 16:56:18 -0400
Peter Xu <peterx@redhat.com> wrote:

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

I can try with, if I have to respin.

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

I had the same thoughts but I'm not confident enough to rewrite
those tests. Hence a knee-jerk reaction of just fixing up base
to unbreak affected test.

> 
> Thanks,
>