All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Dave Young <dyoung@redhat.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, mingo@redhat.com,
	tglx@linutronix.de, hpa@zytor.com, thgarnie@google.com,
	keescook@chromium.org, akpm@linux-foundation.org,
	yamada.masahiro@socionext.com, rja@hpe.com, frank.ramsay@hpe.com
Subject: Re: [PATCH v2 RESEND 1/2] x86/UV: Introduce a helper function to check UV system at earlier stage
Date: Thu, 14 Sep 2017 16:08:14 +0800	[thread overview]
Message-ID: <20170914080814.GO12824@x1> (raw)
In-Reply-To: <20170914074901.GA5182@dhcp-128-65.nay.redhat.com>

On 09/14/17 at 03:49pm, Dave Young wrote:
> > > diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h
> > > index b5a32231abd8..93d7ad8763ba 100644
> > > --- a/arch/x86/include/asm/uv/uv.h
> > > +++ b/arch/x86/include/asm/uv/uv.h
> > > @@ -18,6 +18,11 @@ extern void uv_nmi_init(void);
> > >  extern void uv_system_init(void);
> > >  extern const struct cpumask *uv_flush_tlb_others(const struct cpumask *cpumask,
> > >  						 const struct flush_tlb_info *info);
> > > +#include <linux/efi.h>
> > > +static inline int is_early_uv_system(void)
> > > +{
> > > +	return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
> > > +}
> 

Thanks for looking into this, Dave!

> 
> Sorry for jumping in late, I have two questions about the patch:
> 
> 1) For efi tables, the only invalid value is EFI_INVALID_TABLE_ADDR, and
> efi struct is initialized as EFI_INVALID_TABLE_ADDR by default so no
> need to check "|| !efi.uv_systab". Do we have any UV firmware specific
> assumption that "0" is also possible to be assigned?

Hmm, in uv_bios_init() it also checks the !efi.uv_systab case. And
EFI_INVALID_TABLE_ADDR checking is earlier, it won't affect the result
if it's EFI_INVALID_TABLE_ADDR. And !efi.uv_systab can make it safer
since it doesn't work either if efi.uv_systab is 0. Mainly it's not
harmful.

Mike, what's your thought? Should I only check the (efi.uv_systab ==
EFI_INVALID_TABLE_ADDR) case?

> 
> 2) It seems adding this function in uv.h for separating this for uv
> system only purpose. But I feel it is better to put it in efi.h instead.

At the beginning I put it in efi.c, later Mike suggested putting it in
asm/uv/uv.h. You can also find the discussion in below link.
https://patchwork.kernel.org/patch/9732787/

Thanks
Baoquan

> 
> uv_systab is already a member of struct efi, it is in efi.h so it is
> natural to check the table exist or not. Then just include efi.h in
> kaslr.c and use the function.
> 
> something like drivers/firmware/efi/esrt.c: esrt_table_exists()
> 
> Anyway I have no strong opinon, it looks more natural to me though.
> 
> > >  
> > >  #else	/* X86_UV */
> > >  
> > > @@ -30,6 +35,7 @@ static inline const struct cpumask *
> > >  uv_flush_tlb_others(const struct cpumask *cpumask,
> > >  		    const struct flush_tlb_info *info)
> > >  { return cpumask; }
> > > +static inline int is_early_uv_system(void)	{ return 0; }
> > >  
> > >  #endif	/* X86_UV */
> > >  
> > > -- 
> > > 2.5.5
> > > 
> 
> Thanks
> Dave

  reply	other threads:[~2017-09-14  8:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-07  7:42 [PATCH v2 RESEND 0/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system Baoquan He
2017-09-07  7:42 ` [PATCH v2 RESEND 1/2] x86/UV: Introduce a helper function to check UV system at earlier stage Baoquan He
2017-09-14  7:29   ` Baoquan He
2017-09-14  7:49     ` Dave Young
2017-09-14  8:08       ` Baoquan He [this message]
2017-09-15  0:47         ` Dave Young
2017-09-15  0:55         ` Dave Young
2017-09-07  7:42 ` [PATCH v2 RESEND 2/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system Baoquan He
2017-09-28  7:56   ` Ingo Molnar
2017-09-28  8:31     ` Baoquan He
2017-09-28  9:01       ` Ingo Molnar
2017-09-28 14:10         ` Mike Travis
2017-09-30 11:25           ` Baoquan He
2018-05-17  3:18           ` Baoquan He
2018-05-17 15:06             ` Ramsay, Frank
2018-05-17 15:47               ` Mike Travis
     [not found]             ` <53301a1e-e817-912f-cf7d-0000b078c7a3@hpe.com>
     [not found]               ` <20180523000306.GY24627@MiWiFi-R3L-srv>
     [not found]                 ` <7ce3cc80-3991-f914-c539-9fa38256ea4b@hpe.com>
2018-05-31  3:26                   ` Baoquan He
2017-09-14  1:44 ` [PATCH v2 RESEND 0/2] " Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170914080814.GO12824@x1 \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dyoung@redhat.com \
    --cc=frank.ramsay@hpe.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rja@hpe.com \
    --cc=tglx@linutronix.de \
    --cc=thgarnie@google.com \
    --cc=x86@kernel.org \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.