Re: [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system

[Baoquan He <bhe@redhat.com>]

On 05/21/17 at 01:38pm, Thomas Garnier wrote:
> On Sat, May 20, 2017 at 5:02 AM, Baoquan He <bhe@redhat.com> wrote:
> >  arch/x86/mm/kaslr.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> > index aed2064..20b0456 100644
> > --- a/arch/x86/mm/kaslr.c
> > +++ b/arch/x86/mm/kaslr.c
> > @@ -27,6 +27,7 @@
> >  #include <asm/pgtable.h>
> >  #include <asm/setup.h>
> >  #include <asm/kaslr.h>
> > +#include <asm/uv/uv.h>
> >
> >  #include "mm_internal.h"
> >
> > @@ -123,7 +124,7 @@ void __init kernel_randomize_memory(void)
> >                 CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
> >
> >         /* Adapt phyiscal memory region size based on available memory */
> > -       if (memory_tb < kaslr_regions[0].size_tb)
> > +       if (memory_tb < kaslr_regions[0].size_tb && !is_early_uv_system())
> 
> Given your example, any way we could just restrict memory_tb to be
> 32TB? Or different configurations will result in different mappings?

Thanks for looking into this, Thomas!

For that machine where I used to reproduce the bug and test, 32TB memory
need be mapped to the direct mapping region. I am not sure if SGI UV
system has larger MMIOH region now or in the future in different machine.
If they have machine owning MMIOH region bigger than 64TB, then it's a
problem SGI UV need fix because that will break system whether kaslr
enabled or not.

Hi Mike, Russ and Frank,

About Thomas's question, could you help answer it? Could other SGI UV
system has MMIOH region bigger than 32TB?

Thanks
Baoquan

> 
> >                 kaslr_regions[0].size_tb = memory_tb;
> >
> >         /* Calculate entropy available between regions */