Sorry, forget 'To' Mike, Russ and Frank
On 05/22/17 at 07:14am, Baoquan He wrote: > On 05/21/17 at 01:38pm, Thomas Garnier wrote: > > On Sat, May 20, 2017 at 5:02 AM, Baoquan He <b...@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 */
