[PATCH 1/8] x86/platform/uv: Save OEM_ID from ACPI MADT probe

[Mike Travis]

Save the OEM_ID and OEM_TABLE_ID passed to the apic driver probe function
for later use.  Also, convert the char list arg passed from the kernel
to a true null-terminated string.

Signed-off-by: Mike Travis 
Reviewed-by: Steve Wahl 
Reviewed-by: Dimitri Sivanich 
---
 arch/x86/kernel/apic/x2apic_uv_x.c |   16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -51,6 +52,10 @@ static u64   gru_dist_base, gru_first_no
 static u64 gru_dist_lmask, gru_dist_umask;
 static union uvh_apiciduvh_apicid;
 
+/* Unpack OEM/TABLE ID's to be NULL terminated strings */
+static u8 oem_id[ACPI_OEM_ID_SIZE + 1];
+static u8 oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
+
 /* Information derived from CPUID: */
 static struct {
unsigned int apicid_shift;
@@ -268,11 +273,20 @@ static void __init uv_set_apicid_hibit(v
}
 }
 
-static int __init uv_acpi_madt_oem_check(char *oem_id, char *oem_table_id)
+static void __init uv_stringify(int len, char *to, char *from)
+{
+   /* Relies on 'to' being NULL chars so result will be NULL terminated */
+   strncpy(to, from, len-1);
+}
+
+static int __init uv_acpi_madt_oem_check(char *_oem_id, char *_oem_table_id)
 {
int pnodeid;
int uv_apic;
 
+   uv_stringify(sizeof(oem_id), oem_id, _oem_id);
+   uv_stringify(sizeof(oem_table_id), oem_table_id, _oem_table_id);
+
if (strncmp(oem_id, "SGI", 3) != 0) {
if (strncmp(oem_id, "NSGI", 4) == 0) {
uv_hubless_system = true;

-- 

[PATCH 2/8] x86/platform/uv: Return UV Hubless System Type

[Mike Travis]

Return the type of UV hubless system for UV specific code that depends
on that.  Use a define to indicate the change in arg type for this
function in uv.h.  Add a function to convert UV system type to bit
pattern needed for is_uv_hubless().

Signed-off-by: Mike Travis 
Reviewed-by: Steve Wahl 
Reviewed-by: Dimitri Sivanich 
---
 arch/x86/include/asm/uv/uv.h   |   13 +++--
 arch/x86/kernel/apic/x2apic_uv_x.c |   29 +++--
 2 files changed, 30 insertions(+), 12 deletions(-)

--- linux.orig/arch/x86/include/asm/uv/uv.h
+++ linux/arch/x86/include/asm/uv/uv.h
@@ -12,13 +12,21 @@ struct mm_struct;
 #ifdef CONFIG_X86_UV
 #include 
 
+static inline int uv(int uvtype)
+{
+   /* uv(0) is "any" */
+   if (uvtype >= 0 && uvtype <= 30)
+   return 1 << uvtype;
+   return 1;
+}
 extern enum uv_system_type get_uv_system_type(void);
 static inline bool is_early_uv_system(void)
 {
return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
 }
 extern int is_uv_system(void);
-extern int is_uv_hubless(void);
+extern int _is_uv_hubless(int uvtype);
+#define is_uv_hubless _is_uv_hubless
 extern void uv_cpu_init(void);
 extern void uv_nmi_init(void);
 extern void uv_system_init(void);
@@ -30,7 +38,8 @@ extern const struct cpumask *uv_flush_tl
 static inline enum uv_system_type get_uv_system_type(void) { return UV_NONE; }
 static inline bool is_early_uv_system(void){ return 0; }
 static inline int is_uv_system(void)   { return 0; }
-static inline int is_uv_hubless(void)  { return 0; }
+static inline int _is_uv_hubless(int uv) { return 0; }
+#define is_uv_hubless _is_uv_hubless
 static inline void uv_cpu_init(void)   { }
 static inline void uv_system_init(void){ }
 static inline const struct cpumask *
--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -46,7 +46,7 @@
 DEFINE_PER_CPU(int, x2apic_extra_bits);
 
 static enum uv_system_type uv_system_type;
-static booluv_hubless_system;
+static int uv_hubless_system;
 static u64 gru_start_paddr, gru_end_paddr;
 static u64 gru_dist_base, gru_first_node_paddr = -1LL, 
gru_last_node_paddr;
 static u64 gru_dist_lmask, gru_dist_umask;
@@ -288,11 +288,20 @@ static int __init uv_acpi_madt_oem_check
uv_stringify(sizeof(oem_table_id), oem_table_id, _oem_table_id);
 
if (strncmp(oem_id, "SGI", 3) != 0) {
-   if (strncmp(oem_id, "NSGI", 4) == 0) {
-   uv_hubless_system = true;
-   pr_info("UV: OEM IDs %s/%s, HUBLESS\n",
-   oem_id, oem_table_id);
-   }
+   if (strncmp(oem_id, "NSGI", 4) != 0)
+   return 0;
+
+   /* UV4 Hubless, CH, (0x11:UV4+Any) */
+   if (strncmp(oem_id, "NSGI4", 5) == 0)
+   uv_hubless_system = 0x11;
+
+   /* UV3 Hubless, UV300/MC990X w/o hub (0x9:UV3+Any) */
+   else
+   uv_hubless_system = 0x9;
+
+   pr_info("UV: OEM IDs %s/%s, HUBLESS(0x%x)\n",
+   oem_id, oem_table_id, uv_hubless_system);
+
return 0;
}
 
@@ -370,11 +379,11 @@ int is_uv_system(void)
 }
 EXPORT_SYMBOL_GPL(is_uv_system);
 
-int is_uv_hubless(void)
+int _is_uv_hubless(int uvtype)
 {
-   return uv_hubless_system;
+   return (uv_hubless_system & uvtype);
 }
-EXPORT_SYMBOL_GPL(is_uv_hubless);
+EXPORT_SYMBOL_GPL(_is_uv_hubless);
 
 void **__uv_hub_info_list;
 EXPORT_SYMBOL_GPL(__uv_hub_info_list);
@@ -1612,7 +1621,7 @@ static void __init uv_system_init_hub(vo
  */
 void __init uv_system_init(void)
 {
-   if (likely(!is_uv_system() && !is_uv_hubless()))
+   if (likely(!is_uv_system() && !is_uv_hubless(1)))
return;
 
if (is_uv_system())

-- 

[PATCH 6/8] x86/platform/uv: Decode UVsystab Info

[Mike Travis]

Decode the hubless UVsystab passed from BIOS to the kernel saving
pertinent info in a similar manner that hubbed UVsystabs are decoded.

Signed-off-by: Mike Travis 
Reviewed-by: Steve Wahl 
Reviewed-by: Dimitri Sivanich 
---
 arch/x86/kernel/apic/x2apic_uv_x.c |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -1323,7 +1323,8 @@ static int __init decode_uv_systab(void)
struct uv_systab *st;
int i;
 
-   if (uv_hub_info->hub_revision < UV4_HUB_REVISION_BASE)
+   /* Select only UV4 (hubbed or hubless) and higher */
+   if (is_uv_hubbed(-2) < uv(4) && is_uv_hubless(-2) < uv(4))
return 0;   /* No extended UVsystab required */
 
st = uv_systab;
@@ -1574,8 +1575,19 @@ static __init int uv_system_init_hubless
 
/* Init kernel/BIOS interface */
rc = uv_bios_init();
+   if (rc < 0) {
+   pr_err("UV: BIOS init error:%d\n", rc);
+   return rc;
+   }
+
+   /* Process UVsystab */
+   rc = decode_uv_systab();
+   if (rc < 0) {
+   pr_err("UV: UVsystab decode error:%d\n", rc);
+   return rc;
+   }
 
-   /* Create user access node if UVsystab available */
+   /* Create user access node */
if (rc >= 0)
uv_setup_proc_files(1);
 

-- 

[PATCH 8/8] x86/platform/uv: Account for UV Hubless in is_uvX_hub Ops

[Mike Travis]

The references in the is_uvX_hub() function uses the hub_info pointer
which will be NULL when the system is hubless.  This change avoids
that NULL dereference.  It is also an optimization in performance.

Signed-off-by: Mike Travis 
Reviewed-by: Steve Wahl 
Reviewed-by: Dimitri Sivanich 
---
 arch/x86/include/asm/uv/.uv_hub.h.swp |binary
 arch/x86/include/asm/uv/uv_hub.h |   60 ---
 1 file changed, 19 insertions(+), 41 deletions(-)

Binary files linux.orig/arch/x86/include/asm/uv/.uv_hub.h.swp and 
linux/arch/x86/include/asm/uv/.uv_hub.h.swp differ
--- linux.orig/arch/x86/include/asm/uv/uv_hub.h
+++ linux/arch/x86/include/asm/uv/uv_hub.h
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -243,83 +244,60 @@ static inline int uv_hub_info_check(int
 #define UV4_HUB_REVISION_BASE  7
 #define UV4A_HUB_REVISION_BASE 8   /* UV4 (fixed) rev 2 */
 
-#ifdef UV1_HUB_IS_SUPPORTED
 static inline int is_uv1_hub(void)
 {
-   return uv_hub_info->hub_revision < UV2_HUB_REVISION_BASE;
-}
+#ifdef UV1_HUB_IS_SUPPORTED
+   return is_uv_hubbed(uv(1));
 #else
-static inline int is_uv1_hub(void)
-{
return 0;
-}
 #endif
+}
 
-#ifdef UV2_HUB_IS_SUPPORTED
 static inline int is_uv2_hub(void)
 {
-   return ((uv_hub_info->hub_revision >= UV2_HUB_REVISION_BASE) &&
-   (uv_hub_info->hub_revision < UV3_HUB_REVISION_BASE));
-}
+#ifdef UV2_HUB_IS_SUPPORTED
+   return is_uv_hubbed(uv(2));
 #else
-static inline int is_uv2_hub(void)
-{
return 0;
-}
 #endif
+}
 
-#ifdef UV3_HUB_IS_SUPPORTED
 static inline int is_uv3_hub(void)
 {
-   return ((uv_hub_info->hub_revision >= UV3_HUB_REVISION_BASE) &&
-   (uv_hub_info->hub_revision < UV4_HUB_REVISION_BASE));
-}
+#ifdef UV3_HUB_IS_SUPPORTED
+   return is_uv_hubbed(uv(3));
 #else
-static inline int is_uv3_hub(void)
-{
return 0;
-}
 #endif
+}
 
 /* First test "is UV4A", then "is UV4" */
-#ifdef UV4A_HUB_IS_SUPPORTED
-static inline int is_uv4a_hub(void)
-{
-   return (uv_hub_info->hub_revision >= UV4A_HUB_REVISION_BASE);
-}
-#else
 static inline int is_uv4a_hub(void)
 {
+#ifdef UV4A_HUB_IS_SUPPORTED
+   if (is_uv_hubbed(uv(4)))
+   return (uv_hub_info->hub_revision == UV4A_HUB_REVISION_BASE);
+#endif
return 0;
 }
-#endif
 
-#ifdef UV4_HUB_IS_SUPPORTED
 static inline int is_uv4_hub(void)
 {
-   return uv_hub_info->hub_revision >= UV4_HUB_REVISION_BASE;
-}
+#ifdef UV4_HUB_IS_SUPPORTED
+   return is_uv_hubbed(uv(4));
 #else
-static inline int is_uv4_hub(void)
-{
return 0;
-}
 #endif
+}
 
 static inline int is_uvx_hub(void)
 {
-   if (uv_hub_info->hub_revision >= UV2_HUB_REVISION_BASE)
-   return uv_hub_info->hub_revision;
-
-   return 0;
+   return (is_uv_hubbed(-2) >= uv(2));
 }
 
 static inline int is_uv_hub(void)
 {
-#ifdef UV1_HUB_IS_SUPPORTED
-   return uv_hub_info->hub_revision;
-#endif
-   return is_uvx_hub();
+   return is_uv1_hub() || is_uvx_hub();
 }
 
 union uvh_apicid {

-- 

[PATCH 7/8] x86/platform/uv: Check EFI Boot to set reboot type

[Mike Travis]

Change to checking for EFI Boot type from previous check on if this
is a KDUMP kernel.  This allows for KDUMP kernels that can handle
EFI reboots.

Signed-off-by: Mike Travis 
Reviewed-by: Steve Wahl 
Reviewed-by: Dimitri Sivanich 
---
 arch/x86/kernel/apic/x2apic_uv_x.c |   18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1503,6 +1504,14 @@ static void __init build_socket_tables(v
}
 }
 
+/* Check which reboot to use */
+static void check_efi_reboot(void)
+{
+   /* If EFI reboot not available, use ACPI reboot */
+   if (!efi_enabled(EFI_BOOT))
+   reboot_type = BOOT_ACPI;
+}
+
 /* Setup user proc fs files */
 static int proc_hubbed_show(struct seq_file *file, void *data)
 {
@@ -1591,6 +1600,8 @@ static __init int uv_system_init_hubless
if (rc >= 0)
uv_setup_proc_files(1);
 
+   check_efi_reboot();
+
return rc;
 }
 
@@ -1724,12 +1735,7 @@ static void __init uv_system_init_hub(vo
/* Register Legacy VGA I/O redirection handler: */
pci_register_set_vga_state(uv_set_vga_state);
 
-   /*
-* For a kdump kernel the reset must be BOOT_ACPI, not BOOT_EFI, as
-* EFI is not enabled in the kdump kernel:
-*/
-   if (is_kdump_kernel())
-   reboot_type = BOOT_ACPI;
+   check_efi_reboot();
 }
 
 /*

-- 

Re: [PATCH v3 8/9] x86/mm/tlb: Remove UV special case

[Mike Travis]

It is a fact that the UV is still the UV and SGI is now part of HPE. 
The current external product is known as SuperDome Flex.  It is both up 
to date as well as very well maintained.  The ACK I provided was an okay 
to change the code, but please make the description accurate.


On 7/18/2019 5:58 PM, Nadav Amit wrote:

SGI UV support is outdated and not maintained, and it is not clear how
it performs relatively to non-UV. Remove the code to simplify the code.

Cc: Peter Zijlstra 
Cc: Dave Hansen 
Acked-by: Mike Travis 
Suggested-by: Andy Lutomirski 
Signed-off-by: Nadav Amit 
---
  arch/x86/mm/tlb.c | 25 -
  1 file changed, 25 deletions(-)

diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 89f83ad19507..40daad52ec7d 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -684,31 +684,6 @@ void native_flush_tlb_multi(const struct cpumask *cpumask,
trace_tlb_flush(TLB_REMOTE_SEND_IPI,
(info->end - info->start) >> PAGE_SHIFT);
  
-	if (is_uv_system()) {

-   /*
-* This whole special case is confused.  UV has a "Broadcast
-* Assist Unit", which seems to be a fancy way to send IPIs.
-* Back when x86 used an explicit TLB flush IPI, UV was
-* optimized to use its own mechanism.  These days, x86 uses
-* smp_call_function_many(), but UV still uses a manual IPI,
-* and that IPI's action is out of date -- it does a manual
-* flush instead of calling flush_tlb_func_remote().  This
-* means that the percpu tlb_gen variables won't be updated
-* and we'll do pointless flushes on future context switches.
-*
-* Rather than hooking native_flush_tlb_multi() here, I think
-* that UV should be updated so that smp_call_function_many(),
-* etc, are optimal on UV.
-*/
-   flush_tlb_func_local((void *)info);
-
-   cpumask = uv_flush_tlb_others(cpumask, info);
-   if (cpumask)
-   smp_call_function_many(cpumask, flush_tlb_func_remote,
-  (void *)info, 1);
-   return;
-   }
-
/*
 * If no page tables were freed, we can skip sending IPIs to
 * CPUs in lazy TLB mode. They will flush the CPU themselves

Re: [PATCH v2 8/9] x86/mm/tlb: Remove UV special case

[Mike Travis]

On 7/9/2019 2:09 PM, Nadav Amit wrote:

On Jul 9, 2019, at 1:29 PM, Mike Travis  wrote:



On 7/9/2019 1:09 PM, Russ Anderson wrote:

On Tue, Jul 09, 2019 at 09:50:27PM +0200, Thomas Gleixner wrote:

On Tue, 2 Jul 2019, Nadav Amit wrote:


SGI UV support is outdated and not maintained, and it is not clear how
it performs relatively to non-UV. Remove the code to simplify the code.


You should at least Cc the SGI/HP folks on that. They are still
around. Done so.

Thanks Thomas.  The SGI UV is now HPE Superdome Flex and is
very much still supported.
Thanks.

Cc: Peter Zijlstra 
Cc: Dave Hansen 
Suggested-by: Andy Lutomirski 
Signed-off-by: Nadav Amit 
---
  arch/x86/mm/tlb.c | 25 -
  1 file changed, 25 deletions(-)

diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index b47a71820f35..64afe1215495 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -689,31 +689,6 @@ void native_flush_tlb_multi(const struct cpumask *cpumask,
trace_tlb_flush(TLB_REMOTE_SEND_IPI,
(info->end - info->start) >> PAGE_SHIFT);
  - if (is_uv_system()) {
-   /*
-* This whole special case is confused.  UV has a "Broadcast
-* Assist Unit", which seems to be a fancy way to send IPIs.
-* Back when x86 used an explicit TLB flush IPI, UV was
-* optimized to use its own mechanism.  These days, x86 uses
-* smp_call_function_many(), but UV still uses a manual IPI,
-* and that IPI's action is out of date -- it does a manual
-* flush instead of calling flush_tlb_func_remote().  This
-* means that the percpu tlb_gen variables won't be updated
-* and we'll do pointless flushes on future context switches.
-*
-* Rather than hooking native_flush_tlb_multi() here, I think
-* that UV should be updated so that smp_call_function_many(),
-* etc, are optimal on UV.
-*/


I thought this change was already proposed a bit ago and we acked it
awhile back. Also the replacement functionality is being worked on but it
is more complex. The smp call many has to support all the reasons why it’s
called and not just the tlb shoot downs as is the current BAU case.


Sorry for not cc’ing you before. In the meanwhile, can you give an explicit
acked-by? (I couldn’t find the previous patch you regarded.)


Sure:

Acked-by: Mike Travis 



Thanks,
Nadav

Re: [PATCH v2 8/9] x86/mm/tlb: Remove UV special case

[Mike Travis]

On 7/9/2019 1:09 PM, Russ Anderson wrote:

On Tue, Jul 09, 2019 at 09:50:27PM +0200, Thomas Gleixner wrote:

On Tue, 2 Jul 2019, Nadav Amit wrote:


SGI UV support is outdated and not maintained, and it is not clear how
it performs relatively to non-UV. Remove the code to simplify the code.


You should at least Cc the SGI/HP folks on that. They are still
around. Done so.


Thanks Thomas.  The SGI UV is now HPE Superdome Flex and is
very much still supported.

Thanks.


Cc: Peter Zijlstra 
Cc: Dave Hansen 
Suggested-by: Andy Lutomirski 
Signed-off-by: Nadav Amit 
---
  arch/x86/mm/tlb.c | 25 -
  1 file changed, 25 deletions(-)

diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index b47a71820f35..64afe1215495 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -689,31 +689,6 @@ void native_flush_tlb_multi(const struct cpumask *cpumask,
trace_tlb_flush(TLB_REMOTE_SEND_IPI,
(info->end - info->start) >> PAGE_SHIFT);
  
-	if (is_uv_system()) {

-   /*
-* This whole special case is confused.  UV has a "Broadcast
-* Assist Unit", which seems to be a fancy way to send IPIs.
-* Back when x86 used an explicit TLB flush IPI, UV was
-* optimized to use its own mechanism.  These days, x86 uses
-* smp_call_function_many(), but UV still uses a manual IPI,
-* and that IPI's action is out of date -- it does a manual
-* flush instead of calling flush_tlb_func_remote().  This
-* means that the percpu tlb_gen variables won't be updated
-* and we'll do pointless flushes on future context switches.
-*
-* Rather than hooking native_flush_tlb_multi() here, I think
-* that UV should be updated so that smp_call_function_many(),
-* etc, are optimal on UV.
-*/


I thought this change was already proposed a bit ago and we acked it 
awhile back.  Also the replacement functionality is being worked on but 
it is more complex.  The smp call many has to support all the reasons 
why it's called and not just the tlb shoot downs as is the current BAU case.



-   flush_tlb_func_local(info);
-
-   cpumask = uv_flush_tlb_others(cpumask, info);
-   if (cpumask)
-   smp_call_function_many(cpumask, flush_tlb_func_remote,
-  (void *)info, 1);
-   return;
-   }
-
/*
 * If no page tables were freed, we can skip sending IPIs to
 * CPUs in lazy TLB mode. They will flush the CPU themselves
--
2.17.1

Re: [PATCH 3/6] bitmap_parselist: rework input string parser

[Mike Travis]

On 3/26/2019 2:09 PM, Yuri Norov wrote:

+ Mike Travis 
+ Thomas Gleixner 

--
On Tue, Mar 26, 2019 at 12:07:45AM +0300, Yury Norov wrote:

The requirement for this rework is to keep the __bitmap_parselist()
copy-less and single-pass but make it more readable and maintainable by
splitting into logical parts and removing explicit nested cycles and
opaque local variables.

__bitmap_parselist() can parse userspace inputs and therefore we cannot
use simple_strtoul() to parse numbers.



So, all above depends to what memory we access kernel / user space.
Perhaps we can get copy of memory of a given size and then parse it in kernel 
space always?



--
With Best Regards,
Andy Shevchenko


What I missed during rework is that we have only one caller of *parselist_user  
-
it's write_irq_affinity() introduced by Mike Travis in kernel/irq/proc.c. It 
doesn't look
like a hot path as it's file operations handler. If no objections from Mike or 
Thomas,


No objections from me as long as you can still change irq affinity using 
a cpulist instead of a cpumask.


Thanks,
Mike Travis



I think it would make sense to copy_from_user() the userspace data at the 
beginning
in sake of simplicity of __bitmap_parselist(), as you suggested above.

Yury

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

[Mike Travis]

Hi Baoquan,

There was a breakage in the TSC code (for UV) where the change was to 
introduce an early TSC "adjustment".  This bypassed the UV auto setting 
of TSC by BIOS because it came before the UV init code could indicate 
that the TSC was already in sync.  (I believe I already sent you a note 
about this?)


To fix this, I sent in two patches, the first had this 
is_early_uv_system() function defined and the second had the check to 
avoid adjusting TSC too early.


The commit referred to is:


commit 20a8378aa9dd108a01cb0e695599f5257a885c4b
Author: Mike Travis 
Date:   Tue Oct 2 13:01:45 2018 -0500

x86/platform/uv: Provide is_early_uv_system()

Introduce is_early_uv_system() which uses efi.uv_systab to decide early

in the boot process whether the kernel is running on a UV system.

This is needed to skip other early setup/init code that might break

the UV platform if done too early such as before necessary ACPI tables
parsing takes place.



Check to see if that function is defined in the kernels you are pushing 
this patch to.


As to testing on a UV system, I can schedule the time to do that, just 
send me the details.


Thanks,
Mike

On 2/16/2019 6:09 PM, Baoquan He wrote:

Hi Mike,

On 02/16/19 at 10:00pm, Baoquan He wrote:

On SGI UV system, kernel often hangs when KASLR is enabled. Disabling
KASLR makes kernel work well.


I wrap codes which calculate the size of the direct mapping section
into a new function calc_direct_mapping_size() as Ingo suggested. This
code change has passed basic testing, but hasn't been tested on a
SGI UV machine after reproducing since it needs UV machine with UV
module installed of enough size.

To reproduce it, we can apply patches 0001~0005. If reproduced, patch
0006 can be applied on top to check if bug is fixed. Please help check
if the code is OK, if you have a machine, I can have a test.

Thanks
Baoquan



The back trace is:

kernel BUG at arch/x86/mm/init_64.c:311!
invalid opcode:  [#1] SMP
[...]
RIP: 0010:__init_extra_mapping+0x188/0x196
[...]
Call Trace:
  init_extra_mapping_uc+0x13/0x15
  map_high+0x67/0x75
  map_mmioh_high_uv3+0x20a/0x219
  uv_system_init_hub+0x12d9/0x1496
  uv_system_init+0x27/0x29
  native_smp_prepare_cpus+0x28d/0x2d8
  kernel_init_freeable+0xdd/0x253
  ? rest_init+0x80/0x80
  kernel_init+0xe/0x110
  ret_from_fork+0x2c/0x40

This is because the SGI UV system need map its MMIOH region to the direct
mapping section, and the mapping happens in rest_init() which is much
later than the calling of kernel_randomize_memory() to do mm KASLR. So
mm KASLR can't count in the size of the MMIOH region when calculate the
needed size of address space for the direct mapping section.

When KASLR is disabled, there are 64TB address space for both system RAM
and the MMIOH regions to share. When KASLR is enabled, the current code
of mm KASLR only reserves the actual size of system RAM plus extra 10TB
for the direct mapping. Thus later the MMIOH mapping could go beyond
the upper bound of the direct mapping to step into VMALLOC or VMEMMAP area.
Then BUG_ON() in __init_extra_mapping() will be triggered.

E.g on the SGI UV3 machine where this bug was reported , there are two
MMIOH regions:

[1.519001] UV: Map MMIOH0_HI 0xffc - 0x1000
[1.523001] UV: Map MMIOH1_HI 0x1000 - 0x2000

They are [16TB-16G, 16TB) and [16TB, 32TB). On this machine, 512G RAM are
spread out to 1TB regions. Then above two SGI MMIOH regions also will be
mapped into the direct mapping section.

To fix it, we need check if it's SGI UV system by calling
is_early_uv_system() in kernel_randomize_memory(). If yes, do not adapt
thesize of the direct mapping section, just keep it as is, e.g in level-4
paging mode, 64TB.

Signed-off-by: Baoquan He 
---
  arch/x86/mm/kaslr.c | 57 +
  1 file changed, 42 insertions(+), 15 deletions(-)

diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index ca12ed4e5239..754b5da91d43 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -29,6 +29,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "mm_internal.h"
  
@@ -113,15 +114,51 @@ static inline bool kaslr_memory_enabled(void)

return kaslr_enabled() && !IS_ENABLED(CONFIG_KASAN);
  }
  
+/*

+ * Even though a huge virtual address space is reserved for the direct
+ * mapping of physical memory, e.g in 4-level pageing mode, it's 64TB,
+ * rare system can own enough physical memory to use it up, most are
+ * even less than 1TB. So with KASLR enabled, we adapt the size of
+ * direct mapping area to size of actual physical memory plus the
+ * configured padding CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING.
+ * The left part will be taken out to join memory randomization.
+ *
+ * Note that UV system is an exception, its MMIOH region need be mapped
+ * into the direct mapping area too, while the size can't be got until
+ * rest_init() 

Re: [Patch v3 0/4] Protect against concurrent calls into UV BIOS

[Mike Travis]

On 2/14/2019 1:21 PM, Dimitri Sivanich wrote:

For the series:

Reviewed-by: Dimitri Sivanich 


As well as I:

Reviewed-by: Mike Travis 



On Wed, Feb 13, 2019 at 07:34:09PM +, Hedi Berriche wrote:

- Changes since v2
   Addressed comments from Ard Biesheuvel:
  * expose efi_runtime_lock to UV platform only instead of globally
  * remove unnecessary #ifdef CONFIG_EFI from bios_uv.c

- Changes since v1:
   Addressed comments from Bhupesh Sharma, Thomas Gleixner, and Ard Biesheuvel:
  * made __uv_bios_call() static
  * moved the efi_enabled() cleanup to its own patchlet
  * explained the reason for renaming the efi_runtime_lock semaphore
  * dropped the reviewed-bys as they should be given on the mailing list
  * Cc'ng sta...@vger.kernel.org given the nature of the problem addressed by 
the patches

---

Calls into UV BIOS were not being serialised which is wrong as it violates EFI
runtime rules, and bad as it does result in all sorts of potentially hard to
track down hangs and panics when efi_scratch.prev_mm gets clobbered whenever
efi_switch_mm() gets called concurrently from two different CPUs.

Patch #1 removes an unnecessary #ifdef CONFIG_EFI guard from bios_uv.c.

Patch #2 removes uv_bios_call_reentrant() because it's dead code.

Patch #3 is a cleanup that drops test_bit() in favour of the ad hoc 
efi_enabled().

Patch #4 makes uv_bios_call() variants use the efi_runtime_lock semaphore to
protect against concurrency.

Cc: Russ Anderson 
Cc: Mike Travis 
Cc: Dimitri Sivanich 
Cc: Steve Wahl 
Cc: sta...@vger.kernel.org # v4.9+

Hedi Berriche (4):
   x86/platform/UV: remove unnecessary #ifdef CONFIG_EFI
   x86/platform/UV: kill uv_bios_call_reentrant() as it has no callers
   x86/platform/UV: use efi_enabled() instead of test_bit()
   x86/platform/UV: use efi_runtime_lock to serialise BIOS calls

  arch/x86/include/asm/uv/bios.h  | 13 -
  arch/x86/platform/uv/bios_uv.c  | 35 ++---
  drivers/firmware/efi/runtime-wrappers.c |  7 +
  3 files changed, 34 insertions(+), 21 deletions(-)

--
2.20.1

[tip:x86/urgent] x86/tsc: Fix UV TSC initialization

[tip-bot for Mike Travis]

Commit-ID:  2647c43c7f3ba4b752bfce261d53b16e2f5bc9e3
Gitweb: https://git.kernel.org/tip/2647c43c7f3ba4b752bfce261d53b16e2f5bc9e3
Author: Mike Travis 
AuthorDate: Tue, 2 Oct 2018 13:01:46 -0500
Committer:  Thomas Gleixner 
CommitDate: Tue, 2 Oct 2018 21:29:16 +0200

x86/tsc: Fix UV TSC initialization

The recent rework of the TSC calibration code introduced a regression on UV
systems as it added a call to tsc_early_init() which initializes the TSC
ADJUST values before acpi_boot_table_init().  In the case of UV systems,
that is a necessary step that calls uv_system_init().  This informs
tsc_sanitize_first_cpu() that the kernel runs on a platform with async TSC
resets as documented in commit 341102c3ef29 ("x86/tsc: Add option that TSC
on Socket 0 being non-zero is valid")

Fix it by skipping the early tsc initialization on UV systems and let TSC
init tests take place later in tsc_init().

Fixes: cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once")
Suggested-by: Hedi Berriche 
Signed-off-by: Mike Travis 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
Cc: "H. Peter Anvin" 
Cc: Russ Anderson 
Cc: Dimitri Sivanich 
Cc: Borislav Petkov 
Cc: Kate Stewart 
Cc: Greg Kroah-Hartman 
Cc: Philippe Ombredanne 
Cc: Pavel Tatashin 
Cc: Peter Zijlstra 
Cc: Len Brown 
Cc: Dou Liyang 
Cc: Xiaoming Gao 
Cc: Rajvi Jingar 
Link: 
https://lkml.kernel.org/r/20181002180144.923579...@stormcage.americas.sgi.com

---
 arch/x86/kernel/tsc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 6490f618e096..b52bd2b6cdb4 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 unsigned int __read_mostly cpu_khz;/* TSC clocks / usec, not used here */
 EXPORT_SYMBOL(cpu_khz);
@@ -1433,6 +1434,9 @@ void __init tsc_early_init(void)
 {
if (!boot_cpu_has(X86_FEATURE_TSC))
return;
+   /* Don't change UV TSC multi-chassis synchronization */
+   if (is_early_uv_system())
+   return;
if (!determine_cpu_tsc_frequencies(true))
return;
loops_per_jiffy = get_loops_per_jiffy();

[tip:x86/urgent] x86/tsc: Fix UV TSC initialization

[tip-bot for Mike Travis]

Commit-ID:  2647c43c7f3ba4b752bfce261d53b16e2f5bc9e3
Gitweb: https://git.kernel.org/tip/2647c43c7f3ba4b752bfce261d53b16e2f5bc9e3
Author: Mike Travis 
AuthorDate: Tue, 2 Oct 2018 13:01:46 -0500
Committer:  Thomas Gleixner 
CommitDate: Tue, 2 Oct 2018 21:29:16 +0200

x86/tsc: Fix UV TSC initialization

The recent rework of the TSC calibration code introduced a regression on UV
systems as it added a call to tsc_early_init() which initializes the TSC
ADJUST values before acpi_boot_table_init().  In the case of UV systems,
that is a necessary step that calls uv_system_init().  This informs
tsc_sanitize_first_cpu() that the kernel runs on a platform with async TSC
resets as documented in commit 341102c3ef29 ("x86/tsc: Add option that TSC
on Socket 0 being non-zero is valid")

Fix it by skipping the early tsc initialization on UV systems and let TSC
init tests take place later in tsc_init().

Fixes: cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once")
Suggested-by: Hedi Berriche 
Signed-off-by: Mike Travis 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
Cc: "H. Peter Anvin" 
Cc: Russ Anderson 
Cc: Dimitri Sivanich 
Cc: Borislav Petkov 
Cc: Kate Stewart 
Cc: Greg Kroah-Hartman 
Cc: Philippe Ombredanne 
Cc: Pavel Tatashin 
Cc: Peter Zijlstra 
Cc: Len Brown 
Cc: Dou Liyang 
Cc: Xiaoming Gao 
Cc: Rajvi Jingar 
Link: 
https://lkml.kernel.org/r/20181002180144.923579...@stormcage.americas.sgi.com

---
 arch/x86/kernel/tsc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 6490f618e096..b52bd2b6cdb4 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 unsigned int __read_mostly cpu_khz;/* TSC clocks / usec, not used here */
 EXPORT_SYMBOL(cpu_khz);
@@ -1433,6 +1434,9 @@ void __init tsc_early_init(void)
 {
if (!boot_cpu_has(X86_FEATURE_TSC))
return;
+   /* Don't change UV TSC multi-chassis synchronization */
+   if (is_early_uv_system())
+   return;
if (!determine_cpu_tsc_frequencies(true))
return;
loops_per_jiffy = get_loops_per_jiffy();

[tip:x86/urgent] x86/platform/uv: Provide is_early_uv_system()

[tip-bot for Mike Travis]

Commit-ID:  20a8378aa9dd108a01cb0e695599f5257a885c4b
Gitweb: https://git.kernel.org/tip/20a8378aa9dd108a01cb0e695599f5257a885c4b
Author: Mike Travis 
AuthorDate: Tue, 2 Oct 2018 13:01:45 -0500
Committer:  Thomas Gleixner 
CommitDate: Tue, 2 Oct 2018 21:29:16 +0200

x86/platform/uv: Provide is_early_uv_system()

Introduce is_early_uv_system() which uses efi.uv_systab to decide early
in the boot process whether the kernel runs on a UV system.

This is needed to skip other early setup/init code that might break
the UV platform if done too early such as before necessary ACPI tables
parsing takes place.

Suggested-by: Hedi Berriche 
Signed-off-by: Mike Travis 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
Cc: "H. Peter Anvin" 
Cc: Russ Anderson 
Cc: Dimitri Sivanich 
Cc: Borislav Petkov 
Cc: Kate Stewart 
Cc: Greg Kroah-Hartman 
Cc: Philippe Ombredanne 
Cc: Pavel Tatashin 
Cc: Peter Zijlstra 
Cc: Len Brown 
Cc: Dou Liyang 
Cc: Xiaoming Gao 
Cc: Rajvi Jingar 
Link: 
https://lkml.kernel.org/r/20181002180144.801700...@stormcage.americas.sgi.com

---
 arch/x86/include/asm/uv/uv.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h
index a80c0673798f..e60c45fd3679 100644
--- a/arch/x86/include/asm/uv/uv.h
+++ b/arch/x86/include/asm/uv/uv.h
@@ -10,8 +10,13 @@ struct cpumask;
 struct mm_struct;
 
 #ifdef CONFIG_X86_UV
+#include 
 
 extern enum uv_system_type get_uv_system_type(void);
+static inline bool is_early_uv_system(void)
+{
+   return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
+}
 extern int is_uv_system(void);
 extern int is_uv_hubless(void);
 extern void uv_cpu_init(void);
@@ -23,6 +28,7 @@ extern const struct cpumask *uv_flush_tlb_others(const struct 
cpumask *cpumask,
 #else  /* X86_UV */
 
 static inline enum uv_system_type get_uv_system_type(void) { return UV_NONE; }
+static inline bool is_early_uv_system(void){ return 0; }
 static inline int is_uv_system(void)   { return 0; }
 static inline int is_uv_hubless(void)  { return 0; }
 static inline void uv_cpu_init(void)   { }

[tip:x86/urgent] x86/platform/uv: Provide is_early_uv_system()

[tip-bot for Mike Travis]

Commit-ID:  20a8378aa9dd108a01cb0e695599f5257a885c4b
Gitweb: https://git.kernel.org/tip/20a8378aa9dd108a01cb0e695599f5257a885c4b
Author: Mike Travis 
AuthorDate: Tue, 2 Oct 2018 13:01:45 -0500
Committer:  Thomas Gleixner 
CommitDate: Tue, 2 Oct 2018 21:29:16 +0200

x86/platform/uv: Provide is_early_uv_system()

Introduce is_early_uv_system() which uses efi.uv_systab to decide early
in the boot process whether the kernel runs on a UV system.

This is needed to skip other early setup/init code that might break
the UV platform if done too early such as before necessary ACPI tables
parsing takes place.

Suggested-by: Hedi Berriche 
Signed-off-by: Mike Travis 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
Cc: "H. Peter Anvin" 
Cc: Russ Anderson 
Cc: Dimitri Sivanich 
Cc: Borislav Petkov 
Cc: Kate Stewart 
Cc: Greg Kroah-Hartman 
Cc: Philippe Ombredanne 
Cc: Pavel Tatashin 
Cc: Peter Zijlstra 
Cc: Len Brown 
Cc: Dou Liyang 
Cc: Xiaoming Gao 
Cc: Rajvi Jingar 
Link: 
https://lkml.kernel.org/r/20181002180144.801700...@stormcage.americas.sgi.com

---
 arch/x86/include/asm/uv/uv.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h
index a80c0673798f..e60c45fd3679 100644
--- a/arch/x86/include/asm/uv/uv.h
+++ b/arch/x86/include/asm/uv/uv.h
@@ -10,8 +10,13 @@ struct cpumask;
 struct mm_struct;
 
 #ifdef CONFIG_X86_UV
+#include 
 
 extern enum uv_system_type get_uv_system_type(void);
+static inline bool is_early_uv_system(void)
+{
+   return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
+}
 extern int is_uv_system(void);
 extern int is_uv_hubless(void);
 extern void uv_cpu_init(void);
@@ -23,6 +28,7 @@ extern const struct cpumask *uv_flush_tlb_others(const struct 
cpumask *cpumask,
 #else  /* X86_UV */
 
 static inline enum uv_system_type get_uv_system_type(void) { return UV_NONE; }
+static inline bool is_early_uv_system(void){ return 0; }
 static inline int is_uv_system(void)   { return 0; }
 static inline int is_uv_hubless(void)  { return 0; }
 static inline void uv_cpu_init(void)   { }

[PATCH 2/2] x86/tsc: Fix UV TSC initialization

[Mike Travis]

Fix regression introduced by

commit cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once")

as it added a call to tsc_early_init() which initializes the TSC ADJUST
values before acpi_boot_table_init().  In the case of UV systems,
that is a necessary step thats calls uv_system_init().  This informs
tsc_sanitize_first_cpu() that we're on a platform with async TSC resets
as documented in

commit 341102c3ef29 ("x86/tsc: Add option that TSC on Socket 0 being non-zero 
is valid")

Fix by skipping the early tsc initialization on UV systems and let TSC
init tests take place later in tsc_init().

Fixes: cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once") 
Signed-off-by: Mike Travis 
Suggested-by: Hedi Berriche 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
---
 arch/x86/kernel/tsc.c |4 
 1 file changed, 4 insertions(+)

--- linux.orig/arch/x86/kernel/tsc.c
+++ linux/arch/x86/kernel/tsc.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 unsigned int __read_mostly cpu_khz;/* TSC clocks / usec, not used here */
 EXPORT_SYMBOL(cpu_khz);
@@ -1433,6 +1434,9 @@ void __init tsc_early_init(void)
 {
if (!boot_cpu_has(X86_FEATURE_TSC))
return;
+   /* Don't change UV TSC multi-chassis synchronization */
+   if (is_early_uv_system())
+   return;
if (!determine_cpu_tsc_frequencies(true))
return;
loops_per_jiffy = get_loops_per_jiffy();

-- 

[PATCH 2/2] x86/tsc: Fix UV TSC initialization

[Mike Travis]

Fix regression introduced by

commit cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once")

as it added a call to tsc_early_init() which initializes the TSC ADJUST
values before acpi_boot_table_init().  In the case of UV systems,
that is a necessary step thats calls uv_system_init().  This informs
tsc_sanitize_first_cpu() that we're on a platform with async TSC resets
as documented in

commit 341102c3ef29 ("x86/tsc: Add option that TSC on Socket 0 being non-zero 
is valid")

Fix by skipping the early tsc initialization on UV systems and let TSC
init tests take place later in tsc_init().

Fixes: cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once") 
Signed-off-by: Mike Travis 
Suggested-by: Hedi Berriche 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
---
 arch/x86/kernel/tsc.c |4 
 1 file changed, 4 insertions(+)

--- linux.orig/arch/x86/kernel/tsc.c
+++ linux/arch/x86/kernel/tsc.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 unsigned int __read_mostly cpu_khz;/* TSC clocks / usec, not used here */
 EXPORT_SYMBOL(cpu_khz);
@@ -1433,6 +1434,9 @@ void __init tsc_early_init(void)
 {
if (!boot_cpu_has(X86_FEATURE_TSC))
return;
+   /* Don't change UV TSC multi-chassis synchronization */
+   if (is_early_uv_system())
+   return;
if (!determine_cpu_tsc_frequencies(true))
return;
loops_per_jiffy = get_loops_per_jiffy();

-- 

[PATCH 0/2] Fix TSC ADJUST breakage causing TSC failure

[Mike Travis]

Fix a breakage caused by enabling early tsc initialization which bypasses
a check that disables the forcing of TSC ADJUST to 0 for chassis 0.
This is common on systems where all the chassis start up asynchronously
so which chassis should have a TSC ADJUST value of 0 is not predictable.

The solution is to add a check earlier than this early tsc init to
disable the potential of it incorrectly adjusting TSC ADJUST values that
are already correctly initialized.

*  Patch 1 adds an early callable function (after efi_init) that will
   check if this system might be a UV system.

*  Patch 2 adds code to tsc_early_init() which disables adjusting the
   TSC ADJUST value if it's a UV system.  This allows the later tsc_init
   function to test the tsc_async_resets flag that indicates the system
   chassis start up asynchronously, so which chassis should have a TSC
   ADJUST value of 0 is not predictable.  Further references are in
   the patch.

-- 

[PATCH 1/2] x86/platform/uv: Add is_early_uv_system check

[Mike Travis]

Introduce is_early_uv_system() which uses efi.uv_systab to decide early
in the boot process whether we're on a UV system.

This is needed to skip other early setup/init code that might break
the UV platform if done too early such as before necessary ACPI tables
parsing takes place.

Signed-off-by: Mike Travis 
Suggested-by: Hedi Berriche 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
---
 arch/x86/include/asm/uv/uv.h |6 ++
 1 file changed, 6 insertions(+)

--- linux.orig/arch/x86/include/asm/uv/uv.h
+++ linux/arch/x86/include/asm/uv/uv.h
@@ -10,8 +10,13 @@ struct cpumask;
 struct mm_struct;
 
 #ifdef CONFIG_X86_UV
+#include 
 
 extern enum uv_system_type get_uv_system_type(void);
+static inline bool is_early_uv_system(void)
+{
+   return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
+}
 extern int is_uv_system(void);
 extern int is_uv_hubless(void);
 extern void uv_cpu_init(void);
@@ -23,6 +28,7 @@ extern const struct cpumask *uv_flush_tl
 #else  /* X86_UV */
 
 static inline enum uv_system_type get_uv_system_type(void) { return UV_NONE; }
+static inline bool is_early_uv_system(void){ return 0; }
 static inline int is_uv_system(void)   { return 0; }
 static inline int is_uv_hubless(void)  { return 0; }
 static inline void uv_cpu_init(void)   { }

-- 

[PATCH 0/2] Fix TSC ADJUST breakage causing TSC failure

[Mike Travis]

Fix a breakage caused by enabling early tsc initialization which bypasses
a check that disables the forcing of TSC ADJUST to 0 for chassis 0.
This is common on systems where all the chassis start up asynchronously
so which chassis should have a TSC ADJUST value of 0 is not predictable.

The solution is to add a check earlier than this early tsc init to
disable the potential of it incorrectly adjusting TSC ADJUST values that
are already correctly initialized.

*  Patch 1 adds an early callable function (after efi_init) that will
   check if this system might be a UV system.

*  Patch 2 adds code to tsc_early_init() which disables adjusting the
   TSC ADJUST value if it's a UV system.  This allows the later tsc_init
   function to test the tsc_async_resets flag that indicates the system
   chassis start up asynchronously, so which chassis should have a TSC
   ADJUST value of 0 is not predictable.  Further references are in
   the patch.

-- 

[PATCH 1/2] x86/platform/uv: Add is_early_uv_system check

[Mike Travis]

Introduce is_early_uv_system() which uses efi.uv_systab to decide early
in the boot process whether we're on a UV system.

This is needed to skip other early setup/init code that might break
the UV platform if done too early such as before necessary ACPI tables
parsing takes place.

Signed-off-by: Mike Travis 
Suggested-by: Hedi Berriche 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
---
 arch/x86/include/asm/uv/uv.h |6 ++
 1 file changed, 6 insertions(+)

--- linux.orig/arch/x86/include/asm/uv/uv.h
+++ linux/arch/x86/include/asm/uv/uv.h
@@ -10,8 +10,13 @@ struct cpumask;
 struct mm_struct;
 
 #ifdef CONFIG_X86_UV
+#include 
 
 extern enum uv_system_type get_uv_system_type(void);
+static inline bool is_early_uv_system(void)
+{
+   return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
+}
 extern int is_uv_system(void);
 extern int is_uv_hubless(void);
 extern void uv_cpu_init(void);
@@ -23,6 +28,7 @@ extern const struct cpumask *uv_flush_tl
 #else  /* X86_UV */
 
 static inline enum uv_system_type get_uv_system_type(void) { return UV_NONE; }
+static inline bool is_early_uv_system(void){ return 0; }
 static inline int is_uv_system(void)   { return 0; }
 static inline int is_uv_hubless(void)  { return 0; }
 static inline void uv_cpu_init(void)   { }

-- 

Re: [PATCH 2/2] x86/tsc: Fix UV TSC initialization

[Mike Travis]

On 10/1/2018 11:22 PM, Thomas Gleixner wrote:

On Mon, 1 Oct 2018, Mike Travis wrote:


Fix regression introduced by

commit cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once")

as it changed setup_arch() so that it now calls tsc_early_init() before
acpi_boot_table_init() which is a necessary step, in the case of UV
systems, to inform tsc_sanitize_first_cpu() that we're on a platform
with async TSC resets as documented in

commit 341102c3ef29 ("x86/tsc: Add option that TSC on Socket 0 being non-zero is 
valid")

Fix by skipping tsc_early_init() on UV systems and let TSC initialization
take place later in tsc_init().

Fixes: cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once")
Signed-off-by: Mike Travis 
Signed-off-by: Hedi Berriche 


See previous mail.


Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
---
  arch/x86/kernel/setup.c |6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

--- linux.orig/arch/x86/kernel/setup.c
+++ linux/arch/x86/kernel/setup.c
@@ -117,6 +117,7 @@
  #include 
  #include 
  #include 
+#include 
  
  /*

   * max_low_pfn_mapped: highest direct mapped pfn under 4GB
@@ -1015,7 +1016,10 @@ void __init setup_arch(char **cmdline_p)
 */
init_hypervisor_platform();
  
-	tsc_early_init();

+   /* UV TSC multi-chassis synchronization already set, don't change it */
+   if (!is_early_uv_system())
+   tsc_early_init();


tsc_early_init() has already a check which makes it not invoke the
calibration code, so please put your uv check into that.


Will do, thanks.



Thanks,

tglx

Re: [PATCH 2/2] x86/tsc: Fix UV TSC initialization

[Mike Travis]

On 10/1/2018 11:22 PM, Thomas Gleixner wrote:

On Mon, 1 Oct 2018, Mike Travis wrote:


Fix regression introduced by

commit cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once")

as it changed setup_arch() so that it now calls tsc_early_init() before
acpi_boot_table_init() which is a necessary step, in the case of UV
systems, to inform tsc_sanitize_first_cpu() that we're on a platform
with async TSC resets as documented in

commit 341102c3ef29 ("x86/tsc: Add option that TSC on Socket 0 being non-zero is 
valid")

Fix by skipping tsc_early_init() on UV systems and let TSC initialization
take place later in tsc_init().

Fixes: cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once")
Signed-off-by: Mike Travis 
Signed-off-by: Hedi Berriche 


See previous mail.


Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
---
  arch/x86/kernel/setup.c |6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

--- linux.orig/arch/x86/kernel/setup.c
+++ linux/arch/x86/kernel/setup.c
@@ -117,6 +117,7 @@
  #include 
  #include 
  #include 
+#include 
  
  /*

   * max_low_pfn_mapped: highest direct mapped pfn under 4GB
@@ -1015,7 +1016,10 @@ void __init setup_arch(char **cmdline_p)
 */
init_hypervisor_platform();
  
-	tsc_early_init();

+   /* UV TSC multi-chassis synchronization already set, don't change it */
+   if (!is_early_uv_system())
+   tsc_early_init();


tsc_early_init() has already a check which makes it not invoke the
calibration code, so please put your uv check into that.


Will do, thanks.



Thanks,

tglx

Re: [PATCH 1/2] x86/platform/uv: Add is_early_uv_system check

[Mike Travis]

On 10/1/2018 11:20 PM, Thomas Gleixner wrote:

On Mon, 1 Oct 2018, Mike Travis wrote:


Introduce is_early_uv_system() which uses efi.uv_systab to decide early
in the boot process whether we're on a UV system.

This is needed to skip other early setup/init code that might break UV
platform if done too early such as before necessary ACPI tables parsing
takes place.

Signed-off-by: Mike Travis 
Signed-off-by: Hedi Berriche 


This SOB chain is wrong. I don't see how Hedi is involved in this. If this
wants to express that the patch was developed together please see
Documentation for the Co-developed-by tag.


Hedi suggested a "Suggested-by:" tag, would that suffice?



Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
---
  arch/x86/include/asm/uv/uv.h |6 ++
  1 file changed, 6 insertions(+)

--- linux.orig/arch/x86/include/asm/uv/uv.h
+++ linux/arch/x86/include/asm/uv/uv.h
@@ -10,8 +10,13 @@ struct cpumask;
  struct mm_struct;
  
  #ifdef CONFIG_X86_UV

+#include 
  
  extern enum uv_system_type get_uv_system_type(void);

+static inline int is_early_uv_system(void)


Can you please make this bool?


+{
+   return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
+}


Thanks,

tglx

Re: [PATCH 1/2] x86/platform/uv: Add is_early_uv_system check

[Mike Travis]

On 10/1/2018 11:20 PM, Thomas Gleixner wrote:

On Mon, 1 Oct 2018, Mike Travis wrote:


Introduce is_early_uv_system() which uses efi.uv_systab to decide early
in the boot process whether we're on a UV system.

This is needed to skip other early setup/init code that might break UV
platform if done too early such as before necessary ACPI tables parsing
takes place.

Signed-off-by: Mike Travis 
Signed-off-by: Hedi Berriche 


This SOB chain is wrong. I don't see how Hedi is involved in this. If this
wants to express that the patch was developed together please see
Documentation for the Co-developed-by tag.


Hedi suggested a "Suggested-by:" tag, would that suffice?



Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
---
  arch/x86/include/asm/uv/uv.h |6 ++
  1 file changed, 6 insertions(+)

--- linux.orig/arch/x86/include/asm/uv/uv.h
+++ linux/arch/x86/include/asm/uv/uv.h
@@ -10,8 +10,13 @@ struct cpumask;
  struct mm_struct;
  
  #ifdef CONFIG_X86_UV

+#include 
  
  extern enum uv_system_type get_uv_system_type(void);

+static inline int is_early_uv_system(void)


Can you please make this bool?


+{
+   return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
+}


Thanks,

tglx

[PATCH 0/2] Fix community TSC ADJUST breakage causing TSC failure

[Mike Travis]

Fix a breakage caused by enabling early tsc initialization which bypasses
a check that disables the forcing of TSC ADJUST to 0 for chassis 0.
This is common on systems where all the chassis start up asynchronously
so which chassis should have a TSC ADJUST value of 0 is not predictable.

The solution is to add a check earlier than this early tsc init to
disable the potential of it incorrectly adjusting TSC ADJUST values that
are already correctly initialized.

*  Patch 1 adds an early callable function (right after efi_init) that
   will check if this system might be a UV system.

*  Patch 2 adds code into setup_arch() which disables the call to
   tsc_early_init.  This function calls the TSC adjust initialization
   functions before UV setup has checked if BIOS has set the multi-chassis
   sync flags.  Further references are in the patch.

-- 

[PATCH 0/2] Fix community TSC ADJUST breakage causing TSC failure

[Mike Travis]

Fix a breakage caused by enabling early tsc initialization which bypasses
a check that disables the forcing of TSC ADJUST to 0 for chassis 0.
This is common on systems where all the chassis start up asynchronously
so which chassis should have a TSC ADJUST value of 0 is not predictable.

The solution is to add a check earlier than this early tsc init to
disable the potential of it incorrectly adjusting TSC ADJUST values that
are already correctly initialized.

*  Patch 1 adds an early callable function (right after efi_init) that
   will check if this system might be a UV system.

*  Patch 2 adds code into setup_arch() which disables the call to
   tsc_early_init.  This function calls the TSC adjust initialization
   functions before UV setup has checked if BIOS has set the multi-chassis
   sync flags.  Further references are in the patch.

-- 

[PATCH 2/2] x86/tsc: Fix UV TSC initialization

[Mike Travis]

Fix regression introduced by

commit cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once")

as it changed setup_arch() so that it now calls tsc_early_init() before
acpi_boot_table_init() which is a necessary step, in the case of UV
systems, to inform tsc_sanitize_first_cpu() that we're on a platform
with async TSC resets as documented in

commit 341102c3ef29 ("x86/tsc: Add option that TSC on Socket 0 being non-zero 
is valid")

Fix by skipping tsc_early_init() on UV systems and let TSC initialization
take place later in tsc_init().

Fixes: cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once") 
Signed-off-by: Mike Travis 
Signed-off-by: Hedi Berriche 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
---
 arch/x86/kernel/setup.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- linux.orig/arch/x86/kernel/setup.c
+++ linux/arch/x86/kernel/setup.c
@@ -117,6 +117,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * max_low_pfn_mapped: highest direct mapped pfn under 4GB
@@ -1015,7 +1016,10 @@ void __init setup_arch(char **cmdline_p)
 */
init_hypervisor_platform();
 
-   tsc_early_init();
+   /* UV TSC multi-chassis synchronization already set, don't change it */
+   if (!is_early_uv_system())
+   tsc_early_init();
+
x86_init.resources.probe_roms();
 
/* after parse_early_param, so could debug it */

-- 

[PATCH 1/2] x86/platform/uv: Add is_early_uv_system check

[Mike Travis]

Introduce is_early_uv_system() which uses efi.uv_systab to decide early
in the boot process whether we're on a UV system.

This is needed to skip other early setup/init code that might break UV
platform if done too early such as before necessary ACPI tables parsing
takes place.

Signed-off-by: Mike Travis 
Signed-off-by: Hedi Berriche 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
---
 arch/x86/include/asm/uv/uv.h |6 ++
 1 file changed, 6 insertions(+)

--- linux.orig/arch/x86/include/asm/uv/uv.h
+++ linux/arch/x86/include/asm/uv/uv.h
@@ -10,8 +10,13 @@ struct cpumask;
 struct mm_struct;
 
 #ifdef CONFIG_X86_UV
+#include 
 
 extern enum uv_system_type get_uv_system_type(void);
+static inline int is_early_uv_system(void)
+{
+   return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
+}
 extern int is_uv_system(void);
 extern int is_uv_hubless(void);
 extern void uv_cpu_init(void);
@@ -23,6 +28,7 @@ extern const struct cpumask *uv_flush_tl
 #else  /* X86_UV */
 
 static inline enum uv_system_type get_uv_system_type(void) { return UV_NONE; }
+static inline int is_early_uv_system(void) { return 0; }
 static inline int is_uv_system(void)   { return 0; }
 static inline int is_uv_hubless(void)  { return 0; }
 static inline void uv_cpu_init(void)   { }

-- 

[PATCH 2/2] x86/tsc: Fix UV TSC initialization

[Mike Travis]

Fix regression introduced by

commit cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once")

as it changed setup_arch() so that it now calls tsc_early_init() before
acpi_boot_table_init() which is a necessary step, in the case of UV
systems, to inform tsc_sanitize_first_cpu() that we're on a platform
with async TSC resets as documented in

commit 341102c3ef29 ("x86/tsc: Add option that TSC on Socket 0 being non-zero 
is valid")

Fix by skipping tsc_early_init() on UV systems and let TSC initialization
take place later in tsc_init().

Fixes: cf7a63ef4e02 ("x86/tsc: Calibrate tsc only once") 
Signed-off-by: Mike Travis 
Signed-off-by: Hedi Berriche 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
---
 arch/x86/kernel/setup.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- linux.orig/arch/x86/kernel/setup.c
+++ linux/arch/x86/kernel/setup.c
@@ -117,6 +117,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * max_low_pfn_mapped: highest direct mapped pfn under 4GB
@@ -1015,7 +1016,10 @@ void __init setup_arch(char **cmdline_p)
 */
init_hypervisor_platform();
 
-   tsc_early_init();
+   /* UV TSC multi-chassis synchronization already set, don't change it */
+   if (!is_early_uv_system())
+   tsc_early_init();
+
x86_init.resources.probe_roms();
 
/* after parse_early_param, so could debug it */

-- 

[PATCH 1/2] x86/platform/uv: Add is_early_uv_system check

[Mike Travis]

Introduce is_early_uv_system() which uses efi.uv_systab to decide early
in the boot process whether we're on a UV system.

This is needed to skip other early setup/init code that might break UV
platform if done too early such as before necessary ACPI tables parsing
takes place.

Signed-off-by: Mike Travis 
Signed-off-by: Hedi Berriche 
Reviewed-by: Russ Anderson 
Reviewed-by: Dimitri Sivanich 
---
 arch/x86/include/asm/uv/uv.h |6 ++
 1 file changed, 6 insertions(+)

--- linux.orig/arch/x86/include/asm/uv/uv.h
+++ linux/arch/x86/include/asm/uv/uv.h
@@ -10,8 +10,13 @@ struct cpumask;
 struct mm_struct;
 
 #ifdef CONFIG_X86_UV
+#include 
 
 extern enum uv_system_type get_uv_system_type(void);
+static inline int is_early_uv_system(void)
+{
+   return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
+}
 extern int is_uv_system(void);
 extern int is_uv_hubless(void);
 extern void uv_cpu_init(void);
@@ -23,6 +28,7 @@ extern const struct cpumask *uv_flush_tl
 #else  /* X86_UV */
 
 static inline enum uv_system_type get_uv_system_type(void) { return UV_NONE; }
+static inline int is_early_uv_system(void) { return 0; }
 static inline int is_uv_system(void)   { return 0; }
 static inline int is_uv_hubless(void)  { return 0; }
 static inline void uv_cpu_init(void)   { }

-- 

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

[Mike Travis]

On 5/17/2018 8:06 AM, Ramsay, Frank wrote:




-Original Message-
From: Baoquan He [mailto:b...@redhat.com]
Sent: Wednesday, May 16, 2018 11:18 PM
To: Travis, Mike <mike.tra...@hpe.com>; Anderson, Russ
<russ.ander...@hpe.com>; Ramsay, Frank <frank.ram...@hpe.com>
Cc: Ingo Molnar <mi...@kernel.org>; linux-kernel@vger.kernel.org;
x...@kernel.org; mi...@redhat.com; t...@linutronix.de; h...@zytor.com;
thgar...@google.com; keesc...@chromium.org; akpm@linux-
foundation.org; yamada.masah...@socionext.com; Sivanich, Dimitri
<dimitri.sivan...@hpe.com>; dyo...@redhat.com
Subject: Re: [PATCH v2 RESEND 2/2] x86/mm/KASLR: Do not adapt the size of
the direct mapping section for SGI UV system

Hi Mike, Russ and Frank,

On 09/28/17 at 07:10am, Mike Travis wrote:



On 9/28/2017 2:01 AM, Ingo Molnar wrote:


* Baoquan He <b...@redhat.com> wrote:


@@ -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())
kaslr_regions[0].size_tb = memory_tb;

This is really an ugly hack. Is kaslr_regions[] incorrect? If so
then it should be corrected instead of uglifying the code that uses it...


Thanks for looking into this!

If on SGI UV system, the kaslr_regions[0].size_tb, namely the size
of the direct mapping section, is incorrect.

Its direct mapping size includes two parts:
#1 RAM size of system
#2 MMIOH region size which only SGI UV system has.

However, the #2 can only be got till uv_system_init() is called in
native_smp_prepare_cpus(). That is too late for mm KASLR calculation.
That's why I made this hack.

I checked uv_system_init() code, seems not easy to know the size
of MMIOH region before or inside kernel_randomize_memory(). I have
CCed UV devel experts, not sure if they have any idea about this.
Otherwise, this patch could be the only way I can think of.

Hi Mike and Russ,

Is there any chance we can get the size of MMIOH region before mm
KASLR code, namely before we call kernel_randomize_memory()?


The sizes of the MMIOL and MMIOH areas are tied into the HUB design
and how it is communicated to BIOS and the kernel.  This is via some
of the config MMR's found in the HUB and it would be impossible to
provide any access to these registers as they change with each new UV

architecture.


The kernel does reserve the memory in the EFI memmap.  I can send you
a console log of the full startup that includes the MMIOH
reservations. Note that it is dependent on what I/O devices are
actually present as UV does not map empty slots unless forced (because
we'd quickly run out of resources.) Also, the EFI memmap entries do
not specify the exact usage of the contained areas.


This one is still a regression bug in our newer rhel since I just fixed them 
with
rhel-only patch. Now I still need the console log which includes the MMIOH
reservations.



Does the system need to have an external IO device for this?  If not you should 
just be able to boot one of the SGI UV systems in the beaker lab (possibly also 
the HPE Superdome Flex that is in beaker; hpe-flex-01.rhts.eng.bos.redhat.com)


If you have a hawks2 (UV4), you would have 4 10G ethernet devices on the 
base I/O.  But these would only have smaller MMIOH0 regions.  This would 
not cause MMIOH1 regions to be allocated and assigned.  (MC990X/UV3 only 
has a single sized MMIOH regions where they are all big enough for the 
largest MMIOH region found on any I/O device.)





Could you help provide a console log with MMIOH info, or I need request
one from redhat's lab?

Or expert from HPE UV team can make a patch based on the finding and
analysis?

Thanks
Baoquan




I don't mind system specific quirks to hardware enumeration details,
as long as they don't pollute generic code with such special hacks.

I.e. in this case it's wrong to allow kaslr_regions[0].size_tb to be
wrong. Any other code that relies on it in the future will be wrong as well

on UV systems.


Which may come into play on other arches with the new upcoming

memory

technologies.


The right quirk would be to fix that up where it gets introduced, or
something like that.


Yes, does make sense.


Thanks,

Ingo

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

[Mike Travis]

On 5/17/2018 8:06 AM, Ramsay, Frank wrote:




-Original Message-
From: Baoquan He [mailto:b...@redhat.com]
Sent: Wednesday, May 16, 2018 11:18 PM
To: Travis, Mike ; Anderson, Russ
; Ramsay, Frank 
Cc: Ingo Molnar ; linux-kernel@vger.kernel.org;
x...@kernel.org; mi...@redhat.com; t...@linutronix.de; h...@zytor.com;
thgar...@google.com; keesc...@chromium.org; akpm@linux-
foundation.org; yamada.masah...@socionext.com; Sivanich, Dimitri
; dyo...@redhat.com
Subject: Re: [PATCH v2 RESEND 2/2] x86/mm/KASLR: Do not adapt the size of
the direct mapping section for SGI UV system

Hi Mike, Russ and Frank,

On 09/28/17 at 07:10am, Mike Travis wrote:



On 9/28/2017 2:01 AM, Ingo Molnar wrote:


* Baoquan He  wrote:


@@ -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())
kaslr_regions[0].size_tb = memory_tb;

This is really an ugly hack. Is kaslr_regions[] incorrect? If so
then it should be corrected instead of uglifying the code that uses it...


Thanks for looking into this!

If on SGI UV system, the kaslr_regions[0].size_tb, namely the size
of the direct mapping section, is incorrect.

Its direct mapping size includes two parts:
#1 RAM size of system
#2 MMIOH region size which only SGI UV system has.

However, the #2 can only be got till uv_system_init() is called in
native_smp_prepare_cpus(). That is too late for mm KASLR calculation.
That's why I made this hack.

I checked uv_system_init() code, seems not easy to know the size
of MMIOH region before or inside kernel_randomize_memory(). I have
CCed UV devel experts, not sure if they have any idea about this.
Otherwise, this patch could be the only way I can think of.

Hi Mike and Russ,

Is there any chance we can get the size of MMIOH region before mm
KASLR code, namely before we call kernel_randomize_memory()?


The sizes of the MMIOL and MMIOH areas are tied into the HUB design
and how it is communicated to BIOS and the kernel.  This is via some
of the config MMR's found in the HUB and it would be impossible to
provide any access to these registers as they change with each new UV

architecture.


The kernel does reserve the memory in the EFI memmap.  I can send you
a console log of the full startup that includes the MMIOH
reservations. Note that it is dependent on what I/O devices are
actually present as UV does not map empty slots unless forced (because
we'd quickly run out of resources.) Also, the EFI memmap entries do
not specify the exact usage of the contained areas.


This one is still a regression bug in our newer rhel since I just fixed them 
with
rhel-only patch. Now I still need the console log which includes the MMIOH
reservations.



Does the system need to have an external IO device for this?  If not you should 
just be able to boot one of the SGI UV systems in the beaker lab (possibly also 
the HPE Superdome Flex that is in beaker; hpe-flex-01.rhts.eng.bos.redhat.com)


If you have a hawks2 (UV4), you would have 4 10G ethernet devices on the 
base I/O.  But these would only have smaller MMIOH0 regions.  This would 
not cause MMIOH1 regions to be allocated and assigned.  (MC990X/UV3 only 
has a single sized MMIOH regions where they are all big enough for the 
largest MMIOH region found on any I/O device.)





Could you help provide a console log with MMIOH info, or I need request
one from redhat's lab?

Or expert from HPE UV team can make a patch based on the finding and
analysis?

Thanks
Baoquan




I don't mind system specific quirks to hardware enumeration details,
as long as they don't pollute generic code with such special hacks.

I.e. in this case it's wrong to allow kaslr_regions[0].size_tb to be
wrong. Any other code that relies on it in the future will be wrong as well

on UV systems.


Which may come into play on other arches with the new upcoming

memory

technologies.


The right quirk would be to fix that up where it gets introduced, or
something like that.


Yes, does make sense.


Thanks,

Ingo

Re: [PATCH 0/3] x86/platform/UV: Update Memory Block Size Setting

[Mike Travis]

[re-including everyone for any other comments about these patches...]

On 5/10/2018 11:48 PM, Michal Hocko wrote:

On Thu 10-05-18 18:18:32, mike.tra...@hpe.com wrote:


Update support for the UV kernel to accommodate Intel BIOS changes in
NVDIMM alignment, which caused UV BIOS to align the memory boundaries
on different blocks than the previous UV standard of 2GB.


Please elaborate (much) more. What is the actual problem and how is the
patchset addressing it.



On 5/15/2018 1:55 AM, Michal Hocko wrote:
> On Fri 11-05-18 08:08:14, Mike Travis wrote:
> [...]
>> If you think I need this more detailed explanation in the patch 
descriptions

>> themselves, I'll add it.
>
> Yes we definitely want this information along with a high level
> description of how this got fixed. Incomplete memblocks need to be
> handled gracefully (especially when blocks are 2GB in size).
>
> Thanks!
>

Hi Michal,

I will add more info but this patch does not address anything about 
incomplete memblocks.  They have existed in 2GB mem block size form 
since 2009 (v2.6) with the first UV1 system release.  I am not changing 
any of that handling.


The fixing part was to adapt to what Intel BIOS was using as a different 
boundary to align the PMEM NVDIMMs.  This is explained in both patch 1 
and patch 2:


"Add a new function to "adjust" the current fixed UV memory block size 
of 2GB so it can be changed to a different physical boundary.  This is 
out of necessity so UV BIOS can accommodate Intel BIOS changes for 
NVDIMM's, which can align these new PMEM modules at other than 2GB 
boundaries."


"Add a call to the new function to "adjust" the current fixed UV memory 
block size of 2GB so it can be changed to a different physical boundary. 
This accommodates changes in the Intel BIOS, and therefore UV BIOS, 
which now can align boundaries different than the previous UV standard 
of 2GB. It also flags any UV Mem boundaries that cause a change in the 
mem block size boundary."


I can't explain why the Intel BIOS changed the boundaries, it probably 
has something to do with accommodating other areas of the NVDIMMs 
physical address space.  This caused a boundary alignment to be less 
than 2GB which UV had been using.  From one of the UV BIOS engineers I 
found out that Intel really only guarantees a 64MB boundary (which is 
actually less than the current Linux minimum of 128MB.)  Our own UVHUB 
requirements dictated that 2GB was an acceptable boundary up until now.


So let me know how much more info is needed on how I need to explain 
_this_ change.


Thanks,
Mike

Re: [PATCH 0/3] x86/platform/UV: Update Memory Block Size Setting

[Mike Travis]

[re-including everyone for any other comments about these patches...]

On 5/10/2018 11:48 PM, Michal Hocko wrote:

On Thu 10-05-18 18:18:32, mike.tra...@hpe.com wrote:


Update support for the UV kernel to accommodate Intel BIOS changes in
NVDIMM alignment, which caused UV BIOS to align the memory boundaries
on different blocks than the previous UV standard of 2GB.


Please elaborate (much) more. What is the actual problem and how is the
patchset addressing it.



On 5/15/2018 1:55 AM, Michal Hocko wrote:
> On Fri 11-05-18 08:08:14, Mike Travis wrote:
> [...]
>> If you think I need this more detailed explanation in the patch 
descriptions

>> themselves, I'll add it.
>
> Yes we definitely want this information along with a high level
> description of how this got fixed. Incomplete memblocks need to be
> handled gracefully (especially when blocks are 2GB in size).
>
> Thanks!
>

Hi Michal,

I will add more info but this patch does not address anything about 
incomplete memblocks.  They have existed in 2GB mem block size form 
since 2009 (v2.6) with the first UV1 system release.  I am not changing 
any of that handling.


The fixing part was to adapt to what Intel BIOS was using as a different 
boundary to align the PMEM NVDIMMs.  This is explained in both patch 1 
and patch 2:


"Add a new function to "adjust" the current fixed UV memory block size 
of 2GB so it can be changed to a different physical boundary.  This is 
out of necessity so UV BIOS can accommodate Intel BIOS changes for 
NVDIMM's, which can align these new PMEM modules at other than 2GB 
boundaries."


"Add a call to the new function to "adjust" the current fixed UV memory 
block size of 2GB so it can be changed to a different physical boundary. 
This accommodates changes in the Intel BIOS, and therefore UV BIOS, 
which now can align boundaries different than the previous UV standard 
of 2GB. It also flags any UV Mem boundaries that cause a change in the 
mem block size boundary."


I can't explain why the Intel BIOS changed the boundaries, it probably 
has something to do with accommodating other areas of the NVDIMMs 
physical address space.  This caused a boundary alignment to be less 
than 2GB which UV had been using.  From one of the UV BIOS engineers I 
found out that Intel really only guarantees a 64MB boundary (which is 
actually less than the current Linux minimum of 128MB.)  Our own UVHUB 
requirements dictated that 2GB was an acceptable boundary up until now.


So let me know how much more info is needed on how I need to explain 
_this_ change.


Thanks,
Mike

Re: [PATCH 1/1] x86/platform/UV: Fix critical UV MMR address error

[Mike Travis]

On 3/28/2018 11:17 AM, Thomas Gleixner wrote:

On Wed, 28 Mar 2018, mike.tra...@hpe.com wrote:


A critical error was found testing the fixed UV4 HUB in that an MMR
address was found to be incorrect.  This causes the virtual address
space for accessing the MMIOH1 region to be allocated with the
incorrect size.


Even if this is not intended for stable, despite the diff


Yes, I realized I missed 'stable' a moment or two after hitting send.



--- linux-4.4.orig/arch/x86/include/asm/uv/uv_mmrs.h
+++ linux-4.4/arch/x86/include/asm/uv/uv_mmrs.h


suggesting that this is against a kernel, which receives respiration
treatment, it would be appreciated if you could add a Fixes tag next time.


Sorry I didn't know about that.  Here it is:

Commit-ID:  673aa20c55a138621d1340d343cd6b07c1cb4e92
Gitweb: 
https://.kernel.org/tip/673aa20c55a13862git1d1340d343cd6b07c1cb4e92

Author: Mike Travis <mike.tra...@hpe.com>
AuthorDate: Mon, 8 Jan 2018 13:39:59 -0600
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Tue, 16 Jan 2018 03:58:36 +0100

x86/platform/UV: Update uv_mmrs.h to prepare for UV4A fixes

Regenerate uv_mmrs.h file to accommodate fixes to UV4A MMRs.


That spares me the time to figure out which commit introduced the wreckage
and therefore the scope of the fix. Added it myself.


Oh, well the above should be the same as what you found.


Thanks,

tglx


Thank You!



@@ -3833,7 +3833,7 @@ union uvh_rh_gam_mmioh_overlay_config0_m
  #define UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
  #define UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
  #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1603000UL
-#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x483000UL
+#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x484000UL
  #define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR (
\
is_uv1_hub() ? UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR :  \
is_uv2_hub() ? UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR :  \

--

Re: [PATCH 1/1] x86/platform/UV: Fix critical UV MMR address error

[Mike Travis]

On 3/28/2018 11:17 AM, Thomas Gleixner wrote:

On Wed, 28 Mar 2018, mike.tra...@hpe.com wrote:


A critical error was found testing the fixed UV4 HUB in that an MMR
address was found to be incorrect.  This causes the virtual address
space for accessing the MMIOH1 region to be allocated with the
incorrect size.


Even if this is not intended for stable, despite the diff


Yes, I realized I missed 'stable' a moment or two after hitting send.



--- linux-4.4.orig/arch/x86/include/asm/uv/uv_mmrs.h
+++ linux-4.4/arch/x86/include/asm/uv/uv_mmrs.h


suggesting that this is against a kernel, which receives respiration
treatment, it would be appreciated if you could add a Fixes tag next time.


Sorry I didn't know about that.  Here it is:

Commit-ID:  673aa20c55a138621d1340d343cd6b07c1cb4e92
Gitweb: 
https://.kernel.org/tip/673aa20c55a13862git1d1340d343cd6b07c1cb4e92

Author: Mike Travis 
AuthorDate: Mon, 8 Jan 2018 13:39:59 -0600
Committer:  Ingo Molnar 
CommitDate: Tue, 16 Jan 2018 03:58:36 +0100

x86/platform/UV: Update uv_mmrs.h to prepare for UV4A fixes

Regenerate uv_mmrs.h file to accommodate fixes to UV4A MMRs.


That spares me the time to figure out which commit introduced the wreckage
and therefore the scope of the fix. Added it myself.


Oh, well the above should be the same as what you found.


Thanks,

tglx


Thank You!



@@ -3833,7 +3833,7 @@ union uvh_rh_gam_mmioh_overlay_config0_m
  #define UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
  #define UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
  #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1603000UL
-#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x483000UL
+#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x484000UL
  #define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR (
\
is_uv1_hub() ? UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR :  \
is_uv2_hub() ? UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR :  \

--

[tip:x86/platform] x86/platform/UV: Fix UV4A BAU MMRs

[tip-bot for Mike Travis]

Commit-ID:  a631a0a7a3caf6a9924856f3dcfe256e747f7467
Gitweb: https://git.kernel.org/tip/a631a0a7a3caf6a9924856f3dcfe256e747f7467
Author: Mike Travis <mike.tra...@hpe.com>
AuthorDate: Mon, 8 Jan 2018 13:40:04 -0600
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Tue, 16 Jan 2018 03:58:38 +0100

x86/platform/UV: Fix UV4A BAU MMRs

Fixes to accommodate Intel Processor changes for UV4A broadcast assist unit
(BAU) MMRs.

Signed-off-by: Mike Travis <mike.tra...@hpe.com>
Acked-by: Andrew Banman <aban...@hpe.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Dimitri Sivanich <sivan...@hpe.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Russ Anderson <r...@hpe.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Link: 
http://lkml.kernel.org/r/1515440405-20880-7-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 arch/x86/include/asm/uv/uv_mmrs.h | 59 +--
 1 file changed, 38 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index 30db549..ecb9dde 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -39,9 +39,11 @@
  * #define UV2Hxxx b
  * #define UV3Hxxx c
  * #define UV4Hxxx d
+ * #define UV4AHxxx e
  * #define UVHxxx  (is_uv1_hub() ? UV1Hxxx :
  * (is_uv2_hub() ? UV2Hxxx :
  * (is_uv3_hub() ? UV3Hxxx :
+ * (is_uv4a_hub() ? UV4AHxxx :
  * UV4Hxxx))
  *
  * If the MMR exists on all hub types > 1 but have different addresses, the
@@ -49,8 +51,10 @@
  * #define UV2Hxxx b
  * #define UV3Hxxx c
  * #define UV4Hxxx d
+ * #define UV4AHxxx e
  * #define UVHxxx  (is_uv2_hub() ? UV2Hxxx :
  * (is_uv3_hub() ? UV3Hxxx :
+ * (is_uv4a_hub() ? UV4AHxxx :
  * UV4Hxxx))
  *
  * union uvh_xxx {
@@ -63,6 +67,7 @@
  * } s2;
  * struct uv3h_xxx_s {  # Full UV3 definition (*)
  * } s3;
+ * (NOTE: No struct uv4ah_xxx_s members exist)
  * struct uv4h_xxx_s {  # Full UV4 definition (*)
  * } s4;
  * };
@@ -2780,35 +2785,47 @@ union uvh_lb_bau_sb_activation_status_1_u {
/*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_32)
 
 #define UVH_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_SHFT12
-#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT 49
-#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK 0x7ffeUL
 
+#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
-
+#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
+#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
+#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x3000UL
-
-
-union uvh_lb_bau_sb_descriptor_base_u {
-   unsigned long   v;
-   struct uvh_lb_bau_sb_descriptor_base_s {
-   unsigned long   rsvd_0_11:12;
-   unsigned long   rsvd_12_48:37;
-   unsigned long   node_id:14; /* RW */
-   unsigned long   rsvd_63:1;
-   } s;
-   struct uv4h_lb_bau_sb_descriptor_base_s {
-   unsigned long   rsvd_0_11:12;
-   unsigned long   page_address:34;/* RW */
-   unsigned long   rsvd_46_48:3;
-   unsigned long   node_id:14; /* RW */
-   unsigned long   rsvd_63:1;
-   } s4;
-};
+#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
+
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT   53
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x000ff000UL
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK   0xffe0UL
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :  \
+   /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT)
+
+#define UVH_LB_BAU_SB_

[tip:x86/platform] x86/platform/UV: Fix UV4A BAU MMRs

[tip-bot for Mike Travis]

Commit-ID:  a631a0a7a3caf6a9924856f3dcfe256e747f7467
Gitweb: https://git.kernel.org/tip/a631a0a7a3caf6a9924856f3dcfe256e747f7467
Author: Mike Travis 
AuthorDate: Mon, 8 Jan 2018 13:40:04 -0600
Committer:  Ingo Molnar 
CommitDate: Tue, 16 Jan 2018 03:58:38 +0100

x86/platform/UV: Fix UV4A BAU MMRs

Fixes to accommodate Intel Processor changes for UV4A broadcast assist unit
(BAU) MMRs.

Signed-off-by: Mike Travis 
Acked-by: Andrew Banman 
Cc: Andrew Morton 
Cc: Dimitri Sivanich 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Russ Anderson 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1515440405-20880-7-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/uv/uv_mmrs.h | 59 +--
 1 file changed, 38 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index 30db549..ecb9dde 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -39,9 +39,11 @@
  * #define UV2Hxxx b
  * #define UV3Hxxx c
  * #define UV4Hxxx d
+ * #define UV4AHxxx e
  * #define UVHxxx  (is_uv1_hub() ? UV1Hxxx :
  * (is_uv2_hub() ? UV2Hxxx :
  * (is_uv3_hub() ? UV3Hxxx :
+ * (is_uv4a_hub() ? UV4AHxxx :
  * UV4Hxxx))
  *
  * If the MMR exists on all hub types > 1 but have different addresses, the
@@ -49,8 +51,10 @@
  * #define UV2Hxxx b
  * #define UV3Hxxx c
  * #define UV4Hxxx d
+ * #define UV4AHxxx e
  * #define UVHxxx  (is_uv2_hub() ? UV2Hxxx :
  * (is_uv3_hub() ? UV3Hxxx :
+ * (is_uv4a_hub() ? UV4AHxxx :
  * UV4Hxxx))
  *
  * union uvh_xxx {
@@ -63,6 +67,7 @@
  * } s2;
  * struct uv3h_xxx_s {  # Full UV3 definition (*)
  * } s3;
+ * (NOTE: No struct uv4ah_xxx_s members exist)
  * struct uv4h_xxx_s {  # Full UV4 definition (*)
  * } s4;
  * };
@@ -2780,35 +2785,47 @@ union uvh_lb_bau_sb_activation_status_1_u {
/*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_32)
 
 #define UVH_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_SHFT12
-#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT 49
-#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK 0x7ffeUL
 
+#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
-
+#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
+#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
+#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x3000UL
-
-
-union uvh_lb_bau_sb_descriptor_base_u {
-   unsigned long   v;
-   struct uvh_lb_bau_sb_descriptor_base_s {
-   unsigned long   rsvd_0_11:12;
-   unsigned long   rsvd_12_48:37;
-   unsigned long   node_id:14; /* RW */
-   unsigned long   rsvd_63:1;
-   } s;
-   struct uv4h_lb_bau_sb_descriptor_base_s {
-   unsigned long   rsvd_0_11:12;
-   unsigned long   page_address:34;/* RW */
-   unsigned long   rsvd_46_48:3;
-   unsigned long   node_id:14; /* RW */
-   unsigned long   rsvd_63:1;
-   } s4;
-};
+#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
+
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT   53
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x000ff000UL
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK   0xffe0UL
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :  \
+   /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT)
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv4a_

[tip:x86/platform] x86/platform/UV: Fix GAM MMR references in the UV x2apic code

[tip-bot for Mike Travis]

Commit-ID:  09c3ae12b2bf6dc2837d89c1017bf151af610a1f
Gitweb: https://git.kernel.org/tip/09c3ae12b2bf6dc2837d89c1017bf151af610a1f
Author: Mike Travis <mike.tra...@hpe.com>
AuthorDate: Mon, 8 Jan 2018 13:40:03 -0600
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Tue, 16 Jan 2018 03:58:37 +0100

x86/platform/UV: Fix GAM MMR references in the UV x2apic code

Along with the fixes in UV4A (rev2) MMRs, the code to access those
MMRs also was modified by the fixes.  UV3, UV4, and UV4A no longer
have compatible setups for Global Address Memory (GAM).

Correct the new mistakes.

Signed-off-by: Mike Travis <mike.tra...@hpe.com>
Acked-by: Andrew Banman <aban...@hpe.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Dimitri Sivanich <sivan...@hpe.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Russ Anderson <r...@hpe.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Link: 
http://lkml.kernel.org/r/1515440405-20880-6-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 83 +-
 1 file changed, 37 insertions(+), 46 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 2ddc140..46b675a 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -794,70 +794,61 @@ static __init void map_mmr_high(int max_pnode)
pr_info("UV: MMR disabled\n");
 }
 
-/*
- * This commonality works because both 0 & 1 versions of the MMIOH OVERLAY
- * and REDIRECT MMR regs are exactly the same on UV3.
- */
-struct mmioh_config {
-   unsigned long overlay;
-   unsigned long redirect;
-   char *id;
-};
-
-static __initdata struct mmioh_config mmiohs[] = {
-   {
-   UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR,
-   UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR,
-   "MMIOH0"
-   },
-   {
-   UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR,
-   UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR,
-   "MMIOH1"
-   },
-};
-
-/* UV3 & UV4 have identical MMIOH overlay configs */
-static __init void map_mmioh_high_uv3(int index, int min_pnode, int max_pnode)
+/* UV3/4 have identical MMIOH overlay configs, UV4A is slightly different */
+static __init void map_mmioh_high_uv34(int index, int min_pnode, int max_pnode)
 {
-   union uvh_rh_gam_mmioh_overlay_config0_mmr_u overlay;
+   unsigned long overlay;
unsigned long mmr;
unsigned long base;
+   unsigned long nasid_mask;
unsigned long m_overlay;
int i, n, shift, m_io, max_io;
int nasid, lnasid, fi, li;
char *id;
 
-   id = mmiohs[index].id;
-   overlay.v = uv_read_local_mmr(mmiohs[index].overlay);
-   m_overlay = mmiohs[index].overlay;
-
-   pr_info("UV: %s overlay 0x%lx(@0x%lx) base:0x%x m_io:%d\n",
-   id, overlay.v, m_overlay, overlay.s3.base, overlay.s3.m_io);
-   if (!overlay.s3.enable) {
+   if (index == 0) {
+   id = "MMIOH0";
+   m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR;
+   overlay = uv_read_local_mmr(m_overlay);
+   base = overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK;
+   mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR;
+   m_io = (overlay & 
UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK)
+   >> UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
+   shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
+   n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
+   nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_NASID_MASK;
+   } else {
+   id = "MMIOH1";
+   m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR;
+   overlay = uv_read_local_mmr(m_overlay);
+   base = overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_MASK;
+   mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR;
+   m_io = (overlay & 
UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK)
+   >> UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT;
+   shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT;
+   n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR_DEPTH;
+   nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR_NASID_MASK;
+   }
+   pr_info("UV: %s overlay 0x%lx base:0x%lx m_io:%d\n", id, overlay, base, 
m_io);
+   if (!(overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK)) {
pr_info("UV: %s disabled\n", id);
return;
}
 
-   shift = UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_SHFT;
-   base = (unsigned long)overlay.

[tip:x86/platform] x86/platform/UV: Fix GAM MMR references in the UV x2apic code

[tip-bot for Mike Travis]

Commit-ID:  09c3ae12b2bf6dc2837d89c1017bf151af610a1f
Gitweb: https://git.kernel.org/tip/09c3ae12b2bf6dc2837d89c1017bf151af610a1f
Author: Mike Travis 
AuthorDate: Mon, 8 Jan 2018 13:40:03 -0600
Committer:  Ingo Molnar 
CommitDate: Tue, 16 Jan 2018 03:58:37 +0100

x86/platform/UV: Fix GAM MMR references in the UV x2apic code

Along with the fixes in UV4A (rev2) MMRs, the code to access those
MMRs also was modified by the fixes.  UV3, UV4, and UV4A no longer
have compatible setups for Global Address Memory (GAM).

Correct the new mistakes.

Signed-off-by: Mike Travis 
Acked-by: Andrew Banman 
Cc: Andrew Morton 
Cc: Dimitri Sivanich 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Russ Anderson 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1515440405-20880-6-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 83 +-
 1 file changed, 37 insertions(+), 46 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 2ddc140..46b675a 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -794,70 +794,61 @@ static __init void map_mmr_high(int max_pnode)
pr_info("UV: MMR disabled\n");
 }
 
-/*
- * This commonality works because both 0 & 1 versions of the MMIOH OVERLAY
- * and REDIRECT MMR regs are exactly the same on UV3.
- */
-struct mmioh_config {
-   unsigned long overlay;
-   unsigned long redirect;
-   char *id;
-};
-
-static __initdata struct mmioh_config mmiohs[] = {
-   {
-   UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR,
-   UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR,
-   "MMIOH0"
-   },
-   {
-   UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR,
-   UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR,
-   "MMIOH1"
-   },
-};
-
-/* UV3 & UV4 have identical MMIOH overlay configs */
-static __init void map_mmioh_high_uv3(int index, int min_pnode, int max_pnode)
+/* UV3/4 have identical MMIOH overlay configs, UV4A is slightly different */
+static __init void map_mmioh_high_uv34(int index, int min_pnode, int max_pnode)
 {
-   union uvh_rh_gam_mmioh_overlay_config0_mmr_u overlay;
+   unsigned long overlay;
unsigned long mmr;
unsigned long base;
+   unsigned long nasid_mask;
unsigned long m_overlay;
int i, n, shift, m_io, max_io;
int nasid, lnasid, fi, li;
char *id;
 
-   id = mmiohs[index].id;
-   overlay.v = uv_read_local_mmr(mmiohs[index].overlay);
-   m_overlay = mmiohs[index].overlay;
-
-   pr_info("UV: %s overlay 0x%lx(@0x%lx) base:0x%x m_io:%d\n",
-   id, overlay.v, m_overlay, overlay.s3.base, overlay.s3.m_io);
-   if (!overlay.s3.enable) {
+   if (index == 0) {
+   id = "MMIOH0";
+   m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR;
+   overlay = uv_read_local_mmr(m_overlay);
+   base = overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK;
+   mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR;
+   m_io = (overlay & 
UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK)
+   >> UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
+   shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
+   n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
+   nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_NASID_MASK;
+   } else {
+   id = "MMIOH1";
+   m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR;
+   overlay = uv_read_local_mmr(m_overlay);
+   base = overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_MASK;
+   mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR;
+   m_io = (overlay & 
UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK)
+   >> UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT;
+   shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT;
+   n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR_DEPTH;
+   nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR_NASID_MASK;
+   }
+   pr_info("UV: %s overlay 0x%lx base:0x%lx m_io:%d\n", id, overlay, base, 
m_io);
+   if (!(overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK)) {
pr_info("UV: %s disabled\n", id);
return;
}
 
-   shift = UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_SHFT;
-   base = (unsigned long)overlay.s3.base;
-   m_io = overlay.s3.m_io;
-   mmr = mmiohs[index].redirect;
-   n = UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
/* Convert to NASID: */
min_pnode *= 2;
max_pnode *= 2;
max_io = lnasid = fi = li = -1;
 
for (i = 0; i < n; i+

[tip:x86/platform] x86/platform/UV: Fix GAM MMR changes in UV4A

[tip-bot for Mike Travis]

Commit-ID:  ecce47e0bde6faa3256740280754bfd06a1a4efa
Gitweb: https://git.kernel.org/tip/ecce47e0bde6faa3256740280754bfd06a1a4efa
Author: Mike Travis <mike.tra...@hpe.com>
AuthorDate: Mon, 8 Jan 2018 13:40:02 -0600
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Tue, 16 Jan 2018 03:58:37 +0100

x86/platform/UV: Fix GAM MMR changes in UV4A

Intel processor changes necessitated UV4 HUB Global Address Memory
(GAM) fixes to accommodate support for those processors.  This patch
deals with the updated address range change from 46 to 52 bits in UV4A.

Signed-off-by: Mike Travis <mike.tra...@hpe.com>
Acked-by: Andrew Banman <aban...@hpe.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Dimitri Sivanich <sivan...@hpe.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Russ Anderson <r...@hpe.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Link: 
http://lkml.kernel.org/r/1515440405-20880-5-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 arch/x86/include/asm/uv/uv_mmrs.h | 86 ---
 1 file changed, 80 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index b3afccc..30db549 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -3743,7 +3743,6 @@ union uvh_rh_gam_gru_overlay_config_mmr_u {
/*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR)
 
 
-
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_SHFT26
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT46
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_SHFT 63
@@ -3758,6 +3757,30 @@ union uvh_rh_gam_gru_overlay_config_mmr_u {
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK
0x000fc000UL
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK 0x8000UL
 
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT 52
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK 0x000ffc00UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK 0x03f0UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK 0x8000UL
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK ( \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK)
 
 union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
unsigned long   v;
@@ -3777,6 +3800,14 @@ union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
unsigned long   rsvd_56_62:7;
unsigned long   enable:1;   /* RW */
} s4;
+   struct uv4ah_rh_gam_mmioh_overlay_config0_mmr_s {
+   unsigned long   rsvd_0_25:26;
+   unsigned long   base:26;/* RW */
+   unsigned long   m_io:6; /* RW */
+   unsigned long   n_io:4;
+   unsigned long   undef_62:1; /* Undefined */
+   unsigned long   enable:1;   /* RW */
+   } s4a;
 };
 
 /* = */
@@ -3784,8 +3815,8 @@ union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
 /* = */
 #define UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
 #define UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
-#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1604000UL
-#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x484000UL
+#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1603000UL
+#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x483000UL
 #define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR ( 

[tip:x86/platform] x86/platform/UV: Fix GAM MMR changes in UV4A

[tip-bot for Mike Travis]

Commit-ID:  ecce47e0bde6faa3256740280754bfd06a1a4efa
Gitweb: https://git.kernel.org/tip/ecce47e0bde6faa3256740280754bfd06a1a4efa
Author: Mike Travis 
AuthorDate: Mon, 8 Jan 2018 13:40:02 -0600
Committer:  Ingo Molnar 
CommitDate: Tue, 16 Jan 2018 03:58:37 +0100

x86/platform/UV: Fix GAM MMR changes in UV4A

Intel processor changes necessitated UV4 HUB Global Address Memory
(GAM) fixes to accommodate support for those processors.  This patch
deals with the updated address range change from 46 to 52 bits in UV4A.

Signed-off-by: Mike Travis 
Acked-by: Andrew Banman 
Cc: Andrew Morton 
Cc: Dimitri Sivanich 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Russ Anderson 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1515440405-20880-5-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/uv/uv_mmrs.h | 86 ---
 1 file changed, 80 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index b3afccc..30db549 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -3743,7 +3743,6 @@ union uvh_rh_gam_gru_overlay_config_mmr_u {
/*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR)
 
 
-
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_SHFT26
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT46
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_SHFT 63
@@ -3758,6 +3757,30 @@ union uvh_rh_gam_gru_overlay_config_mmr_u {
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK
0x000fc000UL
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK 0x8000UL
 
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT 52
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK 0x000ffc00UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK 0x03f0UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK 0x8000UL
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK ( \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK)
 
 union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
unsigned long   v;
@@ -3777,6 +3800,14 @@ union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
unsigned long   rsvd_56_62:7;
unsigned long   enable:1;   /* RW */
} s4;
+   struct uv4ah_rh_gam_mmioh_overlay_config0_mmr_s {
+   unsigned long   rsvd_0_25:26;
+   unsigned long   base:26;/* RW */
+   unsigned long   m_io:6; /* RW */
+   unsigned long   n_io:4;
+   unsigned long   undef_62:1; /* Undefined */
+   unsigned long   enable:1;   /* RW */
+   } s4a;
 };
 
 /* = */
@@ -3784,8 +3815,8 @@ union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
 /* = */
 #define UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
 #define UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
-#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1604000UL
-#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x484000UL
+#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1603000UL
+#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x483000UL
 #define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR ( \
is_uv1_hub() ? UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR :  \
is_uv2_hub() ? UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR :  \
@@ -3793,7 +3824,6 @@ union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
/*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1

[tip:x86/platform] x86/platform/UV: Add references to access fixed UV4A HUB MMRs

[tip-bot for Mike Travis]

Commit-ID:  8078d1951da228e20dc36f83306845a565f51345
Gitweb: https://git.kernel.org/tip/8078d1951da228e20dc36f83306845a565f51345
Author: Mike Travis <mike.tra...@hpe.com>
AuthorDate: Mon, 8 Jan 2018 13:40:01 -0600
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Tue, 16 Jan 2018 03:58:37 +0100

x86/platform/UV: Add references to access fixed UV4A HUB MMRs

Add references to enable access to fixed UV4A (rev2) HUB MMRs.

Signed-off-by: Mike Travis <mike.tra...@hpe.com>
Acked-by: Andrew Banman <aban...@hpe.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Dimitri Sivanich <sivan...@hpe.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Russ Anderson <r...@hpe.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Link: 
http://lkml.kernel.org/r/1515440405-20880-4-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 arch/x86/include/asm/uv/uv_hub.h   | 14 ++
 arch/x86/include/asm/uv/uv_mmrs.h  |  1 +
 arch/x86/kernel/apic/x2apic_uv_x.c |  2 ++
 3 files changed, 17 insertions(+)

diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
index 036e26d..44cf6d6 100644
--- a/arch/x86/include/asm/uv/uv_hub.h
+++ b/arch/x86/include/asm/uv/uv_hub.h
@@ -241,6 +241,7 @@ static inline int uv_hub_info_check(int version)
 #define UV2_HUB_REVISION_BASE  3
 #define UV3_HUB_REVISION_BASE  5
 #define UV4_HUB_REVISION_BASE  7
+#define UV4A_HUB_REVISION_BASE 8   /* UV4 (fixed) rev 2 */
 
 #ifdef UV1_HUB_IS_SUPPORTED
 static inline int is_uv1_hub(void)
@@ -280,6 +281,19 @@ static inline int is_uv3_hub(void)
 }
 #endif
 
+/* First test "is UV4A", then "is UV4" */
+#ifdef UV4A_HUB_IS_SUPPORTED
+static inline int is_uv4a_hub(void)
+{
+   return (uv_hub_info->hub_revision >= UV4A_HUB_REVISION_BASE);
+}
+#else
+static inline int is_uv4a_hub(void)
+{
+   return 0;
+}
+#endif
+
 #ifdef UV4_HUB_IS_SUPPORTED
 static inline int is_uv4_hub(void)
 {
diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index f113e27..b3afccc 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -99,6 +99,7 @@
 #define UV2_HUB_IS_SUPPORTED   1
 #define UV3_HUB_IS_SUPPORTED   1
 #define UV4_HUB_IS_SUPPORTED   1
+#define UV4A_HUB_IS_SUPPORTED  1
 
 /* Error function to catch undefined references */
 extern unsigned long uv_undefined(char *str);
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index ebb7d26..2ddc140 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -137,6 +137,8 @@ static int __init early_get_pnodeid(void)
case UV3_HUB_PART_NUMBER_X:
uv_min_hub_revision_id += UV3_HUB_REVISION_BASE;
break;
+
+   /* Update: UV4A has only a modified revision to indicate HUB fixes */
case UV4_HUB_PART_NUMBER:
uv_min_hub_revision_id += UV4_HUB_REVISION_BASE - 1;
uv_cpuid.gnode_shift = 2; /* min partition is 4 sockets */

[tip:x86/platform] x86/platform/UV: Add references to access fixed UV4A HUB MMRs

[tip-bot for Mike Travis]

Commit-ID:  8078d1951da228e20dc36f83306845a565f51345
Gitweb: https://git.kernel.org/tip/8078d1951da228e20dc36f83306845a565f51345
Author: Mike Travis 
AuthorDate: Mon, 8 Jan 2018 13:40:01 -0600
Committer:  Ingo Molnar 
CommitDate: Tue, 16 Jan 2018 03:58:37 +0100

x86/platform/UV: Add references to access fixed UV4A HUB MMRs

Add references to enable access to fixed UV4A (rev2) HUB MMRs.

Signed-off-by: Mike Travis 
Acked-by: Andrew Banman 
Cc: Andrew Morton 
Cc: Dimitri Sivanich 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Russ Anderson 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1515440405-20880-4-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/uv/uv_hub.h   | 14 ++
 arch/x86/include/asm/uv/uv_mmrs.h  |  1 +
 arch/x86/kernel/apic/x2apic_uv_x.c |  2 ++
 3 files changed, 17 insertions(+)

diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
index 036e26d..44cf6d6 100644
--- a/arch/x86/include/asm/uv/uv_hub.h
+++ b/arch/x86/include/asm/uv/uv_hub.h
@@ -241,6 +241,7 @@ static inline int uv_hub_info_check(int version)
 #define UV2_HUB_REVISION_BASE  3
 #define UV3_HUB_REVISION_BASE  5
 #define UV4_HUB_REVISION_BASE  7
+#define UV4A_HUB_REVISION_BASE 8   /* UV4 (fixed) rev 2 */
 
 #ifdef UV1_HUB_IS_SUPPORTED
 static inline int is_uv1_hub(void)
@@ -280,6 +281,19 @@ static inline int is_uv3_hub(void)
 }
 #endif
 
+/* First test "is UV4A", then "is UV4" */
+#ifdef UV4A_HUB_IS_SUPPORTED
+static inline int is_uv4a_hub(void)
+{
+   return (uv_hub_info->hub_revision >= UV4A_HUB_REVISION_BASE);
+}
+#else
+static inline int is_uv4a_hub(void)
+{
+   return 0;
+}
+#endif
+
 #ifdef UV4_HUB_IS_SUPPORTED
 static inline int is_uv4_hub(void)
 {
diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index f113e27..b3afccc 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -99,6 +99,7 @@
 #define UV2_HUB_IS_SUPPORTED   1
 #define UV3_HUB_IS_SUPPORTED   1
 #define UV4_HUB_IS_SUPPORTED   1
+#define UV4A_HUB_IS_SUPPORTED  1
 
 /* Error function to catch undefined references */
 extern unsigned long uv_undefined(char *str);
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index ebb7d26..2ddc140 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -137,6 +137,8 @@ static int __init early_get_pnodeid(void)
case UV3_HUB_PART_NUMBER_X:
uv_min_hub_revision_id += UV3_HUB_REVISION_BASE;
break;
+
+   /* Update: UV4A has only a modified revision to indicate HUB fixes */
case UV4_HUB_PART_NUMBER:
uv_min_hub_revision_id += UV4_HUB_REVISION_BASE - 1;
uv_cpuid.gnode_shift = 2; /* min partition is 4 sockets */

[tip:x86/platform] x86/platform/UV: Fix UV4A support on new Intel Processors

[tip-bot for Mike Travis]

Commit-ID:  62807106c3219d2d6ddbfc778a5ee7e6ba38e58f
Gitweb: https://git.kernel.org/tip/62807106c3219d2d6ddbfc778a5ee7e6ba38e58f
Author: Mike Travis <mike.tra...@hpe.com>
AuthorDate: Mon, 8 Jan 2018 13:40:00 -0600
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Tue, 16 Jan 2018 03:58:37 +0100

x86/platform/UV: Fix UV4A support on new Intel Processors

Upcoming Intel CascadeLake and IceLake processors have some architecture
changes that required fixes in the UV4 HUB bringing that chip to
revision 2.  The nomenclature for that new chip is "UV4A".

This patch fixes the references for the expanded MMR definitions in the
previous (automated) patch.

Signed-off-by: Mike Travis <mike.tra...@hpe.com>
Acked-by: Andrew Banman <aban...@hpe.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Dimitri Sivanich <sivan...@hpe.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Russ Anderson <r...@hpe.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Link: 
http://lkml.kernel.org/r/1515440405-20880-3-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 6de35fc..ebb7d26 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -768,6 +768,7 @@ static __init void map_gru_high(int max_pnode)
return;
}
 
+   /* Only UV3 has distributed GRU mode */
if (is_uv3_hub() && gru.s3.mode) {
map_gru_distributed(gru.v);
return;
@@ -817,17 +818,20 @@ static __initdata struct mmioh_config mmiohs[] = {
 /* UV3 & UV4 have identical MMIOH overlay configs */
 static __init void map_mmioh_high_uv3(int index, int min_pnode, int max_pnode)
 {
-   union uv3h_rh_gam_mmioh_overlay_config0_mmr_u overlay;
+   union uvh_rh_gam_mmioh_overlay_config0_mmr_u overlay;
unsigned long mmr;
unsigned long base;
+   unsigned long m_overlay;
int i, n, shift, m_io, max_io;
int nasid, lnasid, fi, li;
char *id;
 
id = mmiohs[index].id;
overlay.v = uv_read_local_mmr(mmiohs[index].overlay);
+   m_overlay = mmiohs[index].overlay;
 
-   pr_info("UV: %s overlay 0x%lx base:0x%x m_io:%d\n", id, overlay.v, 
overlay.s3.base, overlay.s3.m_io);
+   pr_info("UV: %s overlay 0x%lx(@0x%lx) base:0x%x m_io:%d\n",
+   id, overlay.v, m_overlay, overlay.s3.base, overlay.s3.m_io);
if (!overlay.s3.enable) {
pr_info("UV: %s disabled\n", id);
return;
@@ -844,10 +848,14 @@ static __init void map_mmioh_high_uv3(int index, int 
min_pnode, int max_pnode)
max_io = lnasid = fi = li = -1;
 
for (i = 0; i < n; i++) {
-   union uv3h_rh_gam_mmioh_redirect_config0_mmr_u redirect;
+   union uvh_rh_gam_mmioh_redirect_config0_mmr_u redirect;
+   unsigned long m_redirect = mmr + i * 8;
 
redirect.v = uv_read_local_mmr(mmr + i * 8);
nasid = redirect.s3.nasid;
+   printk_once(KERN_INFO
+   "UV: %s redirect 0x%lx(@0x%lx) 0x%04x\n",
+   id, redirect.v, m_redirect, nasid);
/* Invalid NASID: */
if (nasid < min_pnode || max_pnode < nasid)
nasid = -1;

[tip:x86/platform] x86/platform/UV: Fix UV4A support on new Intel Processors

[tip-bot for Mike Travis]

Commit-ID:  62807106c3219d2d6ddbfc778a5ee7e6ba38e58f
Gitweb: https://git.kernel.org/tip/62807106c3219d2d6ddbfc778a5ee7e6ba38e58f
Author: Mike Travis 
AuthorDate: Mon, 8 Jan 2018 13:40:00 -0600
Committer:  Ingo Molnar 
CommitDate: Tue, 16 Jan 2018 03:58:37 +0100

x86/platform/UV: Fix UV4A support on new Intel Processors

Upcoming Intel CascadeLake and IceLake processors have some architecture
changes that required fixes in the UV4 HUB bringing that chip to
revision 2.  The nomenclature for that new chip is "UV4A".

This patch fixes the references for the expanded MMR definitions in the
previous (automated) patch.

Signed-off-by: Mike Travis 
Acked-by: Andrew Banman 
Cc: Andrew Morton 
Cc: Dimitri Sivanich 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Russ Anderson 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1515440405-20880-3-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 6de35fc..ebb7d26 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -768,6 +768,7 @@ static __init void map_gru_high(int max_pnode)
return;
}
 
+   /* Only UV3 has distributed GRU mode */
if (is_uv3_hub() && gru.s3.mode) {
map_gru_distributed(gru.v);
return;
@@ -817,17 +818,20 @@ static __initdata struct mmioh_config mmiohs[] = {
 /* UV3 & UV4 have identical MMIOH overlay configs */
 static __init void map_mmioh_high_uv3(int index, int min_pnode, int max_pnode)
 {
-   union uv3h_rh_gam_mmioh_overlay_config0_mmr_u overlay;
+   union uvh_rh_gam_mmioh_overlay_config0_mmr_u overlay;
unsigned long mmr;
unsigned long base;
+   unsigned long m_overlay;
int i, n, shift, m_io, max_io;
int nasid, lnasid, fi, li;
char *id;
 
id = mmiohs[index].id;
overlay.v = uv_read_local_mmr(mmiohs[index].overlay);
+   m_overlay = mmiohs[index].overlay;
 
-   pr_info("UV: %s overlay 0x%lx base:0x%x m_io:%d\n", id, overlay.v, 
overlay.s3.base, overlay.s3.m_io);
+   pr_info("UV: %s overlay 0x%lx(@0x%lx) base:0x%x m_io:%d\n",
+   id, overlay.v, m_overlay, overlay.s3.base, overlay.s3.m_io);
if (!overlay.s3.enable) {
pr_info("UV: %s disabled\n", id);
return;
@@ -844,10 +848,14 @@ static __init void map_mmioh_high_uv3(int index, int 
min_pnode, int max_pnode)
max_io = lnasid = fi = li = -1;
 
for (i = 0; i < n; i++) {
-   union uv3h_rh_gam_mmioh_redirect_config0_mmr_u redirect;
+   union uvh_rh_gam_mmioh_redirect_config0_mmr_u redirect;
+   unsigned long m_redirect = mmr + i * 8;
 
redirect.v = uv_read_local_mmr(mmr + i * 8);
nasid = redirect.s3.nasid;
+   printk_once(KERN_INFO
+   "UV: %s redirect 0x%lx(@0x%lx) 0x%04x\n",
+   id, redirect.v, m_redirect, nasid);
/* Invalid NASID: */
if (nasid < min_pnode || max_pnode < nasid)
nasid = -1;

[tip:x86/platform] x86/platform/UV: Update uv_mmrs.h to prepare for UV4A fixes

[tip-bot for Mike Travis]

Commit-ID:  673aa20c55a138621d1340d343cd6b07c1cb4e92
Gitweb: https://git.kernel.org/tip/673aa20c55a138621d1340d343cd6b07c1cb4e92
Author: Mike Travis <mike.tra...@hpe.com>
AuthorDate: Mon, 8 Jan 2018 13:39:59 -0600
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Tue, 16 Jan 2018 03:58:36 +0100

x86/platform/UV: Update uv_mmrs.h to prepare for UV4A fixes

Regenerate uv_mmrs.h file to accommodate fixes to UV4A MMRs.

Signed-off-by: Mike Travis <mike.tra...@hpe.com>
Acked-by: Andrew Banman <aban...@hpe.com>
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Dimitri Sivanich <sivan...@hpe.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Russ Anderson <r...@hpe.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Link: 
http://lkml.kernel.org/r/1515440405-20880-2-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 arch/x86/include/asm/uv/uv_mmrs.h | 615 +-
 1 file changed, 533 insertions(+), 82 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index 548d684..f113e27 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -3031,6 +3031,41 @@ union uvh_node_present_table_u {
 #define UVH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
 #define UVH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
 
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
 
 union uvh_rh_gam_alias210_overlay_config_0_mmr_u {
unsigned long   v;
@@ -3042,6 +3077,46 @@ union uvh_rh_gam_alias210_overlay_config_0_mmr_u {
unsigned long   rsvd_53_62:10;
unsigned long   enable:1;   /* RW */
} s;
+   struct uv1h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } s1;
+   struct uvxh_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } sx;
+   struct uv2h_rh_gam_alias210_ove

[tip:x86/platform] x86/platform/UV: Update uv_mmrs.h to prepare for UV4A fixes

[tip-bot for Mike Travis]

Commit-ID:  673aa20c55a138621d1340d343cd6b07c1cb4e92
Gitweb: https://git.kernel.org/tip/673aa20c55a138621d1340d343cd6b07c1cb4e92
Author: Mike Travis 
AuthorDate: Mon, 8 Jan 2018 13:39:59 -0600
Committer:  Ingo Molnar 
CommitDate: Tue, 16 Jan 2018 03:58:36 +0100

x86/platform/UV: Update uv_mmrs.h to prepare for UV4A fixes

Regenerate uv_mmrs.h file to accommodate fixes to UV4A MMRs.

Signed-off-by: Mike Travis 
Acked-by: Andrew Banman 
Cc: Andrew Morton 
Cc: Dimitri Sivanich 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Russ Anderson 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1515440405-20880-2-git-send-email-mike.tra...@hpe.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/uv/uv_mmrs.h | 615 +-
 1 file changed, 533 insertions(+), 82 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index 548d684..f113e27 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -3031,6 +3031,41 @@ union uvh_node_present_table_u {
 #define UVH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
 #define UVH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
 
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
 
 union uvh_rh_gam_alias210_overlay_config_0_mmr_u {
unsigned long   v;
@@ -3042,6 +3077,46 @@ union uvh_rh_gam_alias210_overlay_config_0_mmr_u {
unsigned long   rsvd_53_62:10;
unsigned long   enable:1;   /* RW */
} s;
+   struct uv1h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } s1;
+   struct uvxh_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } sx;
+   struct uv2h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long

[PATCH 4/7] x86/platform/UV: Fix GAM MMR changes in UV4A

[Mike Travis]

Intel processor changes necessitated UV4 HUB Global Address Memory
(GAM) fixes to accommodate support for those processors.  This patch
deals with the updated address range change from 46 to 52 bits in UV4A.

Signed-off-by: Mike Travis <mike.tra...@hpe.com>
Acked-by: Andrew Banman <aban...@hpe.com>
---
 arch/x86/include/asm/uv/uv_mmrs.h | 86 ---
 1 file changed, 80 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index b3afccc..30db549 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -3743,7 +3743,6 @@
/*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR)
 
 
-
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_SHFT26
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT46
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_SHFT 63
@@ -3758,6 +3757,30 @@
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK
0x000fc000UL
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK 0x8000UL
 
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT 52
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK 0x000ffc00UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK 0x03f0UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK 0x8000UL
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK ( \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK)
 
 union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
unsigned long   v;
@@ -3777,6 +3800,14 @@
unsigned long   rsvd_56_62:7;
unsigned long   enable:1;   /* RW */
} s4;
+   struct uv4ah_rh_gam_mmioh_overlay_config0_mmr_s {
+   unsigned long   rsvd_0_25:26;
+   unsigned long   base:26;/* RW */
+   unsigned long   m_io:6; /* RW */
+   unsigned long   n_io:4;
+   unsigned long   undef_62:1; /* Undefined */
+   unsigned long   enable:1;   /* RW */
+   } s4a;
 };
 
 /* = */
@@ -3784,8 +3815,8 @@
 /* = */
 #define UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
 #define UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
-#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1604000UL
-#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x484000UL
+#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1603000UL
+#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x483000UL
 #define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR ( \
is_uv1_hub() ? UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR :  \
is_uv2_hub() ? UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR :  \
@@ -3793,7 +3824,6 @@
/*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR)
 
 
-
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_SHFT26
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT46
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_ENABLE_SHFT 63
@@ -3808,6 +3838,24 @@
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK
0x000fc000UL
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_ENABLE_MASK 0x8000UL
 
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT 52
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_MASK 0x000ffc00UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK 0x03f0UL
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMI

[PATCH 4/7] x86/platform/UV: Fix GAM MMR changes in UV4A

[Mike Travis]

Intel processor changes necessitated UV4 HUB Global Address Memory
(GAM) fixes to accommodate support for those processors.  This patch
deals with the updated address range change from 46 to 52 bits in UV4A.

Signed-off-by: Mike Travis 
Acked-by: Andrew Banman 
---
 arch/x86/include/asm/uv/uv_mmrs.h | 86 ---
 1 file changed, 80 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index b3afccc..30db549 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -3743,7 +3743,6 @@
/*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR)
 
 
-
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_SHFT26
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT46
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_SHFT 63
@@ -3758,6 +3757,30 @@
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK
0x000fc000UL
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK 0x8000UL
 
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT 52
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK 0x000ffc00UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK 0x03f0UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK 0x8000UL
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK ( \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK)
 
 union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
unsigned long   v;
@@ -3777,6 +3800,14 @@
unsigned long   rsvd_56_62:7;
unsigned long   enable:1;   /* RW */
} s4;
+   struct uv4ah_rh_gam_mmioh_overlay_config0_mmr_s {
+   unsigned long   rsvd_0_25:26;
+   unsigned long   base:26;/* RW */
+   unsigned long   m_io:6; /* RW */
+   unsigned long   n_io:4;
+   unsigned long   undef_62:1; /* Undefined */
+   unsigned long   enable:1;   /* RW */
+   } s4a;
 };
 
 /* = */
@@ -3784,8 +3815,8 @@
 /* = */
 #define UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
 #define UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
-#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1604000UL
-#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x484000UL
+#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1603000UL
+#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x483000UL
 #define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR ( \
is_uv1_hub() ? UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR :  \
is_uv2_hub() ? UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR :  \
@@ -3793,7 +3824,6 @@
/*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR)
 
 
-
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_SHFT26
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT46
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_ENABLE_SHFT 63
@@ -3808,6 +3838,24 @@
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK
0x000fc000UL
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_ENABLE_MASK 0x8000UL
 
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT 52
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_MASK 0x000ffc00UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK 0x03f0UL
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT : \

[PATCH 5/7] x86/platform/UV: Fix GAM MMR references in UV x2apic code

[Mike Travis]

Along with the fixes in UV4A (rev2) MMRs, the code to access those
MMRs also was modified by the fixes.  UV3, UV4, and UV4A no longer
have compatible seetups for Global Address Memory (GAM).  Correct the
new mistakes.

Signed-off-by: Mike Travis <mike.tra...@hpe.com>
Acked-by: Andrew Banman <aban...@hpe.com>
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 83 +-
 1 file changed, 37 insertions(+), 46 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index e158722..f1c26f9 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -793,70 +793,61 @@ static __init void map_mmr_high(int max_pnode)
pr_info("UV: MMR disabled\n");
 }
 
-/*
- * This commonality works because both 0 & 1 versions of the MMIOH OVERLAY
- * and REDIRECT MMR regs are exactly the same on UV3.
- */
-struct mmioh_config {
-   unsigned long overlay;
-   unsigned long redirect;
-   char *id;
-};
-
-static __initdata struct mmioh_config mmiohs[] = {
-   {
-   UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR,
-   UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR,
-   "MMIOH0"
-   },
-   {
-   UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR,
-   UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR,
-   "MMIOH1"
-   },
-};
-
-/* UV3 & UV4 have identical MMIOH overlay configs */
-static __init void map_mmioh_high_uv3(int index, int min_pnode, int max_pnode)
+/* UV3/4 have identical MMIOH overlay configs, UV4A is slightly different */
+static __init void map_mmioh_high_uv34(int index, int min_pnode, int max_pnode)
 {
-   union uvh_rh_gam_mmioh_overlay_config0_mmr_u overlay;
+   unsigned long overlay;
unsigned long mmr;
unsigned long base;
+   unsigned long nasid_mask;
unsigned long m_overlay;
int i, n, shift, m_io, max_io;
int nasid, lnasid, fi, li;
char *id;
 
-   id = mmiohs[index].id;
-   overlay.v = uv_read_local_mmr(mmiohs[index].overlay);
-   m_overlay = mmiohs[index].overlay;
-
-   pr_info("UV: %s overlay 0x%lx(@0x%lx) base:0x%x m_io:%d\n",
-   id, overlay.v, m_overlay, overlay.s3.base, overlay.s3.m_io);
-   if (!overlay.s3.enable) {
+   if (index == 0) {
+   id = "MMIOH0";
+   m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR;
+   overlay = uv_read_local_mmr(m_overlay);
+   base = overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK;
+   mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR;
+   m_io = (overlay & 
UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK)
+   >> UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
+   shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
+   n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
+   nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_NASID_MASK;
+   } else {
+   id = "MMIOH1";
+   m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR;
+   overlay = uv_read_local_mmr(m_overlay);
+   base = overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_MASK;
+   mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR;
+   m_io = (overlay & 
UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK)
+   >> UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT;
+   shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT;
+   n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR_DEPTH;
+   nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR_NASID_MASK;
+   }
+   pr_info("UV: %s overlay 0x%lx base:0x%lx m_io:%d\n", id, overlay, base, 
m_io);
+   if (!(overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK)) {
pr_info("UV: %s disabled\n", id);
return;
}
 
-   shift = UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_SHFT;
-   base = (unsigned long)overlay.s3.base;
-   m_io = overlay.s3.m_io;
-   mmr = mmiohs[index].redirect;
-   n = UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
/* Convert to NASID: */
min_pnode *= 2;
max_pnode *= 2;
max_io = lnasid = fi = li = -1;
 
for (i = 0; i < n; i++) {
-   union uvh_rh_gam_mmioh_redirect_config0_mmr_u redirect;
unsigned long m_redirect = mmr + i * 8;
+   unsigned long redirect = uv_read_local_mmr(m_redirect);
+
+   nasid = redirect & nasid_mask;
+   if (i == 0)
+   pr_info("UV: %s redirect base 0x%lx(@0x%lx) 0x%04x\n",
+   id, redirect, m_redirect, nasid);
 
-   redirect.v = uv_read_local_mmr(mmr + i *

[PATCH 5/7] x86/platform/UV: Fix GAM MMR references in UV x2apic code

[Mike Travis]

Along with the fixes in UV4A (rev2) MMRs, the code to access those
MMRs also was modified by the fixes.  UV3, UV4, and UV4A no longer
have compatible seetups for Global Address Memory (GAM).  Correct the
new mistakes.

Signed-off-by: Mike Travis 
Acked-by: Andrew Banman 
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 83 +-
 1 file changed, 37 insertions(+), 46 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index e158722..f1c26f9 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -793,70 +793,61 @@ static __init void map_mmr_high(int max_pnode)
pr_info("UV: MMR disabled\n");
 }
 
-/*
- * This commonality works because both 0 & 1 versions of the MMIOH OVERLAY
- * and REDIRECT MMR regs are exactly the same on UV3.
- */
-struct mmioh_config {
-   unsigned long overlay;
-   unsigned long redirect;
-   char *id;
-};
-
-static __initdata struct mmioh_config mmiohs[] = {
-   {
-   UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR,
-   UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR,
-   "MMIOH0"
-   },
-   {
-   UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR,
-   UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR,
-   "MMIOH1"
-   },
-};
-
-/* UV3 & UV4 have identical MMIOH overlay configs */
-static __init void map_mmioh_high_uv3(int index, int min_pnode, int max_pnode)
+/* UV3/4 have identical MMIOH overlay configs, UV4A is slightly different */
+static __init void map_mmioh_high_uv34(int index, int min_pnode, int max_pnode)
 {
-   union uvh_rh_gam_mmioh_overlay_config0_mmr_u overlay;
+   unsigned long overlay;
unsigned long mmr;
unsigned long base;
+   unsigned long nasid_mask;
unsigned long m_overlay;
int i, n, shift, m_io, max_io;
int nasid, lnasid, fi, li;
char *id;
 
-   id = mmiohs[index].id;
-   overlay.v = uv_read_local_mmr(mmiohs[index].overlay);
-   m_overlay = mmiohs[index].overlay;
-
-   pr_info("UV: %s overlay 0x%lx(@0x%lx) base:0x%x m_io:%d\n",
-   id, overlay.v, m_overlay, overlay.s3.base, overlay.s3.m_io);
-   if (!overlay.s3.enable) {
+   if (index == 0) {
+   id = "MMIOH0";
+   m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR;
+   overlay = uv_read_local_mmr(m_overlay);
+   base = overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK;
+   mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR;
+   m_io = (overlay & 
UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK)
+   >> UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
+   shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
+   n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
+   nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_NASID_MASK;
+   } else {
+   id = "MMIOH1";
+   m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR;
+   overlay = uv_read_local_mmr(m_overlay);
+   base = overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_MASK;
+   mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR;
+   m_io = (overlay & 
UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK)
+   >> UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT;
+   shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT;
+   n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR_DEPTH;
+   nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR_NASID_MASK;
+   }
+   pr_info("UV: %s overlay 0x%lx base:0x%lx m_io:%d\n", id, overlay, base, 
m_io);
+   if (!(overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK)) {
pr_info("UV: %s disabled\n", id);
return;
}
 
-   shift = UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_SHFT;
-   base = (unsigned long)overlay.s3.base;
-   m_io = overlay.s3.m_io;
-   mmr = mmiohs[index].redirect;
-   n = UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
/* Convert to NASID: */
min_pnode *= 2;
max_pnode *= 2;
max_io = lnasid = fi = li = -1;
 
for (i = 0; i < n; i++) {
-   union uvh_rh_gam_mmioh_redirect_config0_mmr_u redirect;
unsigned long m_redirect = mmr + i * 8;
+   unsigned long redirect = uv_read_local_mmr(m_redirect);
+
+   nasid = redirect & nasid_mask;
+   if (i == 0)
+   pr_info("UV: %s redirect base 0x%lx(@0x%lx) 0x%04x\n",
+   id, redirect, m_redirect, nasid);
 
-   redirect.v = uv_read_local_mmr(mmr + i * 8);
-   nasid = redirect.s3.nasid;
-   printk_o

[PATCH 6/7] x86/platform/UV: Fix for UV4A BAU MMRs

[Mike Travis]

Fixes to accommodate Intel Processor changes for UV4A broadcast assist unit
(BAU) MMRs.

Signed-off-by: Mike Travis <mike.tra...@hpe.com>
Acked-by: Andrew Banman <aban...@hpe.com>
---
 arch/x86/include/asm/uv/uv_mmrs.h | 59 +--
 1 file changed, 38 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index 30db549..ecb9dde 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -39,9 +39,11 @@
  * #define UV2Hxxx b
  * #define UV3Hxxx c
  * #define UV4Hxxx d
+ * #define UV4AHxxx e
  * #define UVHxxx  (is_uv1_hub() ? UV1Hxxx :
  * (is_uv2_hub() ? UV2Hxxx :
  * (is_uv3_hub() ? UV3Hxxx :
+ * (is_uv4a_hub() ? UV4AHxxx :
  * UV4Hxxx))
  *
  * If the MMR exists on all hub types > 1 but have different addresses, the
@@ -49,8 +51,10 @@
  * #define UV2Hxxx b
  * #define UV3Hxxx c
  * #define UV4Hxxx d
+ * #define UV4AHxxx e
  * #define UVHxxx  (is_uv2_hub() ? UV2Hxxx :
  * (is_uv3_hub() ? UV3Hxxx :
+ * (is_uv4a_hub() ? UV4AHxxx :
  * UV4Hxxx))
  *
  * union uvh_xxx {
@@ -63,6 +67,7 @@
  * } s2;
  * struct uv3h_xxx_s {  # Full UV3 definition (*)
  * } s3;
+ * (NOTE: No struct uv4ah_xxx_s members exist)
  * struct uv4h_xxx_s {  # Full UV4 definition (*)
  * } s4;
  * };
@@ -2780,35 +2785,47 @@
/*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_32)
 
 #define UVH_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_SHFT12
-#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT 49
-#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK 0x7ffeUL
 
+#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
-
+#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
+#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
+#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x3000UL
-
-
-union uvh_lb_bau_sb_descriptor_base_u {
-   unsigned long   v;
-   struct uvh_lb_bau_sb_descriptor_base_s {
-   unsigned long   rsvd_0_11:12;
-   unsigned long   rsvd_12_48:37;
-   unsigned long   node_id:14; /* RW */
-   unsigned long   rsvd_63:1;
-   } s;
-   struct uv4h_lb_bau_sb_descriptor_base_s {
-   unsigned long   rsvd_0_11:12;
-   unsigned long   page_address:34;/* RW */
-   unsigned long   rsvd_46_48:3;
-   unsigned long   node_id:14; /* RW */
-   unsigned long   rsvd_63:1;
-   } s4;
-};
+#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
+
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT   53
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x000ff000UL
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK   0xffe0UL
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :  \
+   /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT)
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :  \
+   /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK)
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :\
+   is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :  \
+   /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BA

[PATCH 2/7] x86/platform/UV: Support for UV4A fixes for new Intel Processors

[Mike Travis]

Upcoming Intel CascadeLake and IceLake processors have some architecture
changes that required fixes in the UV4 HUB bringing that chip to
revision 2.  The nomenclature for that new chip is "UV4A".

This patch fixes the references for the expanded MMR definitions in the
previous (automated) patch.

Signed-off-by: Mike Travis <mike.tra...@hpe.com>
Acked-by: Andrew Banman <aban...@hpe.com>
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index e1b8e8b..b0ce393 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -767,6 +767,7 @@ static __init void map_gru_high(int max_pnode)
return;
}
 
+   /* Only UV3 has distributed GRU mode */
if (is_uv3_hub() && gru.s3.mode) {
map_gru_distributed(gru.v);
return;
@@ -816,17 +817,20 @@ struct mmioh_config {
 /* UV3 & UV4 have identical MMIOH overlay configs */
 static __init void map_mmioh_high_uv3(int index, int min_pnode, int max_pnode)
 {
-   union uv3h_rh_gam_mmioh_overlay_config0_mmr_u overlay;
+   union uvh_rh_gam_mmioh_overlay_config0_mmr_u overlay;
unsigned long mmr;
unsigned long base;
+   unsigned long m_overlay;
int i, n, shift, m_io, max_io;
int nasid, lnasid, fi, li;
char *id;
 
id = mmiohs[index].id;
overlay.v = uv_read_local_mmr(mmiohs[index].overlay);
+   m_overlay = mmiohs[index].overlay;
 
-   pr_info("UV: %s overlay 0x%lx base:0x%x m_io:%d\n", id, overlay.v, 
overlay.s3.base, overlay.s3.m_io);
+   pr_info("UV: %s overlay 0x%lx(@0x%lx) base:0x%x m_io:%d\n",
+   id, overlay.v, m_overlay, overlay.s3.base, overlay.s3.m_io);
if (!overlay.s3.enable) {
pr_info("UV: %s disabled\n", id);
return;
@@ -843,10 +847,14 @@ static __init void map_mmioh_high_uv3(int index, int 
min_pnode, int max_pnode)
max_io = lnasid = fi = li = -1;
 
for (i = 0; i < n; i++) {
-   union uv3h_rh_gam_mmioh_redirect_config0_mmr_u redirect;
+   union uvh_rh_gam_mmioh_redirect_config0_mmr_u redirect;
+   unsigned long m_redirect = mmr + i * 8;
 
redirect.v = uv_read_local_mmr(mmr + i * 8);
nasid = redirect.s3.nasid;
+   printk_once(KERN_INFO
+   "UV: %s redirect 0x%lx(@0x%lx) 0x%04x\n",
+   id, redirect.v, m_redirect, nasid);
/* Invalid NASID: */
if (nasid < min_pnode || max_pnode < nasid)
nasid = -1;
-- 
1.8.2.1

[PATCH 0/7 v2] x86/platform/UV: UV Fix patches for Intel processors

[Mike Travis]

This patchset handles the fixes made to the UV4 HUB for upcoming Intel
processors as there are some interface changes.

v2: fix excessive MMIOH redirect messages and print redirect MMR base for
each MMIOH section.

* Update uv_mmrs.h to prep for fixed defines for UV4A.

* Updates to handle UV4 vs. UV4A (fixed) arches.

* Updates to handle UV4 GAM (global addressable memory) MMRs fixes.

* Updates to handle UV4 BAU (broadcast assist unit) MMRs fixes.

* Turn on UV4A_IS_SUPPORTED to enable code and header file fixes.

[PATCH 0/7 v2] x86/platform/UV: UV Fix patches for Intel processors

[Mike Travis]

This patchset handles the fixes made to the UV4 HUB for upcoming Intel
processors as there are some interface changes.

v2: fix excessive MMIOH redirect messages and print redirect MMR base for
each MMIOH section.

* Update uv_mmrs.h to prep for fixed defines for UV4A.

* Updates to handle UV4 vs. UV4A (fixed) arches.

* Updates to handle UV4 GAM (global addressable memory) MMRs fixes.

* Updates to handle UV4 BAU (broadcast assist unit) MMRs fixes.

* Turn on UV4A_IS_SUPPORTED to enable code and header file fixes.

[PATCH 6/7] x86/platform/UV: Fix for UV4A BAU MMRs

[Mike Travis]

Fixes to accommodate Intel Processor changes for UV4A broadcast assist unit
(BAU) MMRs.

Signed-off-by: Mike Travis 
Acked-by: Andrew Banman 
---
 arch/x86/include/asm/uv/uv_mmrs.h | 59 +--
 1 file changed, 38 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index 30db549..ecb9dde 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -39,9 +39,11 @@
  * #define UV2Hxxx b
  * #define UV3Hxxx c
  * #define UV4Hxxx d
+ * #define UV4AHxxx e
  * #define UVHxxx  (is_uv1_hub() ? UV1Hxxx :
  * (is_uv2_hub() ? UV2Hxxx :
  * (is_uv3_hub() ? UV3Hxxx :
+ * (is_uv4a_hub() ? UV4AHxxx :
  * UV4Hxxx))
  *
  * If the MMR exists on all hub types > 1 but have different addresses, the
@@ -49,8 +51,10 @@
  * #define UV2Hxxx b
  * #define UV3Hxxx c
  * #define UV4Hxxx d
+ * #define UV4AHxxx e
  * #define UVHxxx  (is_uv2_hub() ? UV2Hxxx :
  * (is_uv3_hub() ? UV3Hxxx :
+ * (is_uv4a_hub() ? UV4AHxxx :
  * UV4Hxxx))
  *
  * union uvh_xxx {
@@ -63,6 +67,7 @@
  * } s2;
  * struct uv3h_xxx_s {  # Full UV3 definition (*)
  * } s3;
+ * (NOTE: No struct uv4ah_xxx_s members exist)
  * struct uv4h_xxx_s {  # Full UV4 definition (*)
  * } s4;
  * };
@@ -2780,35 +2785,47 @@
/*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_32)
 
 #define UVH_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_SHFT12
-#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT 49
-#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK 0x7ffeUL
 
+#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
-
+#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
+#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
+#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x3000UL
-
-
-union uvh_lb_bau_sb_descriptor_base_u {
-   unsigned long   v;
-   struct uvh_lb_bau_sb_descriptor_base_s {
-   unsigned long   rsvd_0_11:12;
-   unsigned long   rsvd_12_48:37;
-   unsigned long   node_id:14; /* RW */
-   unsigned long   rsvd_63:1;
-   } s;
-   struct uv4h_lb_bau_sb_descriptor_base_s {
-   unsigned long   rsvd_0_11:12;
-   unsigned long   page_address:34;/* RW */
-   unsigned long   rsvd_46_48:3;
-   unsigned long   node_id:14; /* RW */
-   unsigned long   rsvd_63:1;
-   } s4;
-};
+#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
+
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT   53
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x000ff000UL
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK   0xffe0UL
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :  \
+   /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT)
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :  \
+   /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK)
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :\
+   is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :  \
+   /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_M

[PATCH 2/7] x86/platform/UV: Support for UV4A fixes for new Intel Processors

[Mike Travis]

Upcoming Intel CascadeLake and IceLake processors have some architecture
changes that required fixes in the UV4 HUB bringing that chip to
revision 2.  The nomenclature for that new chip is "UV4A".

This patch fixes the references for the expanded MMR definitions in the
previous (automated) patch.

Signed-off-by: Mike Travis 
Acked-by: Andrew Banman 
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index e1b8e8b..b0ce393 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -767,6 +767,7 @@ static __init void map_gru_high(int max_pnode)
return;
}
 
+   /* Only UV3 has distributed GRU mode */
if (is_uv3_hub() && gru.s3.mode) {
map_gru_distributed(gru.v);
return;
@@ -816,17 +817,20 @@ struct mmioh_config {
 /* UV3 & UV4 have identical MMIOH overlay configs */
 static __init void map_mmioh_high_uv3(int index, int min_pnode, int max_pnode)
 {
-   union uv3h_rh_gam_mmioh_overlay_config0_mmr_u overlay;
+   union uvh_rh_gam_mmioh_overlay_config0_mmr_u overlay;
unsigned long mmr;
unsigned long base;
+   unsigned long m_overlay;
int i, n, shift, m_io, max_io;
int nasid, lnasid, fi, li;
char *id;
 
id = mmiohs[index].id;
overlay.v = uv_read_local_mmr(mmiohs[index].overlay);
+   m_overlay = mmiohs[index].overlay;
 
-   pr_info("UV: %s overlay 0x%lx base:0x%x m_io:%d\n", id, overlay.v, 
overlay.s3.base, overlay.s3.m_io);
+   pr_info("UV: %s overlay 0x%lx(@0x%lx) base:0x%x m_io:%d\n",
+   id, overlay.v, m_overlay, overlay.s3.base, overlay.s3.m_io);
if (!overlay.s3.enable) {
pr_info("UV: %s disabled\n", id);
return;
@@ -843,10 +847,14 @@ static __init void map_mmioh_high_uv3(int index, int 
min_pnode, int max_pnode)
max_io = lnasid = fi = li = -1;
 
for (i = 0; i < n; i++) {
-   union uv3h_rh_gam_mmioh_redirect_config0_mmr_u redirect;
+   union uvh_rh_gam_mmioh_redirect_config0_mmr_u redirect;
+   unsigned long m_redirect = mmr + i * 8;
 
redirect.v = uv_read_local_mmr(mmr + i * 8);
nasid = redirect.s3.nasid;
+   printk_once(KERN_INFO
+   "UV: %s redirect 0x%lx(@0x%lx) 0x%04x\n",
+   id, redirect.v, m_redirect, nasid);
/* Invalid NASID: */
if (nasid < min_pnode || max_pnode < nasid)
nasid = -1;
-- 
1.8.2.1

[PATCH 1/7] x86/platform/UV: Update uv_mmrs.h to prep for UV4A fixes

[Mike Travis]

Regenerate uv_mmrs.h file to accommodate fixes to UV4A MMRs.

Signed-off-by: Mike Travis <mike.tra...@hpe.com>
Acked-by: Andrew Banman <aban...@hpe.com>
---
 arch/x86/include/asm/uv/uv_mmrs.h | 615 +-
 1 file changed, 533 insertions(+), 82 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index 548d684..f113e27 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -3031,6 +3031,41 @@
 #define UVH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
 #define UVH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
 
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
 
 union uvh_rh_gam_alias210_overlay_config_0_mmr_u {
unsigned long   v;
@@ -3042,6 +3077,46 @@
unsigned long   rsvd_53_62:10;
unsigned long   enable:1;   /* RW */
} s;
+   struct uv1h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } s1;
+   struct uvxh_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } sx;
+   struct uv2h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } s2;
+   struct uv3h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } s3;
+   struct uv4h_rh_gam_alias210_overlay_co

[PATCH 1/7] x86/platform/UV: Update uv_mmrs.h to prep for UV4A fixes

[Mike Travis]

Regenerate uv_mmrs.h file to accommodate fixes to UV4A MMRs.

Signed-off-by: Mike Travis 
Acked-by: Andrew Banman 
---
 arch/x86/include/asm/uv/uv_mmrs.h | 615 +-
 1 file changed, 533 insertions(+), 82 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index 548d684..f113e27 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -3031,6 +3031,41 @@
 #define UVH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
 #define UVH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
 
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
 
 union uvh_rh_gam_alias210_overlay_config_0_mmr_u {
unsigned long   v;
@@ -3042,6 +3077,46 @@
unsigned long   rsvd_53_62:10;
unsigned long   enable:1;   /* RW */
} s;
+   struct uv1h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } s1;
+   struct uvxh_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } sx;
+   struct uv2h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } s2;
+   struct uv3h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } s3;
+   struct uv4h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24

[PATCH 3/7] x86/platform/UV: Add references to access to fixed UV4A HUB MMRs

[Mike Travis]

Add references to enable access to fixed UV4A (rev2) HUB MMRs.

Signed-off-by: Mike Travis <mike.tra...@hpe.com>
Acked-by: Andrew Banman <aban...@hpe.com>
---
 arch/x86/include/asm/uv/uv_hub.h   | 14 ++
 arch/x86/include/asm/uv/uv_mmrs.h  |  1 +
 arch/x86/kernel/apic/x2apic_uv_x.c |  2 ++
 3 files changed, 17 insertions(+)

diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
index 036e26d..44cf6d6 100644
--- a/arch/x86/include/asm/uv/uv_hub.h
+++ b/arch/x86/include/asm/uv/uv_hub.h
@@ -241,6 +241,7 @@ static inline int uv_hub_info_check(int version)
 #define UV2_HUB_REVISION_BASE  3
 #define UV3_HUB_REVISION_BASE  5
 #define UV4_HUB_REVISION_BASE  7
+#define UV4A_HUB_REVISION_BASE 8   /* UV4 (fixed) rev 2 */
 
 #ifdef UV1_HUB_IS_SUPPORTED
 static inline int is_uv1_hub(void)
@@ -280,6 +281,19 @@ static inline int is_uv3_hub(void)
 }
 #endif
 
+/* First test "is UV4A", then "is UV4" */
+#ifdef UV4A_HUB_IS_SUPPORTED
+static inline int is_uv4a_hub(void)
+{
+   return (uv_hub_info->hub_revision >= UV4A_HUB_REVISION_BASE);
+}
+#else
+static inline int is_uv4a_hub(void)
+{
+   return 0;
+}
+#endif
+
 #ifdef UV4_HUB_IS_SUPPORTED
 static inline int is_uv4_hub(void)
 {
diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index f113e27..b3afccc 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -99,6 +99,7 @@
 #define UV2_HUB_IS_SUPPORTED   1
 #define UV3_HUB_IS_SUPPORTED   1
 #define UV4_HUB_IS_SUPPORTED   1
+#define UV4A_HUB_IS_SUPPORTED  1
 
 /* Error function to catch undefined references */
 extern unsigned long uv_undefined(char *str);
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index b0ce393..e158722 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -137,6 +137,8 @@ static int __init early_get_pnodeid(void)
case UV3_HUB_PART_NUMBER_X:
uv_min_hub_revision_id += UV3_HUB_REVISION_BASE;
break;
+
+   /* Update: UV4A has only a modified revision to indicate HUB fixes */
case UV4_HUB_PART_NUMBER:
uv_min_hub_revision_id += UV4_HUB_REVISION_BASE - 1;
uv_cpuid.gnode_shift = 2; /* min partition is 4 sockets */
-- 
1.8.2.1

[PATCH 3/7] x86/platform/UV: Add references to access to fixed UV4A HUB MMRs

[Mike Travis]

Add references to enable access to fixed UV4A (rev2) HUB MMRs.

Signed-off-by: Mike Travis 
Acked-by: Andrew Banman 
---
 arch/x86/include/asm/uv/uv_hub.h   | 14 ++
 arch/x86/include/asm/uv/uv_mmrs.h  |  1 +
 arch/x86/kernel/apic/x2apic_uv_x.c |  2 ++
 3 files changed, 17 insertions(+)

diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
index 036e26d..44cf6d6 100644
--- a/arch/x86/include/asm/uv/uv_hub.h
+++ b/arch/x86/include/asm/uv/uv_hub.h
@@ -241,6 +241,7 @@ static inline int uv_hub_info_check(int version)
 #define UV2_HUB_REVISION_BASE  3
 #define UV3_HUB_REVISION_BASE  5
 #define UV4_HUB_REVISION_BASE  7
+#define UV4A_HUB_REVISION_BASE 8   /* UV4 (fixed) rev 2 */
 
 #ifdef UV1_HUB_IS_SUPPORTED
 static inline int is_uv1_hub(void)
@@ -280,6 +281,19 @@ static inline int is_uv3_hub(void)
 }
 #endif
 
+/* First test "is UV4A", then "is UV4" */
+#ifdef UV4A_HUB_IS_SUPPORTED
+static inline int is_uv4a_hub(void)
+{
+   return (uv_hub_info->hub_revision >= UV4A_HUB_REVISION_BASE);
+}
+#else
+static inline int is_uv4a_hub(void)
+{
+   return 0;
+}
+#endif
+
 #ifdef UV4_HUB_IS_SUPPORTED
 static inline int is_uv4_hub(void)
 {
diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index f113e27..b3afccc 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -99,6 +99,7 @@
 #define UV2_HUB_IS_SUPPORTED   1
 #define UV3_HUB_IS_SUPPORTED   1
 #define UV4_HUB_IS_SUPPORTED   1
+#define UV4A_HUB_IS_SUPPORTED  1
 
 /* Error function to catch undefined references */
 extern unsigned long uv_undefined(char *str);
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index b0ce393..e158722 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -137,6 +137,8 @@ static int __init early_get_pnodeid(void)
case UV3_HUB_PART_NUMBER_X:
uv_min_hub_revision_id += UV3_HUB_REVISION_BASE;
break;
+
+   /* Update: UV4A has only a modified revision to indicate HUB fixes */
case UV4_HUB_PART_NUMBER:
uv_min_hub_revision_id += UV4_HUB_REVISION_BASE - 1;
uv_cpuid.gnode_shift = 2; /* min partition is 4 sockets */
-- 
1.8.2.1

Re: [PATCH 0/7] x86/platform/UV: UV Fix patches for Intel processors

[Mike Travis]

On 12/21/2017 7:39 AM, Mike Travis wrote:
Sigh, has any of this been properly build tested? x86-64 allyesconfig 
produces a

bunch of ugly warnings:



...
I will try this "allyesconfig" though I believe it introduces CONFIG 
items that cause problems where the resultant kernel doesn't boot on a 
UV system.  But if building is the only goal, then we can ignore them.


I found the error and it had already been fixed.  But somehow during the 
hand off for submission, an earlier version was included in this patch.
Unfortunately most everyone is out for a mandatory shutdown (I've been 
working during my last 5 vacation days), so I'm not sure we can push the 
entire patch set again until the new year.


Here's the small change that fixed these warnings that slipped out:

--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -816,7 +816,7 @@ static __init void map_mmioh_high_uv34(i
shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_NASID_MASK;
-   } else if (index == 1) {
+   } else {
id = "MMIOH1";
m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR;
overlay = uv_read_local_mmr(m_overlay);

Would it be possible for you to insert this after...

[PATCH 4/7] x86/platform/UV: Fix GAM MMR changes in UV4A

??

Thanks,
Mike

Re: [PATCH 0/7] x86/platform/UV: UV Fix patches for Intel processors

[Mike Travis]

On 12/21/2017 7:39 AM, Mike Travis wrote:
Sigh, has any of this been properly build tested? x86-64 allyesconfig 
produces a

bunch of ugly warnings:



...
I will try this "allyesconfig" though I believe it introduces CONFIG 
items that cause problems where the resultant kernel doesn't boot on a 
UV system.  But if building is the only goal, then we can ignore them.


I found the error and it had already been fixed.  But somehow during the 
hand off for submission, an earlier version was included in this patch.
Unfortunately most everyone is out for a mandatory shutdown (I've been 
working during my last 5 vacation days), so I'm not sure we can push the 
entire patch set again until the new year.


Here's the small change that fixed these warnings that slipped out:

--- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
+++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -816,7 +816,7 @@ static __init void map_mmioh_high_uv34(i
shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_NASID_MASK;
-   } else if (index == 1) {
+   } else {
id = "MMIOH1";
m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR;
overlay = uv_read_local_mmr(m_overlay);

Would it be possible for you to insert this after...

[PATCH 4/7] x86/platform/UV: Fix GAM MMR changes in UV4A

??

Thanks,
Mike

Re: [PATCH 0/7] x86/platform/UV: UV Fix patches for Intel processors

[Mike Travis]

On 12/21/2017 3:49 AM, Ingo Molnar wrote:


* Mike Travis <tra...@sgi.com> wrote:



This patchset handles the fixes made to the UV4 HUB for upcoming Intel
processors as there are some interface changes.

 * Update uv_mmrs.h to prep for fixed defines for UV4A.

 * Updates to handle UV4 vs. UV4A (fixed) arches.

 * Updates to handle UV4 GAM (global addressable memory) MMRs fixes.

 * Updates to handle UV4 BAU (broadcast assist unit) MMRs fixes.

 * Turn on UV4A_IS_SUPPORTED to enable code and header file fixes.


Sigh, has any of this been properly build tested? x86-64 allyesconfig produces a
bunch of ugly warnings:


Admittedly, we don't have a setup to test too many upstream kernel 
builds with configs other than what our distros are shipping with.  We 
do test build specific earlier kernel releases that are current with the 
distro to insure (or at least understand) back port issues.


I will try this "allyesconfig" though I believe it introduces CONFIG 
items that cause problems where the resultant kernel doesn't boot on a 
UV system.  But if building is the only goal, then we can ignore them.


Are there any other standard configs that are required to build when 
CONFIG_X86_UV is defined?  (Since all of these changes are within the UV 
specific code.)


Thanks,
Mike


In file included from ./include/linux/kernel.h:14:0,
arch/x86/kernel/apic/x2apic_uv_x.c: In function ‘map_mmioh_high_uv34’:
./include/linux/printk.h:308:2: warning: ‘id’ may be used uninitialized in this 
function [-Wmaybe-uninitialized]
arch/x86/kernel/apic/x2apic_uv_x.c:806:8: note: ‘id’ was declared here
In file included from ./include/linux/kernel.h:14:0,
./include/linux/printk.h:308:2: warning: ‘m_io’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
arch/x86/kernel/apic/x2apic_uv_x.c:804:19: note: ‘m_io’ was declared here
In file included from ./include/linux/kernel.h:14:0,
./include/linux/printk.h:308:2: warning: ‘shift’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
arch/x86/kernel/apic/x2apic_uv_x.c:804:12: note: ‘shift’ was declared here
arch/x86/kernel/apic/x2apic_uv_x.c:856:14: warning: ‘n’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
arch/x86/kernel/apic/x2apic_uv_x.c:846:9: warning: ‘nasid_mask’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
In file included from ./include/linux/kernel.h:14:0,
./include/linux/printk.h:308:2: warning: ‘base’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
arch/x86/kernel/apic/x2apic_uv_x.c:801:16: note: ‘base’ was declared here
arch/x86/kernel/apic/x2apic_uv_x.c:843:17: warning: ‘mmr’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
arch/x86/kernel/apic/x2apic_uv_x.c:832:16: warning: ‘overlay’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]

Thanks,

Ingo

Re: [PATCH 0/7] x86/platform/UV: UV Fix patches for Intel processors

[Mike Travis]

On 12/21/2017 3:49 AM, Ingo Molnar wrote:


* Mike Travis  wrote:



This patchset handles the fixes made to the UV4 HUB for upcoming Intel
processors as there are some interface changes.

 * Update uv_mmrs.h to prep for fixed defines for UV4A.

 * Updates to handle UV4 vs. UV4A (fixed) arches.

 * Updates to handle UV4 GAM (global addressable memory) MMRs fixes.

 * Updates to handle UV4 BAU (broadcast assist unit) MMRs fixes.

 * Turn on UV4A_IS_SUPPORTED to enable code and header file fixes.


Sigh, has any of this been properly build tested? x86-64 allyesconfig produces a
bunch of ugly warnings:


Admittedly, we don't have a setup to test too many upstream kernel 
builds with configs other than what our distros are shipping with.  We 
do test build specific earlier kernel releases that are current with the 
distro to insure (or at least understand) back port issues.


I will try this "allyesconfig" though I believe it introduces CONFIG 
items that cause problems where the resultant kernel doesn't boot on a 
UV system.  But if building is the only goal, then we can ignore them.


Are there any other standard configs that are required to build when 
CONFIG_X86_UV is defined?  (Since all of these changes are within the UV 
specific code.)


Thanks,
Mike


In file included from ./include/linux/kernel.h:14:0,
arch/x86/kernel/apic/x2apic_uv_x.c: In function ‘map_mmioh_high_uv34’:
./include/linux/printk.h:308:2: warning: ‘id’ may be used uninitialized in this 
function [-Wmaybe-uninitialized]
arch/x86/kernel/apic/x2apic_uv_x.c:806:8: note: ‘id’ was declared here
In file included from ./include/linux/kernel.h:14:0,
./include/linux/printk.h:308:2: warning: ‘m_io’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
arch/x86/kernel/apic/x2apic_uv_x.c:804:19: note: ‘m_io’ was declared here
In file included from ./include/linux/kernel.h:14:0,
./include/linux/printk.h:308:2: warning: ‘shift’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
arch/x86/kernel/apic/x2apic_uv_x.c:804:12: note: ‘shift’ was declared here
arch/x86/kernel/apic/x2apic_uv_x.c:856:14: warning: ‘n’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
arch/x86/kernel/apic/x2apic_uv_x.c:846:9: warning: ‘nasid_mask’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
In file included from ./include/linux/kernel.h:14:0,
./include/linux/printk.h:308:2: warning: ‘base’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
arch/x86/kernel/apic/x2apic_uv_x.c:801:16: note: ‘base’ was declared here
arch/x86/kernel/apic/x2apic_uv_x.c:843:17: warning: ‘mmr’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
arch/x86/kernel/apic/x2apic_uv_x.c:832:16: warning: ‘overlay’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]

Thanks,

Ingo

[PATCH 2/7] x86/platform/UV: Support for UV4A fixes for new Intel Processors

[Mike Travis]

Upcoming Intel CascadeLake and IceLake processors have some architecture
changes that required fixes in the UV4 HUB bringing that chip to
revision 2.  The nomenclature for that new chip is "UV4A".

This patch fixes the references for the expanded MMR definitions in the
previous (automated) patch.

Signed-off-by: Mike Travis <tra...@sgi.com>
Signed-off-by: Andrew Banman <aban...@hpe.com>
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index e1b8e8b..b0ce393 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -767,6 +767,7 @@ static __init void map_gru_high(int max_pnode)
return;
}
 
+   /* Only UV3 has distributed GRU mode */
if (is_uv3_hub() && gru.s3.mode) {
map_gru_distributed(gru.v);
return;
@@ -816,17 +817,20 @@ struct mmioh_config {
 /* UV3 & UV4 have identical MMIOH overlay configs */
 static __init void map_mmioh_high_uv3(int index, int min_pnode, int max_pnode)
 {
-   union uv3h_rh_gam_mmioh_overlay_config0_mmr_u overlay;
+   union uvh_rh_gam_mmioh_overlay_config0_mmr_u overlay;
unsigned long mmr;
unsigned long base;
+   unsigned long m_overlay;
int i, n, shift, m_io, max_io;
int nasid, lnasid, fi, li;
char *id;
 
id = mmiohs[index].id;
overlay.v = uv_read_local_mmr(mmiohs[index].overlay);
+   m_overlay = mmiohs[index].overlay;
 
-   pr_info("UV: %s overlay 0x%lx base:0x%x m_io:%d\n", id, overlay.v, 
overlay.s3.base, overlay.s3.m_io);
+   pr_info("UV: %s overlay 0x%lx(@0x%lx) base:0x%x m_io:%d\n",
+   id, overlay.v, m_overlay, overlay.s3.base, overlay.s3.m_io);
if (!overlay.s3.enable) {
pr_info("UV: %s disabled\n", id);
return;
@@ -843,10 +847,14 @@ static __init void map_mmioh_high_uv3(int index, int 
min_pnode, int max_pnode)
max_io = lnasid = fi = li = -1;
 
for (i = 0; i < n; i++) {
-   union uv3h_rh_gam_mmioh_redirect_config0_mmr_u redirect;
+   union uvh_rh_gam_mmioh_redirect_config0_mmr_u redirect;
+   unsigned long m_redirect = mmr + i * 8;
 
redirect.v = uv_read_local_mmr(mmr + i * 8);
nasid = redirect.s3.nasid;
+   printk_once(KERN_INFO
+   "UV: %s redirect 0x%lx(@0x%lx) 0x%04x\n",
+   id, redirect.v, m_redirect, nasid);
/* Invalid NASID: */
if (nasid < min_pnode || max_pnode < nasid)
nasid = -1;
-- 
1.8.2.1

[PATCH 2/7] x86/platform/UV: Support for UV4A fixes for new Intel Processors

[Mike Travis]

Upcoming Intel CascadeLake and IceLake processors have some architecture
changes that required fixes in the UV4 HUB bringing that chip to
revision 2.  The nomenclature for that new chip is "UV4A".

This patch fixes the references for the expanded MMR definitions in the
previous (automated) patch.

Signed-off-by: Mike Travis 
Signed-off-by: Andrew Banman 
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index e1b8e8b..b0ce393 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -767,6 +767,7 @@ static __init void map_gru_high(int max_pnode)
return;
}
 
+   /* Only UV3 has distributed GRU mode */
if (is_uv3_hub() && gru.s3.mode) {
map_gru_distributed(gru.v);
return;
@@ -816,17 +817,20 @@ struct mmioh_config {
 /* UV3 & UV4 have identical MMIOH overlay configs */
 static __init void map_mmioh_high_uv3(int index, int min_pnode, int max_pnode)
 {
-   union uv3h_rh_gam_mmioh_overlay_config0_mmr_u overlay;
+   union uvh_rh_gam_mmioh_overlay_config0_mmr_u overlay;
unsigned long mmr;
unsigned long base;
+   unsigned long m_overlay;
int i, n, shift, m_io, max_io;
int nasid, lnasid, fi, li;
char *id;
 
id = mmiohs[index].id;
overlay.v = uv_read_local_mmr(mmiohs[index].overlay);
+   m_overlay = mmiohs[index].overlay;
 
-   pr_info("UV: %s overlay 0x%lx base:0x%x m_io:%d\n", id, overlay.v, 
overlay.s3.base, overlay.s3.m_io);
+   pr_info("UV: %s overlay 0x%lx(@0x%lx) base:0x%x m_io:%d\n",
+   id, overlay.v, m_overlay, overlay.s3.base, overlay.s3.m_io);
if (!overlay.s3.enable) {
pr_info("UV: %s disabled\n", id);
return;
@@ -843,10 +847,14 @@ static __init void map_mmioh_high_uv3(int index, int 
min_pnode, int max_pnode)
max_io = lnasid = fi = li = -1;
 
for (i = 0; i < n; i++) {
-   union uv3h_rh_gam_mmioh_redirect_config0_mmr_u redirect;
+   union uvh_rh_gam_mmioh_redirect_config0_mmr_u redirect;
+   unsigned long m_redirect = mmr + i * 8;
 
redirect.v = uv_read_local_mmr(mmr + i * 8);
nasid = redirect.s3.nasid;
+   printk_once(KERN_INFO
+   "UV: %s redirect 0x%lx(@0x%lx) 0x%04x\n",
+   id, redirect.v, m_redirect, nasid);
/* Invalid NASID: */
if (nasid < min_pnode || max_pnode < nasid)
nasid = -1;
-- 
1.8.2.1

[PATCH 6/7] x86/platform/UV: Fix for UV4A BAU MMRs

[Mike Travis]

Fixes to accommodate Intel Processor changes for UV4A broadcast assist unit
(BAU) MMRs.

Signed-off-by: Mike Travis <tra...@sgi.com>
Signed-off-by: Andrew Banman <aban...@hpe.com>
---
 arch/x86/include/asm/uv/uv_mmrs.h | 59 +--
 1 file changed, 38 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index 30db549..ecb9dde 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -39,9 +39,11 @@
  * #define UV2Hxxx b
  * #define UV3Hxxx c
  * #define UV4Hxxx d
+ * #define UV4AHxxx e
  * #define UVHxxx  (is_uv1_hub() ? UV1Hxxx :
  * (is_uv2_hub() ? UV2Hxxx :
  * (is_uv3_hub() ? UV3Hxxx :
+ * (is_uv4a_hub() ? UV4AHxxx :
  * UV4Hxxx))
  *
  * If the MMR exists on all hub types > 1 but have different addresses, the
@@ -49,8 +51,10 @@
  * #define UV2Hxxx b
  * #define UV3Hxxx c
  * #define UV4Hxxx d
+ * #define UV4AHxxx e
  * #define UVHxxx  (is_uv2_hub() ? UV2Hxxx :
  * (is_uv3_hub() ? UV3Hxxx :
+ * (is_uv4a_hub() ? UV4AHxxx :
  * UV4Hxxx))
  *
  * union uvh_xxx {
@@ -63,6 +67,7 @@
  * } s2;
  * struct uv3h_xxx_s {  # Full UV3 definition (*)
  * } s3;
+ * (NOTE: No struct uv4ah_xxx_s members exist)
  * struct uv4h_xxx_s {  # Full UV4 definition (*)
  * } s4;
  * };
@@ -2780,35 +2785,47 @@
/*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_32)
 
 #define UVH_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_SHFT12
-#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT 49
-#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK 0x7ffeUL
 
+#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
-
+#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
+#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
+#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x3000UL
-
-
-union uvh_lb_bau_sb_descriptor_base_u {
-   unsigned long   v;
-   struct uvh_lb_bau_sb_descriptor_base_s {
-   unsigned long   rsvd_0_11:12;
-   unsigned long   rsvd_12_48:37;
-   unsigned long   node_id:14; /* RW */
-   unsigned long   rsvd_63:1;
-   } s;
-   struct uv4h_lb_bau_sb_descriptor_base_s {
-   unsigned long   rsvd_0_11:12;
-   unsigned long   page_address:34;/* RW */
-   unsigned long   rsvd_46_48:3;
-   unsigned long   node_id:14; /* RW */
-   unsigned long   rsvd_63:1;
-   } s4;
-};
+#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
+
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT   53
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x000ff000UL
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK   0xffe0UL
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :  \
+   /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT)
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :  \
+   /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK)
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :\
+   is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :  \
+   /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BA

[PATCH 6/7] x86/platform/UV: Fix for UV4A BAU MMRs

[Mike Travis]

Fixes to accommodate Intel Processor changes for UV4A broadcast assist unit
(BAU) MMRs.

Signed-off-by: Mike Travis 
Signed-off-by: Andrew Banman 
---
 arch/x86/include/asm/uv/uv_mmrs.h | 59 +--
 1 file changed, 38 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index 30db549..ecb9dde 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -39,9 +39,11 @@
  * #define UV2Hxxx b
  * #define UV3Hxxx c
  * #define UV4Hxxx d
+ * #define UV4AHxxx e
  * #define UVHxxx  (is_uv1_hub() ? UV1Hxxx :
  * (is_uv2_hub() ? UV2Hxxx :
  * (is_uv3_hub() ? UV3Hxxx :
+ * (is_uv4a_hub() ? UV4AHxxx :
  * UV4Hxxx))
  *
  * If the MMR exists on all hub types > 1 but have different addresses, the
@@ -49,8 +51,10 @@
  * #define UV2Hxxx b
  * #define UV3Hxxx c
  * #define UV4Hxxx d
+ * #define UV4AHxxx e
  * #define UVHxxx  (is_uv2_hub() ? UV2Hxxx :
  * (is_uv3_hub() ? UV3Hxxx :
+ * (is_uv4a_hub() ? UV4AHxxx :
  * UV4Hxxx))
  *
  * union uvh_xxx {
@@ -63,6 +67,7 @@
  * } s2;
  * struct uv3h_xxx_s {  # Full UV3 definition (*)
  * } s3;
+ * (NOTE: No struct uv4ah_xxx_s members exist)
  * struct uv4h_xxx_s {  # Full UV4 definition (*)
  * } s4;
  * };
@@ -2780,35 +2785,47 @@
/*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_32)
 
 #define UVH_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_SHFT12
-#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT 49
-#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK 0x7ffeUL
 
+#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
-
+#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
+#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x07fff000UL
+#define UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
 
+#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT49
 #define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x3000UL
-
-
-union uvh_lb_bau_sb_descriptor_base_u {
-   unsigned long   v;
-   struct uvh_lb_bau_sb_descriptor_base_s {
-   unsigned long   rsvd_0_11:12;
-   unsigned long   rsvd_12_48:37;
-   unsigned long   node_id:14; /* RW */
-   unsigned long   rsvd_63:1;
-   } s;
-   struct uv4h_lb_bau_sb_descriptor_base_s {
-   unsigned long   rsvd_0_11:12;
-   unsigned long   page_address:34;/* RW */
-   unsigned long   rsvd_46_48:3;
-   unsigned long   node_id:14; /* RW */
-   unsigned long   rsvd_63:1;
-   } s4;
-};
+#define UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK0x7ffeUL
+
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT   53
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_PAGE_ADDRESS_MASK 0x000ff000UL
+#define UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK   0xffe0UL
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :\
+   is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT :  \
+   /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_SHFT)
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :\
+   is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK :  \
+   /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_PAGE_ADDRESS_MASK)
+
+#define UVH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK (   \
+   is_uv1_hub() ? UV1H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :\
+   is_uv2_hub() ? UV2H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :\
+   is_uv3_hub() ? UV3H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :\
+   is_uv4a_hub() ? UV4AH_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_MASK :  \
+   /*is_uv4_hub*/ UV4H_LB_BAU_SB_DESCRIPTOR_BASE_NODE_ID_M

[PATCH 3/7] x86/platform/UV: Add references to access to fixed UV4A HUB MMRs

[Mike Travis]

Add references to enable access to fixed UV4A (rev2) HUB MMRs.

Signed-off-by: Mike Travis <tra...@sgi.com>
Signed-off-by: Andrew Banman <aban...@hpe.com>
---
 arch/x86/include/asm/uv/uv_hub.h   | 14 ++
 arch/x86/include/asm/uv/uv_mmrs.h  |  1 +
 arch/x86/kernel/apic/x2apic_uv_x.c |  2 ++
 3 files changed, 17 insertions(+)

diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
index 036e26d..44cf6d6 100644
--- a/arch/x86/include/asm/uv/uv_hub.h
+++ b/arch/x86/include/asm/uv/uv_hub.h
@@ -241,6 +241,7 @@ static inline int uv_hub_info_check(int version)
 #define UV2_HUB_REVISION_BASE  3
 #define UV3_HUB_REVISION_BASE  5
 #define UV4_HUB_REVISION_BASE  7
+#define UV4A_HUB_REVISION_BASE 8   /* UV4 (fixed) rev 2 */
 
 #ifdef UV1_HUB_IS_SUPPORTED
 static inline int is_uv1_hub(void)
@@ -280,6 +281,19 @@ static inline int is_uv3_hub(void)
 }
 #endif
 
+/* First test "is UV4A", then "is UV4" */
+#ifdef UV4A_HUB_IS_SUPPORTED
+static inline int is_uv4a_hub(void)
+{
+   return (uv_hub_info->hub_revision >= UV4A_HUB_REVISION_BASE);
+}
+#else
+static inline int is_uv4a_hub(void)
+{
+   return 0;
+}
+#endif
+
 #ifdef UV4_HUB_IS_SUPPORTED
 static inline int is_uv4_hub(void)
 {
diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index f113e27..b3afccc 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -99,6 +99,7 @@
 #define UV2_HUB_IS_SUPPORTED   1
 #define UV3_HUB_IS_SUPPORTED   1
 #define UV4_HUB_IS_SUPPORTED   1
+#define UV4A_HUB_IS_SUPPORTED  1
 
 /* Error function to catch undefined references */
 extern unsigned long uv_undefined(char *str);
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index b0ce393..e158722 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -137,6 +137,8 @@ static int __init early_get_pnodeid(void)
case UV3_HUB_PART_NUMBER_X:
uv_min_hub_revision_id += UV3_HUB_REVISION_BASE;
break;
+
+   /* Update: UV4A has only a modified revision to indicate HUB fixes */
case UV4_HUB_PART_NUMBER:
uv_min_hub_revision_id += UV4_HUB_REVISION_BASE - 1;
uv_cpuid.gnode_shift = 2; /* min partition is 4 sockets */
-- 
1.8.2.1

[PATCH 3/7] x86/platform/UV: Add references to access to fixed UV4A HUB MMRs

[Mike Travis]

Add references to enable access to fixed UV4A (rev2) HUB MMRs.

Signed-off-by: Mike Travis 
Signed-off-by: Andrew Banman 
---
 arch/x86/include/asm/uv/uv_hub.h   | 14 ++
 arch/x86/include/asm/uv/uv_mmrs.h  |  1 +
 arch/x86/kernel/apic/x2apic_uv_x.c |  2 ++
 3 files changed, 17 insertions(+)

diff --git a/arch/x86/include/asm/uv/uv_hub.h b/arch/x86/include/asm/uv/uv_hub.h
index 036e26d..44cf6d6 100644
--- a/arch/x86/include/asm/uv/uv_hub.h
+++ b/arch/x86/include/asm/uv/uv_hub.h
@@ -241,6 +241,7 @@ static inline int uv_hub_info_check(int version)
 #define UV2_HUB_REVISION_BASE  3
 #define UV3_HUB_REVISION_BASE  5
 #define UV4_HUB_REVISION_BASE  7
+#define UV4A_HUB_REVISION_BASE 8   /* UV4 (fixed) rev 2 */
 
 #ifdef UV1_HUB_IS_SUPPORTED
 static inline int is_uv1_hub(void)
@@ -280,6 +281,19 @@ static inline int is_uv3_hub(void)
 }
 #endif
 
+/* First test "is UV4A", then "is UV4" */
+#ifdef UV4A_HUB_IS_SUPPORTED
+static inline int is_uv4a_hub(void)
+{
+   return (uv_hub_info->hub_revision >= UV4A_HUB_REVISION_BASE);
+}
+#else
+static inline int is_uv4a_hub(void)
+{
+   return 0;
+}
+#endif
+
 #ifdef UV4_HUB_IS_SUPPORTED
 static inline int is_uv4_hub(void)
 {
diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index f113e27..b3afccc 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -99,6 +99,7 @@
 #define UV2_HUB_IS_SUPPORTED   1
 #define UV3_HUB_IS_SUPPORTED   1
 #define UV4_HUB_IS_SUPPORTED   1
+#define UV4A_HUB_IS_SUPPORTED  1
 
 /* Error function to catch undefined references */
 extern unsigned long uv_undefined(char *str);
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index b0ce393..e158722 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -137,6 +137,8 @@ static int __init early_get_pnodeid(void)
case UV3_HUB_PART_NUMBER_X:
uv_min_hub_revision_id += UV3_HUB_REVISION_BASE;
break;
+
+   /* Update: UV4A has only a modified revision to indicate HUB fixes */
case UV4_HUB_PART_NUMBER:
uv_min_hub_revision_id += UV4_HUB_REVISION_BASE - 1;
uv_cpuid.gnode_shift = 2; /* min partition is 4 sockets */
-- 
1.8.2.1

[PATCH 0/7] x86/platform/UV: UV Fix patches for Intel processors

[Mike Travis]

This patchset handles the fixes made to the UV4 HUB for upcoming Intel
processors as there are some interface changes.

* Update uv_mmrs.h to prep for fixed defines for UV4A.

* Updates to handle UV4 vs. UV4A (fixed) arches.

* Updates to handle UV4 GAM (global addressable memory) MMRs fixes.

* Updates to handle UV4 BAU (broadcast assist unit) MMRs fixes.

* Turn on UV4A_IS_SUPPORTED to enable code and header file fixes.

[PATCH 0/7] x86/platform/UV: UV Fix patches for Intel processors

[Mike Travis]

This patchset handles the fixes made to the UV4 HUB for upcoming Intel
processors as there are some interface changes.

* Update uv_mmrs.h to prep for fixed defines for UV4A.

* Updates to handle UV4 vs. UV4A (fixed) arches.

* Updates to handle UV4 GAM (global addressable memory) MMRs fixes.

* Updates to handle UV4 BAU (broadcast assist unit) MMRs fixes.

* Turn on UV4A_IS_SUPPORTED to enable code and header file fixes.

[PATCH 1/7] x86/platform/UV: Update uv_mmrs.h to prep for UV4A fixes

[Mike Travis]

Regenerate uv_mmrs.h file to accommodate fixes to UV4A MMRs.

Signed-off-by: Mike Travis <tra...@sgi.com>
Signed-off-by: Andrew Banman <aban...@hpe.com>
---
 arch/x86/include/asm/uv/uv_mmrs.h | 615 +-
 1 file changed, 533 insertions(+), 82 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index 548d684..f113e27 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -3031,6 +3031,41 @@
 #define UVH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
 #define UVH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
 
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
 
 union uvh_rh_gam_alias210_overlay_config_0_mmr_u {
unsigned long   v;
@@ -3042,6 +3077,46 @@
unsigned long   rsvd_53_62:10;
unsigned long   enable:1;   /* RW */
} s;
+   struct uv1h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } s1;
+   struct uvxh_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } sx;
+   struct uv2h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } s2;
+   struct uv3h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } s3;
+   struct uv4h_rh_gam_alias210_overlay_co

[PATCH 1/7] x86/platform/UV: Update uv_mmrs.h to prep for UV4A fixes

[Mike Travis]

Regenerate uv_mmrs.h file to accommodate fixes to UV4A MMRs.

Signed-off-by: Mike Travis 
Signed-off-by: Andrew Banman 
---
 arch/x86/include/asm/uv/uv_mmrs.h | 615 +-
 1 file changed, 533 insertions(+), 82 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index 548d684..f113e27 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -3031,6 +3031,41 @@
 #define UVH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
 #define UVH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
 
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV1H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UVXH_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV2H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV3H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_SHFT 24
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_SHFT 48
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_SHFT 63
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_BASE_MASK 
0xff00UL
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_M_ALIAS_MASK 
0x001fUL
+#define UV4H_RH_GAM_ALIAS210_OVERLAY_CONFIG_0_MMR_ENABLE_MASK 
0x8000UL
+
 
 union uvh_rh_gam_alias210_overlay_config_0_mmr_u {
unsigned long   v;
@@ -3042,6 +3077,46 @@
unsigned long   rsvd_53_62:10;
unsigned long   enable:1;   /* RW */
} s;
+   struct uv1h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } s1;
+   struct uvxh_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } sx;
+   struct uv2h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } s2;
+   struct uv3h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24;
+   unsigned long   base:8; /* RW */
+   unsigned long   rsvd_32_47:16;
+   unsigned long   m_alias:5;  /* RW */
+   unsigned long   rsvd_53_62:10;
+   unsigned long   enable:1;   /* RW */
+   } s3;
+   struct uv4h_rh_gam_alias210_overlay_config_0_mmr_s {
+   unsigned long   rsvd_0_23:24

[PATCH 5/7] x86/platform/UV: Fix GAM MMR references in UV x2apic code

[Mike Travis]

Along with the fixes in UV4A (rev2) MMRs, the code to access those
MMRs also was modified by the fixes.  UV3, UV4, and UV4A no longer
have compatible setups for Global Address Memory (GAM).  Correct the
new mistakes.

Signed-off-by: Mike Travis <tra...@sgi.com>
Signed-off-by: Andrew Banman <aban...@hpe.com>
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 81 --
 1 file changed, 35 insertions(+), 46 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index e158722..5ee0522 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -793,70 +793,59 @@ static __init void map_mmr_high(int max_pnode)
pr_info("UV: MMR disabled\n");
 }
 
-/*
- * This commonality works because both 0 & 1 versions of the MMIOH OVERLAY
- * and REDIRECT MMR regs are exactly the same on UV3.
- */
-struct mmioh_config {
-   unsigned long overlay;
-   unsigned long redirect;
-   char *id;
-};
-
-static __initdata struct mmioh_config mmiohs[] = {
-   {
-   UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR,
-   UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR,
-   "MMIOH0"
-   },
-   {
-   UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR,
-   UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR,
-   "MMIOH1"
-   },
-};
-
-/* UV3 & UV4 have identical MMIOH overlay configs */
-static __init void map_mmioh_high_uv3(int index, int min_pnode, int max_pnode)
+/* UV3/4 have identical MMIOH overlay configs, UV4A is slightly different */
+static __init void map_mmioh_high_uv34(int index, int min_pnode, int max_pnode)
 {
-   union uvh_rh_gam_mmioh_overlay_config0_mmr_u overlay;
+   unsigned long overlay;
unsigned long mmr;
unsigned long base;
+   unsigned long nasid_mask;
unsigned long m_overlay;
int i, n, shift, m_io, max_io;
int nasid, lnasid, fi, li;
char *id;
 
-   id = mmiohs[index].id;
-   overlay.v = uv_read_local_mmr(mmiohs[index].overlay);
-   m_overlay = mmiohs[index].overlay;
-
-   pr_info("UV: %s overlay 0x%lx(@0x%lx) base:0x%x m_io:%d\n",
-   id, overlay.v, m_overlay, overlay.s3.base, overlay.s3.m_io);
-   if (!overlay.s3.enable) {
+   if (index == 0) {
+   id = "MMIOH0";
+   m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR;
+   overlay = uv_read_local_mmr(m_overlay);
+   base = overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK;
+   mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR;
+   m_io = (overlay & 
UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK)
+   >> UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
+   shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
+   n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
+   nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_NASID_MASK;
+   } else if (index == 1) {
+   id = "MMIOH1";
+   m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR;
+   overlay = uv_read_local_mmr(m_overlay);
+   base = overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_MASK;
+   mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR;
+   m_io = (overlay & 
UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK)
+   >> UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT;
+   shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT;
+   n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR_DEPTH;
+   nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR_NASID_MASK;
+   }
+   pr_info("UV: %s overlay 0x%lx base:0x%lx m_io:%d\n", id, overlay, base, 
m_io);
+   if (!(overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK)) {
pr_info("UV: %s disabled\n", id);
return;
}
 
-   shift = UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_SHFT;
-   base = (unsigned long)overlay.s3.base;
-   m_io = overlay.s3.m_io;
-   mmr = mmiohs[index].redirect;
-   n = UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
/* Convert to NASID: */
min_pnode *= 2;
max_pnode *= 2;
max_io = lnasid = fi = li = -1;
 
for (i = 0; i < n; i++) {
-   union uvh_rh_gam_mmioh_redirect_config0_mmr_u redirect;
unsigned long m_redirect = mmr + i * 8;
+   unsigned long redirect = uv_read_local_mmr(m_redirect);
 
-   redirect.v = uv_read_local_mmr(mmr + i * 8);
-   nasid = redirect.s3.nasid;
-   printk_once(KERN_INFO
-   "UV: %s redirect 0x%lx(@0x%lx) 0x%04x\n",
-   id, redirect.v, m_redirect, nasid);
+   

[PATCH 5/7] x86/platform/UV: Fix GAM MMR references in UV x2apic code

[Mike Travis]

Along with the fixes in UV4A (rev2) MMRs, the code to access those
MMRs also was modified by the fixes.  UV3, UV4, and UV4A no longer
have compatible setups for Global Address Memory (GAM).  Correct the
new mistakes.

Signed-off-by: Mike Travis 
Signed-off-by: Andrew Banman 
---
 arch/x86/kernel/apic/x2apic_uv_x.c | 81 --
 1 file changed, 35 insertions(+), 46 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index e158722..5ee0522 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -793,70 +793,59 @@ static __init void map_mmr_high(int max_pnode)
pr_info("UV: MMR disabled\n");
 }
 
-/*
- * This commonality works because both 0 & 1 versions of the MMIOH OVERLAY
- * and REDIRECT MMR regs are exactly the same on UV3.
- */
-struct mmioh_config {
-   unsigned long overlay;
-   unsigned long redirect;
-   char *id;
-};
-
-static __initdata struct mmioh_config mmiohs[] = {
-   {
-   UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR,
-   UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR,
-   "MMIOH0"
-   },
-   {
-   UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR,
-   UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR,
-   "MMIOH1"
-   },
-};
-
-/* UV3 & UV4 have identical MMIOH overlay configs */
-static __init void map_mmioh_high_uv3(int index, int min_pnode, int max_pnode)
+/* UV3/4 have identical MMIOH overlay configs, UV4A is slightly different */
+static __init void map_mmioh_high_uv34(int index, int min_pnode, int max_pnode)
 {
-   union uvh_rh_gam_mmioh_overlay_config0_mmr_u overlay;
+   unsigned long overlay;
unsigned long mmr;
unsigned long base;
+   unsigned long nasid_mask;
unsigned long m_overlay;
int i, n, shift, m_io, max_io;
int nasid, lnasid, fi, li;
char *id;
 
-   id = mmiohs[index].id;
-   overlay.v = uv_read_local_mmr(mmiohs[index].overlay);
-   m_overlay = mmiohs[index].overlay;
-
-   pr_info("UV: %s overlay 0x%lx(@0x%lx) base:0x%x m_io:%d\n",
-   id, overlay.v, m_overlay, overlay.s3.base, overlay.s3.m_io);
-   if (!overlay.s3.enable) {
+   if (index == 0) {
+   id = "MMIOH0";
+   m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR;
+   overlay = uv_read_local_mmr(m_overlay);
+   base = overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK;
+   mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR;
+   m_io = (overlay & 
UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK)
+   >> UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
+   shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT;
+   n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
+   nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_NASID_MASK;
+   } else if (index == 1) {
+   id = "MMIOH1";
+   m_overlay = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR;
+   overlay = uv_read_local_mmr(m_overlay);
+   base = overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_MASK;
+   mmr = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR;
+   m_io = (overlay & 
UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK)
+   >> UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT;
+   shift = UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT;
+   n = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR_DEPTH;
+   nasid_mask = UVH_RH_GAM_MMIOH_REDIRECT_CONFIG1_MMR_NASID_MASK;
+   }
+   pr_info("UV: %s overlay 0x%lx base:0x%lx m_io:%d\n", id, overlay, base, 
m_io);
+   if (!(overlay & UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK)) {
pr_info("UV: %s disabled\n", id);
return;
}
 
-   shift = UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_SHFT;
-   base = (unsigned long)overlay.s3.base;
-   m_io = overlay.s3.m_io;
-   mmr = mmiohs[index].redirect;
-   n = UV3H_RH_GAM_MMIOH_REDIRECT_CONFIG0_MMR_DEPTH;
/* Convert to NASID: */
min_pnode *= 2;
max_pnode *= 2;
max_io = lnasid = fi = li = -1;
 
for (i = 0; i < n; i++) {
-   union uvh_rh_gam_mmioh_redirect_config0_mmr_u redirect;
unsigned long m_redirect = mmr + i * 8;
+   unsigned long redirect = uv_read_local_mmr(m_redirect);
 
-   redirect.v = uv_read_local_mmr(mmr + i * 8);
-   nasid = redirect.s3.nasid;
-   printk_once(KERN_INFO
-   "UV: %s redirect 0x%lx(@0x%lx) 0x%04x\n",
-   id, redirect.v, m_redirect, nasid);
+   nasid = redirect & nasi

[PATCH 4/7] x86/platform/UV: Fix GAM MMR changes in UV4A

[Mike Travis]

Intel processor changes necessitated UV4 HUB Global Address Memory
(GAM) fixes to accommodate support for those processors.  This patch
deals with the updated address range change from 46 to 52 bits in UV4A.

Signed-off-by: Mike Travis <tra...@sgi.com>
Signed-off-by: Andrew Banman <aban...@hpe.com>
---
 arch/x86/include/asm/uv/uv_mmrs.h | 86 ---
 1 file changed, 80 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index b3afccc..30db549 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -3743,7 +3743,6 @@
/*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR)
 
 
-
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_SHFT26
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT46
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_SHFT 63
@@ -3758,6 +3757,30 @@
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK
0x000fc000UL
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK 0x8000UL
 
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT 52
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK 0x000ffc00UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK 0x03f0UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK 0x8000UL
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK ( \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK)
 
 union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
unsigned long   v;
@@ -3777,6 +3800,14 @@
unsigned long   rsvd_56_62:7;
unsigned long   enable:1;   /* RW */
} s4;
+   struct uv4ah_rh_gam_mmioh_overlay_config0_mmr_s {
+   unsigned long   rsvd_0_25:26;
+   unsigned long   base:26;/* RW */
+   unsigned long   m_io:6; /* RW */
+   unsigned long   n_io:4;
+   unsigned long   undef_62:1; /* Undefined */
+   unsigned long   enable:1;   /* RW */
+   } s4a;
 };
 
 /* = */
@@ -3784,8 +3815,8 @@
 /* = */
 #define UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
 #define UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
-#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1604000UL
-#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x484000UL
+#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1603000UL
+#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x483000UL
 #define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR ( \
is_uv1_hub() ? UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR :  \
is_uv2_hub() ? UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR :  \
@@ -3793,7 +3824,6 @@
/*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR)
 
 
-
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_SHFT26
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT46
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_ENABLE_SHFT 63
@@ -3808,6 +3838,24 @@
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK
0x000fc000UL
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_ENABLE_MASK 0x8000UL
 
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT 52
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_MASK 0x000ffc00UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK 0x03f0UL
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMI

[PATCH 4/7] x86/platform/UV: Fix GAM MMR changes in UV4A

[Mike Travis]

Intel processor changes necessitated UV4 HUB Global Address Memory
(GAM) fixes to accommodate support for those processors.  This patch
deals with the updated address range change from 46 to 52 bits in UV4A.

Signed-off-by: Mike Travis 
Signed-off-by: Andrew Banman 
---
 arch/x86/include/asm/uv/uv_mmrs.h | 86 ---
 1 file changed, 80 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv_mmrs.h 
b/arch/x86/include/asm/uv/uv_mmrs.h
index b3afccc..30db549 100644
--- a/arch/x86/include/asm/uv/uv_mmrs.h
+++ b/arch/x86/include/asm/uv/uv_mmrs.h
@@ -3743,7 +3743,6 @@
/*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR)
 
 
-
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_SHFT26
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT46
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_SHFT 63
@@ -3758,6 +3757,30 @@
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK
0x000fc000UL
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK 0x8000UL
 
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT 52
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK 0x000ffc00UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK 0x03f0UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK 0x8000UL
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_SHFT)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_BASE_MASK)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_M_IO_MASK)
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK ( \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK : \
+   is_uv4a_hub() ? UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK : \
+   /*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG0_MMR_ENABLE_MASK)
 
 union uvh_rh_gam_mmioh_overlay_config0_mmr_u {
unsigned long   v;
@@ -3777,6 +3800,14 @@
unsigned long   rsvd_56_62:7;
unsigned long   enable:1;   /* RW */
} s4;
+   struct uv4ah_rh_gam_mmioh_overlay_config0_mmr_s {
+   unsigned long   rsvd_0_25:26;
+   unsigned long   base:26;/* RW */
+   unsigned long   m_io:6; /* RW */
+   unsigned long   n_io:4;
+   unsigned long   undef_62:1; /* Undefined */
+   unsigned long   enable:1;   /* RW */
+   } s4a;
 };
 
 /* = */
@@ -3784,8 +3815,8 @@
 /* = */
 #define UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
 #define UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 
uv_undefined("UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR")
-#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1604000UL
-#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x484000UL
+#define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x1603000UL
+#define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR 0x483000UL
 #define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR ( \
is_uv1_hub() ? UV1H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR :  \
is_uv2_hub() ? UV2H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR :  \
@@ -3793,7 +3824,6 @@
/*is_uv4_hub*/ UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR)
 
 
-
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_SHFT26
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT46
 #define UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_ENABLE_SHFT 63
@@ -3808,6 +3838,24 @@
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK
0x000fc000UL
 #define UV4H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_ENABLE_MASK 0x8000UL
 
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT 52
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_BASE_MASK 0x000ffc00UL
+#define UV4AH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_MASK 0x03f0UL
+
+#define UVH_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT (   \
+   is_uv3_hub() ? UV3H_RH_GAM_MMIOH_OVERLAY_CONFIG1_MMR_M_IO_SHFT : \

Re: [PATCH] x86/platform/UV: make functions uv_handle_nmi and uv_nmi_setup_common static

[Mike Travis]

I know you've already changed it but the UV changes look
fine, so ACK for that.  Thanks.

On 12/6/2017 9:08 AM, Colin King wrote:

From: Colin Ian King 

Functions uv_handle_nmi and uv_nmi_setup_common are local to the
source and do not need to be in global scope, so make them static.

Cleans up sparse warnings:
symbol 'uv_handle_nmi' was not declared. Should it be static?
symbol 'uv_nmi_setup_common' was not declared. Should it be static?

Signed-off-by: Colin Ian King 
---
  arch/x86/platform/uv/uv_nmi.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/platform/uv/uv_nmi.c b/arch/x86/platform/uv/uv_nmi.c
index c34bd8233f7c..5f64f30873e2 100644
--- a/arch/x86/platform/uv/uv_nmi.c
+++ b/arch/x86/platform/uv/uv_nmi.c
@@ -905,7 +905,7 @@ static inline void uv_call_kgdb_kdb(int cpu, struct pt_regs 
*regs, int master)
  /*
   * UV NMI handler
   */
-int uv_handle_nmi(unsigned int reason, struct pt_regs *regs)
+static int uv_handle_nmi(unsigned int reason, struct pt_regs *regs)
  {
struct uv_hub_nmi_s *hub_nmi = uv_hub_nmi;
int cpu = smp_processor_id();
@@ -1013,7 +1013,7 @@ void uv_nmi_init(void)
  }
  
  /* Setup HUB NMI info */

-void __init uv_nmi_setup_common(bool hubbed)
+static void __init uv_nmi_setup_common(bool hubbed)
  {
int size = sizeof(void *) * (1 << NODES_SHIFT);
int cpu;

Re: [PATCH] x86/platform/UV: make functions uv_handle_nmi and uv_nmi_setup_common static

[Mike Travis]

I know you've already changed it but the UV changes look
fine, so ACK for that.  Thanks.

On 12/6/2017 9:08 AM, Colin King wrote:

From: Colin Ian King 

Functions uv_handle_nmi and uv_nmi_setup_common are local to the
source and do not need to be in global scope, so make them static.

Cleans up sparse warnings:
symbol 'uv_handle_nmi' was not declared. Should it be static?
symbol 'uv_nmi_setup_common' was not declared. Should it be static?

Signed-off-by: Colin Ian King 
---
  arch/x86/platform/uv/uv_nmi.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/platform/uv/uv_nmi.c b/arch/x86/platform/uv/uv_nmi.c
index c34bd8233f7c..5f64f30873e2 100644
--- a/arch/x86/platform/uv/uv_nmi.c
+++ b/arch/x86/platform/uv/uv_nmi.c
@@ -905,7 +905,7 @@ static inline void uv_call_kgdb_kdb(int cpu, struct pt_regs 
*regs, int master)
  /*
   * UV NMI handler
   */
-int uv_handle_nmi(unsigned int reason, struct pt_regs *regs)
+static int uv_handle_nmi(unsigned int reason, struct pt_regs *regs)
  {
struct uv_hub_nmi_s *hub_nmi = uv_hub_nmi;
int cpu = smp_processor_id();
@@ -1013,7 +1013,7 @@ void uv_nmi_init(void)
  }
  
  /* Setup HUB NMI info */

-void __init uv_nmi_setup_common(bool hubbed)
+static void __init uv_nmi_setup_common(bool hubbed)
  {
int size = sizeof(void *) * (1 << NODES_SHIFT);
int cpu;

Re: [PATCH 2/5] x86/kernel: Skip TSC test and error messages if already unstable

[Mike Travis]

On 10/12/2017 8:22 AM, Thomas Gleixner wrote:

On Thu, 12 Oct 2017, Mike Travis wrote:

On 10/12/2017 4:17 AM, Thomas Gleixner wrote:

On Thu, 5 Oct 2017, mike.tra...@hpe.com wrote:

@@ -89,6 +93,10 @@ bool tsc_store_and_check_tsc_adjust(bool
if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
return false;
   +/* Skip unnecessary error messages if TSC already unstable */
+   if (check_tsc_unstable())
+   return false;
+
rdmsrl(MSR_IA32_TSC_ADJUST, bootval);
cur->bootval = bootval;
cur->adjusted = bootval;


This hunk rejects and I really can't figure out against which tree that
would apply.


My current merge tree happens to be 4.13.0-rc1 which was the latest when I
started this patch submission.  I can update my merge tree and reapply if need
be?


Please send patches always against top of tree and not some random ancient
version of it.



I pulled in 4.14.0-rc4 and reapplied the patches and they went in
without conflict.  Hopefully it will be the same for you.

(And dealt with your question about applying the same change to
the !CONFIG_SMP case.)

Thanks,
Mike

Re: [PATCH 2/5] x86/kernel: Skip TSC test and error messages if already unstable

[Mike Travis]

On 10/12/2017 8:22 AM, Thomas Gleixner wrote:

On Thu, 12 Oct 2017, Mike Travis wrote:

On 10/12/2017 4:17 AM, Thomas Gleixner wrote:

On Thu, 5 Oct 2017, mike.tra...@hpe.com wrote:

@@ -89,6 +93,10 @@ bool tsc_store_and_check_tsc_adjust(bool
if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
return false;
   +/* Skip unnecessary error messages if TSC already unstable */
+   if (check_tsc_unstable())
+   return false;
+
rdmsrl(MSR_IA32_TSC_ADJUST, bootval);
cur->bootval = bootval;
cur->adjusted = bootval;


This hunk rejects and I really can't figure out against which tree that
would apply.


My current merge tree happens to be 4.13.0-rc1 which was the latest when I
started this patch submission.  I can update my merge tree and reapply if need
be?


Please send patches always against top of tree and not some random ancient
version of it.



I pulled in 4.14.0-rc4 and reapplied the patches and they went in
without conflict.  Hopefully it will be the same for you.

(And dealt with your question about applying the same change to
the !CONFIG_SMP case.)

Thanks,
Mike

Re: [PATCH 2/5] x86/kernel: Skip TSC test and error messages if already unstable

[Mike Travis]

On 10/12/2017 4:17 AM, Thomas Gleixner wrote:

On Thu, 5 Oct 2017, mike.tra...@hpe.com wrote:


If the TSC has already been determined to be unstable, then checking
TSC ADJUST values is a waste of time and generates unnecessary error
messages.

Signed-off-by: Mike Travis <mike.tra...@hpe.com>
Reviewed-by: Dimitri Sivanich <dimitri.sivan...@hpe.com>
Reviewed-by: Russ Anderson <russ.ander...@hpe.com>
Reviewed-by: Peter Zijlstra <pet...@infradead.org>
---
  arch/x86/kernel/tsc_sync.c |8 
  1 file changed, 8 insertions(+)

--- linux.orig/arch/x86/kernel/tsc_sync.c
+++ linux/arch/x86/kernel/tsc_sync.c
@@ -38,6 +38,10 @@ void tsc_verify_tsc_adjust(bool resume)
if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
return;
  
+	/* Skip unnecessary error messages if TSC already unstable */

+   if (check_tsc_unstable())
+   return;
+
/* Rate limit the MSR check */
if (!resume && time_before(jiffies, adj->nextcheck))
return;
@@ -89,6 +93,10 @@ bool tsc_store_and_check_tsc_adjust(bool
if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
return false;
  
+	/* Skip unnecessary error messages if TSC already unstable */

+   if (check_tsc_unstable())
+   return false;
+
rdmsrl(MSR_IA32_TSC_ADJUST, bootval);
cur->bootval = bootval;
cur->adjusted = bootval;


This hunk rejects and I really can't figure out against which tree that
would apply.


My current merge tree happens to be 4.13.0-rc1 which was the latest when 
I started this patch submission.  I can update my merge tree and reapply 
if need be?




Btw, there are two incarnations of tsc_store_and_check_tsc_adjust().
Shouldn't the !SMP variant get the same treatment?


I could add it though I'm not sure the point?  If it's only one CPU 
would TSC's being out of sync become a question?


Thanks,

tglx

Re: [PATCH 2/5] x86/kernel: Skip TSC test and error messages if already unstable

[Mike Travis]

On 10/12/2017 4:17 AM, Thomas Gleixner wrote:

On Thu, 5 Oct 2017, mike.tra...@hpe.com wrote:


If the TSC has already been determined to be unstable, then checking
TSC ADJUST values is a waste of time and generates unnecessary error
messages.

Signed-off-by: Mike Travis 
Reviewed-by: Dimitri Sivanich 
Reviewed-by: Russ Anderson 
Reviewed-by: Peter Zijlstra 
---
  arch/x86/kernel/tsc_sync.c |8 
  1 file changed, 8 insertions(+)

--- linux.orig/arch/x86/kernel/tsc_sync.c
+++ linux/arch/x86/kernel/tsc_sync.c
@@ -38,6 +38,10 @@ void tsc_verify_tsc_adjust(bool resume)
if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
return;
  
+	/* Skip unnecessary error messages if TSC already unstable */

+   if (check_tsc_unstable())
+   return;
+
/* Rate limit the MSR check */
if (!resume && time_before(jiffies, adj->nextcheck))
return;
@@ -89,6 +93,10 @@ bool tsc_store_and_check_tsc_adjust(bool
if (!boot_cpu_has(X86_FEATURE_TSC_ADJUST))
return false;
  
+	/* Skip unnecessary error messages if TSC already unstable */

+   if (check_tsc_unstable())
+   return false;
+
rdmsrl(MSR_IA32_TSC_ADJUST, bootval);
cur->bootval = bootval;
cur->adjusted = bootval;


This hunk rejects and I really can't figure out against which tree that
would apply.


My current merge tree happens to be 4.13.0-rc1 which was the latest when 
I started this patch submission.  I can update my merge tree and reapply 
if need be?




Btw, there are two incarnations of tsc_store_and_check_tsc_adjust().
Shouldn't the !SMP variant get the same treatment?


I could add it though I'm not sure the point?  If it's only one CPU 
would TSC's being out of sync become a question?


Thanks,

tglx

Re: [PATCH 4/5] x86/kernel: Provide a means to disable TSC ART

[Mike Travis]

On 10/4/2017 2:27 AM, Peter Zijlstra wrote:

On Mon, Oct 02, 2017 at 10:12:18AM -0500, mike.tra...@hpe.com wrote:

  static void detect_art(void)
  {
unsigned int unused[2];
  
-	if (boot_cpu_data.cpuid_level < ART_CPUID_LEAF)

+   if (boot_cpu_data.cpuid_level < ART_CPUID_LEAF || tsc_art_disabled)
return;
  
  	/* Don't enable ART in a VM, non-stop TSC and TSC_ADJUST required */



So why can't we use is_uv_system() here an for the tsc_adjust thing?


I could.  I just thought that there may be future system arches that
need the same facility?


Also (and I hate the name) tsc_multi_sync_resets is the reason you
cannot use ART, I don't think it makes sense to introduce yet another
knob.


Okay.  I wasn't sure if there might be different causes for wanting one
condition over the other.  So does this mean change this later test to
use is_uv_system() or tsc_multi_sync_resets?

Thanks.

Re: [PATCH 4/5] x86/kernel: Provide a means to disable TSC ART

[Mike Travis]

On 10/4/2017 2:27 AM, Peter Zijlstra wrote:

On Mon, Oct 02, 2017 at 10:12:18AM -0500, mike.tra...@hpe.com wrote:

  static void detect_art(void)
  {
unsigned int unused[2];
  
-	if (boot_cpu_data.cpuid_level < ART_CPUID_LEAF)

+   if (boot_cpu_data.cpuid_level < ART_CPUID_LEAF || tsc_art_disabled)
return;
  
  	/* Don't enable ART in a VM, non-stop TSC and TSC_ADJUST required */



So why can't we use is_uv_system() here an for the tsc_adjust thing?


I could.  I just thought that there may be future system arches that
need the same facility?


Also (and I hate the name) tsc_multi_sync_resets is the reason you
cannot use ART, I don't think it makes sense to introduce yet another
knob.


Okay.  I wasn't sure if there might be different causes for wanting one
condition over the other.  So does this mean change this later test to
use is_uv_system() or tsc_multi_sync_resets?

Thanks.

Re: [PATCH 0/4] x86/platform/UV: Update TSC support

[Mike Travis]

On 9/29/2017 9:23 AM, Peter Zijlstra wrote:

On Fri, Sep 29, 2017 at 08:19:22AM -0700, Mike Travis wrote:

So I would still like to get clarification on how ART works (or likely
doesn't) on your systems. I think for now its fairly prudent to kill
detect_art() on UV.


I tested with both detect_art enabled and disabled and didn't notice a
difference though I wasn't sure what test to run to verify whether it was
being used or not.  (I'd be glad to run some specific test if one can be
suggested?)  The num/denom setting for a 2100Mhz CPU was 168/2 if that
information helps?


While ART has a ratio to TSC, it too has an absolute relation to it.
Given an ART time stamp we can compute a TSC value and vice versa, this
allows correlating device timestamps (Network, Audio/Video etc..) with
CPU time stamps.

Per detect_art() we have a single system wide offset, namely:

   rdmsrl(MSR_IA32_TSC_ADJUST, art_to_tsc_offset);

But you use TSC_ADJUST to sync between your cabinets, this cannot ever
be right. The ART clock of the other cabinets (those that did not run
detect_art) will have a different offset.

Currently there are only two device drivers that use ART:

   drivers/net/ethernet/intel/e1000e/ptp.c:*system = 
convert_art_to_tsc(sys_cycles);
   sound/pci/hda/hda_controller.c: *system = convert_art_to_tsc(tsc_counter);

Outside of that nobody cares, _for_now_.


I'm checking with the hardware/firmware designers but your mention of 
e1000e reminded me that I did see this but didn't quite connect the 
meaning.  If it's really a system wide constant, then yes we cannot 
provide a single value that would apply to all CPU's.




I'm not sure if there's a means for the CPU to read ART in order to test
this correlation.

Intel SDM Vol 3B 17.17.4 speaks of 'K' with a footnote about TSC_ADJUST
and the VMCS TSC fields. But basically both TSC and ART start at 0 on
power on and given the frequency ratio 'K' is a known for native system
agents.

Again, I would suggest killing detect_art() (and the setting of
X86_FEATURE_ART) on UV systems until things are worked out. Also, given
you have your own distributed clock, I'm thinking you use that on your
own devices, obviating the immediate need for ART.


Also, while indeed not strictly required, that TSC_ADJUST==0 test on
bootcpu is nice for consumer systems, BIOS did something 'weird' if that
is not true. Is something like is_uv_system() available early enough?


My previous version of the patches had me setting a flag that could be
checked by the tsc_sanitize_first_cpu() function and disable the requirement
of "TSC == 0 on socket 0" for any arch that specified it.
(And UV did set that flag.)

But Thomas said it was "hackery" and that TSC being 0 on socket 0 was no
longer a requirement.  So I took it out for this version and made the "TSC
== 0 on socket 0" no longer the default for any arch.


That's where it comes from. But normal systems really _should_ have it
at 0 and its a useful sanity check IMO. We really want to know when the
BIOS does a funny behind our backs.



How about a more generic flag, such as "multi_tsc_sync_sources"?  That 
could trigger both disabling the "TSC == 0 on socket 0" check as well as 
disabling X86_FEATURE_ART where appropriate?  Or I could clear the 
feature ART cap separately in the UV system init code if they are not 
really related?

Re: [PATCH 0/4] x86/platform/UV: Update TSC support

[Mike Travis]

On 9/29/2017 9:23 AM, Peter Zijlstra wrote:

On Fri, Sep 29, 2017 at 08:19:22AM -0700, Mike Travis wrote:

So I would still like to get clarification on how ART works (or likely
doesn't) on your systems. I think for now its fairly prudent to kill
detect_art() on UV.


I tested with both detect_art enabled and disabled and didn't notice a
difference though I wasn't sure what test to run to verify whether it was
being used or not.  (I'd be glad to run some specific test if one can be
suggested?)  The num/denom setting for a 2100Mhz CPU was 168/2 if that
information helps?


While ART has a ratio to TSC, it too has an absolute relation to it.
Given an ART time stamp we can compute a TSC value and vice versa, this
allows correlating device timestamps (Network, Audio/Video etc..) with
CPU time stamps.

Per detect_art() we have a single system wide offset, namely:

   rdmsrl(MSR_IA32_TSC_ADJUST, art_to_tsc_offset);

But you use TSC_ADJUST to sync between your cabinets, this cannot ever
be right. The ART clock of the other cabinets (those that did not run
detect_art) will have a different offset.

Currently there are only two device drivers that use ART:

   drivers/net/ethernet/intel/e1000e/ptp.c:*system = 
convert_art_to_tsc(sys_cycles);
   sound/pci/hda/hda_controller.c: *system = convert_art_to_tsc(tsc_counter);

Outside of that nobody cares, _for_now_.


I'm checking with the hardware/firmware designers but your mention of 
e1000e reminded me that I did see this but didn't quite connect the 
meaning.  If it's really a system wide constant, then yes we cannot 
provide a single value that would apply to all CPU's.




I'm not sure if there's a means for the CPU to read ART in order to test
this correlation.

Intel SDM Vol 3B 17.17.4 speaks of 'K' with a footnote about TSC_ADJUST
and the VMCS TSC fields. But basically both TSC and ART start at 0 on
power on and given the frequency ratio 'K' is a known for native system
agents.

Again, I would suggest killing detect_art() (and the setting of
X86_FEATURE_ART) on UV systems until things are worked out. Also, given
you have your own distributed clock, I'm thinking you use that on your
own devices, obviating the immediate need for ART.


Also, while indeed not strictly required, that TSC_ADJUST==0 test on
bootcpu is nice for consumer systems, BIOS did something 'weird' if that
is not true. Is something like is_uv_system() available early enough?


My previous version of the patches had me setting a flag that could be
checked by the tsc_sanitize_first_cpu() function and disable the requirement
of "TSC == 0 on socket 0" for any arch that specified it.
(And UV did set that flag.)

But Thomas said it was "hackery" and that TSC being 0 on socket 0 was no
longer a requirement.  So I took it out for this version and made the "TSC
== 0 on socket 0" no longer the default for any arch.


That's where it comes from. But normal systems really _should_ have it
at 0 and its a useful sanity check IMO. We really want to know when the
BIOS does a funny behind our backs.



How about a more generic flag, such as "multi_tsc_sync_sources"?  That 
could trigger both disabling the "TSC == 0 on socket 0" check as well as 
disabling X86_FEATURE_ART where appropriate?  Or I could clear the 
feature ART cap separately in the UV system init code if they are not 
really related?

Re: [PATCH 0/4] x86/platform/UV: Update TSC support

[Mike Travis]

On 9/29/2017 1:46 AM, Peter Zijlstra wrote:

On Thu, Sep 28, 2017 at 01:03:39PM -0500, mike.tra...@hpe.com wrote:


The UV BIOS goes to considerable effort to get the TSC synchronization
accurate across the entire system.  Included in that are multiple chassis
that can have 32+ sockets.  The architecture does support an external
high resolution clock to aid in maintaining this synchronization.

The resulting TSC accuracy set by the UV system BIOS is much better
than the generic kernel TSC ADJUST functions.  This is important for
applications that read the TSC values directly for accessing data bases.

*   These patches disable an assumption made by the kernel tsc sync
 functions that Socket 0 in the system should have a TSC ADJUST
 value of zero.  This is not correct when the chassis are reset
 asynchronously to each other so which TSC's should be zero is
 not predictable.

*   When the system BIOS determines that the TSC is not stable, it then
 sets a flag so the UV kernel setup can set the "tsc is unstable"
 flag.  A patch now prevents the kernel from attempting to fix the
 TSC causing a slew of warning messages.

*   It also eliminates another avalanche of warning messages from older
 BIOS that did not have the TSC ADJUST MSR (ex. >3000 msgs in a 32
 socket Skylake system).  It now notes this with a single warning
 message and then moves on with fixing them.


So I would still like to get clarification on how ART works (or likely
doesn't) on your systems. I think for now its fairly prudent to kill
detect_art() on UV.


I tested with both detect_art enabled and disabled and didn't notice a 
difference though I wasn't sure what test to run to verify whether it 
was being used or not.  (I'd be glad to run some specific test if one 
can be suggested?)  The num/denom setting for a 2100Mhz CPU was 168/2 if 
that information helps?



Also, while indeed not strictly required, that TSC_ADJUST==0 test on
bootcpu is nice for consumer systems, BIOS did something 'weird' if that
is not true. Is something like is_uv_system() available early enough?


My previous version of the patches had me setting a flag that could be 
checked by the tsc_sanitize_first_cpu() function and disable the 
requirement of "TSC == 0 on socket 0" for any arch that specified it.

(And UV did set that flag.)

But Thomas said it was "hackery" and that TSC being 0 on socket 0 was no 
longer a requirement.  So I took it out for this version and made the 
"TSC == 0 on socket 0" no longer the default for any arch.


Other than that, the patches look good to me.

Re: [PATCH 0/4] x86/platform/UV: Update TSC support

[Mike Travis]

On 9/29/2017 1:46 AM, Peter Zijlstra wrote:

On Thu, Sep 28, 2017 at 01:03:39PM -0500, mike.tra...@hpe.com wrote:


The UV BIOS goes to considerable effort to get the TSC synchronization
accurate across the entire system.  Included in that are multiple chassis
that can have 32+ sockets.  The architecture does support an external
high resolution clock to aid in maintaining this synchronization.

The resulting TSC accuracy set by the UV system BIOS is much better
than the generic kernel TSC ADJUST functions.  This is important for
applications that read the TSC values directly for accessing data bases.

*   These patches disable an assumption made by the kernel tsc sync
 functions that Socket 0 in the system should have a TSC ADJUST
 value of zero.  This is not correct when the chassis are reset
 asynchronously to each other so which TSC's should be zero is
 not predictable.

*   When the system BIOS determines that the TSC is not stable, it then
 sets a flag so the UV kernel setup can set the "tsc is unstable"
 flag.  A patch now prevents the kernel from attempting to fix the
 TSC causing a slew of warning messages.

*   It also eliminates another avalanche of warning messages from older
 BIOS that did not have the TSC ADJUST MSR (ex. >3000 msgs in a 32
 socket Skylake system).  It now notes this with a single warning
 message and then moves on with fixing them.


So I would still like to get clarification on how ART works (or likely
doesn't) on your systems. I think for now its fairly prudent to kill
detect_art() on UV.


I tested with both detect_art enabled and disabled and didn't notice a 
difference though I wasn't sure what test to run to verify whether it 
was being used or not.  (I'd be glad to run some specific test if one 
can be suggested?)  The num/denom setting for a 2100Mhz CPU was 168/2 if 
that information helps?



Also, while indeed not strictly required, that TSC_ADJUST==0 test on
bootcpu is nice for consumer systems, BIOS did something 'weird' if that
is not true. Is something like is_uv_system() available early enough?


My previous version of the patches had me setting a flag that could be 
checked by the tsc_sanitize_first_cpu() function and disable the 
requirement of "TSC == 0 on socket 0" for any arch that specified it.

(And UV did set that flag.)

But Thomas said it was "hackery" and that TSC being 0 on socket 0 was no 
longer a requirement.  So I took it out for this version and made the 
"TSC == 0 on socket 0" no longer the default for any arch.


Other than that, the patches look good to me.

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

[Mike Travis]

On 9/28/2017 2:01 AM, Ingo Molnar wrote:


* Baoquan He  wrote:


Hi Ingo,

On 09/28/17 at 09:56am, Ingo Molnar wrote:

diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index af599167fe3c..4d68c08df82d 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -27,6 +27,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #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())
kaslr_regions[0].size_tb = memory_tb;

This is really an ugly hack. Is kaslr_regions[] incorrect? If so then it should 
be
corrected instead of uglifying the code that uses it...


Thanks for looking into this!

If on SGI UV system, the kaslr_regions[0].size_tb, namely the size of
the direct mapping section, is incorrect.

Its direct mapping size includes two parts:
#1 RAM size of system
#2 MMIOH region size which only SGI UV system has.

However, the #2 can only be got till uv_system_init() is called in
native_smp_prepare_cpus(). That is too late for mm KASLR calculation.
That's why I made this hack.

I checked uv_system_init() code, seems not easy to know the size of
MMIOH region before or inside kernel_randomize_memory(). I have CCed UV
devel experts, not sure if they have any idea about this. Otherwise,
this patch could be the only way I can think of.

Hi Mike and Russ,

Is there any chance we can get the size of MMIOH region before mm KASLR
code, namely before we call kernel_randomize_memory()?


The sizes of the MMIOL and MMIOH areas are tied into the HUB design and 
how it is communicated to BIOS and the kernel.  This is via some of the 
config MMR's found in the HUB and it would be impossible to provide any 
access to these registers as they change with each new UV architecture.


The kernel does reserve the memory in the EFI memmap.  I can send you a 
console log of the full startup that includes the MMIOH reservations. 
Note that it is dependent on what I/O devices are actually present as UV 
does not map empty slots unless forced (because we'd quickly run out of 
resources.)  Also, the EFI memmap entries do not specify the exact usage 
of the contained areas.




I don't mind system specific quirks to hardware enumeration details, as long as
they don't pollute generic code with such special hacks.

I.e. in this case it's wrong to allow kaslr_regions[0].size_tb to be wrong. Any
other code that relies on it in the future will be wrong as well on UV systems.


Which may come into play on other arches with the new upcoming memory 
technologies.


The right quirk would be to fix that up where it gets introduced, or something
like that.


Yes, does make sense.


Thanks,

Ingo

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

[Mike Travis]

On 9/28/2017 2:01 AM, Ingo Molnar wrote:


* Baoquan He  wrote:


Hi Ingo,

On 09/28/17 at 09:56am, Ingo Molnar wrote:

diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index af599167fe3c..4d68c08df82d 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -27,6 +27,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #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())
kaslr_regions[0].size_tb = memory_tb;

This is really an ugly hack. Is kaslr_regions[] incorrect? If so then it should 
be
corrected instead of uglifying the code that uses it...


Thanks for looking into this!

If on SGI UV system, the kaslr_regions[0].size_tb, namely the size of
the direct mapping section, is incorrect.

Its direct mapping size includes two parts:
#1 RAM size of system
#2 MMIOH region size which only SGI UV system has.

However, the #2 can only be got till uv_system_init() is called in
native_smp_prepare_cpus(). That is too late for mm KASLR calculation.
That's why I made this hack.

I checked uv_system_init() code, seems not easy to know the size of
MMIOH region before or inside kernel_randomize_memory(). I have CCed UV
devel experts, not sure if they have any idea about this. Otherwise,
this patch could be the only way I can think of.

Hi Mike and Russ,

Is there any chance we can get the size of MMIOH region before mm KASLR
code, namely before we call kernel_randomize_memory()?


The sizes of the MMIOL and MMIOH areas are tied into the HUB design and 
how it is communicated to BIOS and the kernel.  This is via some of the 
config MMR's found in the HUB and it would be impossible to provide any 
access to these registers as they change with each new UV architecture.


The kernel does reserve the memory in the EFI memmap.  I can send you a 
console log of the full startup that includes the MMIOH reservations. 
Note that it is dependent on what I/O devices are actually present as UV 
does not map empty slots unless forced (because we'd quickly run out of 
resources.)  Also, the EFI memmap entries do not specify the exact usage 
of the contained areas.




I don't mind system specific quirks to hardware enumeration details, as long as
they don't pollute generic code with such special hacks.

I.e. in this case it's wrong to allow kaslr_regions[0].size_tb to be wrong. Any
other code that relies on it in the future will be wrong as well on UV systems.


Which may come into play on other arches with the new upcoming memory 
technologies.


The right quirk would be to fix that up where it gets introduced, or something
like that.


Yes, does make sense.


Thanks,

Ingo

Re: [PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being non-null is valid

[Mike Travis]

On 9/25/2017 11:10 AM, Thomas Gleixner wrote:

On Mon, 25 Sep 2017, Mike Travis wrote:

On 9/25/2017 8:30 AM, Thomas Gleixner wrote:

Aside of that I really do not like this kind of special case hackery. The
real question is whether we need to enforce TSC_ADJUST == 0 on the boot cpu
at all. In principle we don't anymore now that we handle that TSC deadline
timer wreckage cleanly.


I am hesitant to make such a global change as it appears the author
intentionally added this.  It not only caused our internal tsc sync tests to
become totally out of whack, it also generated an avalanche of error messages
to the system console (>3000 messages for a 32 socket Skylake system).  And I
don't have the means to test how major changes to the TSC adjust functions
will affect standard whitebox PC's.


The reason why I put it there in the first place was to make the TSC
deadline timer work on a whole range of systems. It turned out that our
'fix' was not enough so we changed that later to disable the deadline timer
completely on affected systems when the firmware does not contain a fix for
it. So there is no real technical reason anymore to enforce TSC_ADJUST == 0
on the boot CPU. So rather than special casing this for UV we should just
remove that requirement and leave the boot value as is.


Okay, I could do that but as I mentioned I'm not comfortable changing 
code that I cannot personally verify is correct.  I'm assuming you only 
mean removing the part where socket 0 should have a TSC_ADJUST value of 
0?  And the part mentioned below that all cpu threads on a socket should 
have the same adjust values should not be changed?



Our BIOS team did make a change to conform to the "TSC_ADJUST should be the
same on all cpu threads on a single socket" requirement, so we were able to
pass that part of the TSC validation functions.  (Prior to this, the TSC's
were synced by writing directly to the TSC MSR and natural delays in the
processor firmware caused the slight differences in the TSC ADJUST values.)


Right. TSC_ADJUST is there for a reason.


Well, there is the problem with bit 63 (sign bit) in the TSC ADJUST MSR. 
So it's almost there... :)



But the UV 'boot chassis at different times' brings me to a related
question:


Essentially what happens is the system reset signals are distributed in
various ways which cause the different chassis to start up asynchronously with
each other.  The UV system is not "hard" bound to each other but adapts to the
system configuration as it starts up.


I figured that much.


How is this setup dealing with ART (Always Running Timer, which is
distributed over PCIe for hardware timestamping and hardware assisted event
correlation)?

I assume that ART on UV is also per chassis, but that means that the
documented relation ship of:

TSC = ART * n/d + offset

where $offset is system wide (the TSC_ADJUST value of the boot cpu), is
not applicable.

Is there some other magic in play which makes ART work across chassis?

Thanks,

tglx



Sorry, I'm not sure how the UV hardware mimics the concept of 'ART'.  It does
have an external clock generator that is distributed as part of the NumaLink
protocol and signal set.  Since separate chassis can be configured to be
either within the same SSI or in separate SSI's then it has the ability to
configure which chassis are in sync with each other and which are on a
different clock sync.  This is all within the purview of the BIOS folks.


Cute. How is that supposed to work, when the chassis are out of sync?


Huh?  The TSC's are only guaranteed to be synced within an SSI.  As long 
as the sockets in the same SSI share a common clock, the BIOS can 
synchronize the TSC's to be very, very close.



We do have independent methods to verify if TSCs' are in sync with each other
by measuring the skew rate.  Typical deviations on UV are within a two digit
clock tick spread, which at an Uncore frequency of 2.5Ghz is in the small
single digit or less nanosecond range.


That should be good enough to pass the kernel side tests.

But back to my question about ART. You might talk to your BIOS/HW folks
about that and eventually disable the ART related functionality in the
kernel on UV.


Once again, I'm not sure what code you are talking about.  I talked to 
the BIOS engineer specifically working on TSC related items and he was 
also not familiar with the Intel ART spec.  I could go farther up the 
chain to the hardware designers but right now this would be extremely 
low on their priority queue.


Perhaps if you were more specific in what code should be disabled?  We 
would like to keep as much as the self check code as possible as there 
are still some remotely possible failure cases.  And removing the self 
checks would have a negative impact on reliability.


I actually did test using the CPU flags, "TSC reliable" and no "TSC 
ADJUST" to prevent the kernel from overwriting the already correct TS

Re: [PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being non-null is valid

[Mike Travis]

On 9/25/2017 11:10 AM, Thomas Gleixner wrote:

On Mon, 25 Sep 2017, Mike Travis wrote:

On 9/25/2017 8:30 AM, Thomas Gleixner wrote:

Aside of that I really do not like this kind of special case hackery. The
real question is whether we need to enforce TSC_ADJUST == 0 on the boot cpu
at all. In principle we don't anymore now that we handle that TSC deadline
timer wreckage cleanly.


I am hesitant to make such a global change as it appears the author
intentionally added this.  It not only caused our internal tsc sync tests to
become totally out of whack, it also generated an avalanche of error messages
to the system console (>3000 messages for a 32 socket Skylake system).  And I
don't have the means to test how major changes to the TSC adjust functions
will affect standard whitebox PC's.


The reason why I put it there in the first place was to make the TSC
deadline timer work on a whole range of systems. It turned out that our
'fix' was not enough so we changed that later to disable the deadline timer
completely on affected systems when the firmware does not contain a fix for
it. So there is no real technical reason anymore to enforce TSC_ADJUST == 0
on the boot CPU. So rather than special casing this for UV we should just
remove that requirement and leave the boot value as is.


Okay, I could do that but as I mentioned I'm not comfortable changing 
code that I cannot personally verify is correct.  I'm assuming you only 
mean removing the part where socket 0 should have a TSC_ADJUST value of 
0?  And the part mentioned below that all cpu threads on a socket should 
have the same adjust values should not be changed?



Our BIOS team did make a change to conform to the "TSC_ADJUST should be the
same on all cpu threads on a single socket" requirement, so we were able to
pass that part of the TSC validation functions.  (Prior to this, the TSC's
were synced by writing directly to the TSC MSR and natural delays in the
processor firmware caused the slight differences in the TSC ADJUST values.)


Right. TSC_ADJUST is there for a reason.


Well, there is the problem with bit 63 (sign bit) in the TSC ADJUST MSR. 
So it's almost there... :)



But the UV 'boot chassis at different times' brings me to a related
question:


Essentially what happens is the system reset signals are distributed in
various ways which cause the different chassis to start up asynchronously with
each other.  The UV system is not "hard" bound to each other but adapts to the
system configuration as it starts up.


I figured that much.


How is this setup dealing with ART (Always Running Timer, which is
distributed over PCIe for hardware timestamping and hardware assisted event
correlation)?

I assume that ART on UV is also per chassis, but that means that the
documented relation ship of:

TSC = ART * n/d + offset

where $offset is system wide (the TSC_ADJUST value of the boot cpu), is
not applicable.

Is there some other magic in play which makes ART work across chassis?

Thanks,

tglx



Sorry, I'm not sure how the UV hardware mimics the concept of 'ART'.  It does
have an external clock generator that is distributed as part of the NumaLink
protocol and signal set.  Since separate chassis can be configured to be
either within the same SSI or in separate SSI's then it has the ability to
configure which chassis are in sync with each other and which are on a
different clock sync.  This is all within the purview of the BIOS folks.


Cute. How is that supposed to work, when the chassis are out of sync?


Huh?  The TSC's are only guaranteed to be synced within an SSI.  As long 
as the sockets in the same SSI share a common clock, the BIOS can 
synchronize the TSC's to be very, very close.



We do have independent methods to verify if TSCs' are in sync with each other
by measuring the skew rate.  Typical deviations on UV are within a two digit
clock tick spread, which at an Uncore frequency of 2.5Ghz is in the small
single digit or less nanosecond range.


That should be good enough to pass the kernel side tests.

But back to my question about ART. You might talk to your BIOS/HW folks
about that and eventually disable the ART related functionality in the
kernel on UV.


Once again, I'm not sure what code you are talking about.  I talked to 
the BIOS engineer specifically working on TSC related items and he was 
also not familiar with the Intel ART spec.  I could go farther up the 
chain to the hardware designers but right now this would be extremely 
low on their priority queue.


Perhaps if you were more specific in what code should be disabled?  We 
would like to keep as much as the self check code as possible as there 
are still some remotely possible failure cases.  And removing the self 
checks would have a negative impact on reliability.


I actually did test using the CPU flags, "TSC reliable" and no "TSC 
ADJUST" to prevent the kernel from overwriting the already correct TS

Re: [PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being non-null is valid

[Mike Travis]

On 9/25/2017 8:30 AM, Thomas Gleixner wrote:

On Thu, 21 Sep 2017, mike.tra...@hpe.com wrote:

+/*
+ * TSC on socket 0 being non-zero may be correct as set by BIOS
+ */
+static int __read_mostly tsc_socket0_nonzero;
+
  /* native_sched_clock() is called before tsc_init(), so
 we must start with the TSC soft disabled to prevent
 erroneous rdtsc usage on !boot_cpu_has(X86_FEATURE_TSC) processors */
@@ -244,6 +249,20 @@ int check_tsc_unstable(void)
  }
  EXPORT_SYMBOL_GPL(check_tsc_unstable);
  
+void mark_tsc_socket0_nonzero(char *reason)

+{
+   tsc_socket0_nonzero = 1;
+   pr_info("Marking TSC non-zero value valid for socket 0 due to %s\n",
+   reason);
+}
+EXPORT_SYMBOL_GPL(mark_tsc_socket0_nonzero);

+int check_tsc_socket0_nonzero(void)
+{
+   return tsc_socket0_nonzero;
+}
+EXPORT_SYMBOL_GPL(check_tsc_socket0_nonzero);


Is there a real reason to export these functions? I can't see the UV early
boot code and tsc_sync being built as modules in the forseeable future, but
perhaps you know more than I do :)


Yes, that was a mistake.  I originally inserted this by following the 
example of the check_tsc_unstable() function.  I had a later patch 
moving this to tsc_sync.c as a local flag but apparently it reverted 
back to the earlier version.  I'll fix that.


Aside of that I really do not like this kind of special case hackery. The
real question is whether we need to enforce TSC_ADJUST == 0 on the boot cpu
at all. In principle we don't anymore now that we handle that TSC deadline
timer wreckage cleanly.


I am hesitant to make such a global change as it appears the author 
intentionally added this.  It not only caused our internal tsc sync 
tests to become totally out of whack, it also generated an avalanche of 
error messages to the system console (>3000 messages for a 32 socket 
Skylake system).  And I don't have the means to test how major changes 
to the TSC adjust functions will affect standard whitebox PC's.


Our BIOS team did make a change to conform to the "TSC_ADJUST should be 
the same on all cpu threads on a single socket" requirement, so we were 
able to pass that part of the TSC validation functions.  (Prior to this, 
the TSC's were synced by writing directly to the TSC MSR and natural 
delays in the processor firmware caused the slight differences in the 
TSC ADJUST values.)




But the UV 'boot chassis at different times' brings me to a related
question:


Essentially what happens is the system reset signals are distributed in 
various ways which cause the different chassis to start up 
asynchronously with each other.  The UV system is not "hard" bound to 
each other but adapts to the system configuration as it starts up.




How is this setup dealing with ART (Always Running Timer, which is
distributed over PCIe for hardware timestamping and hardware assisted event
correlation)?

I assume that ART on UV is also per chassis, but that means that the
documented relation ship of:

TSC = ART * n/d + offset

where $offset is system wide (the TSC_ADJUST value of the boot cpu), is
not applicable.

Is there some other magic in play which makes ART work across chassis?

>
> Thanks,
>
>tglx
>

Sorry, I'm not sure how the UV hardware mimics the concept of 'ART'.  It 
does have an external clock generator that is distributed as part of the 
NumaLink protocol and signal set.  Since separate chassis can be 
configured to be either within the same SSI or in separate SSI's then it 
has the ability to configure which chassis are in sync with each other 
and which are on a different clock sync.  This is all within the purview 
of the BIOS folks.


We do have independent methods to verify if TSCs' are in sync with each 
other by measuring the skew rate.  Typical deviations on UV are within a 
two digit clock tick spread, which at an Uncore frequency of 2.5Ghz is 
in the small single digit or less nanosecond range.


I'll post the updated patch set shortly.

Thanks,
Mike

Re: [PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being non-null is valid

[Mike Travis]

On 9/25/2017 8:30 AM, Thomas Gleixner wrote:

On Thu, 21 Sep 2017, mike.tra...@hpe.com wrote:

+/*
+ * TSC on socket 0 being non-zero may be correct as set by BIOS
+ */
+static int __read_mostly tsc_socket0_nonzero;
+
  /* native_sched_clock() is called before tsc_init(), so
 we must start with the TSC soft disabled to prevent
 erroneous rdtsc usage on !boot_cpu_has(X86_FEATURE_TSC) processors */
@@ -244,6 +249,20 @@ int check_tsc_unstable(void)
  }
  EXPORT_SYMBOL_GPL(check_tsc_unstable);
  
+void mark_tsc_socket0_nonzero(char *reason)

+{
+   tsc_socket0_nonzero = 1;
+   pr_info("Marking TSC non-zero value valid for socket 0 due to %s\n",
+   reason);
+}
+EXPORT_SYMBOL_GPL(mark_tsc_socket0_nonzero);

+int check_tsc_socket0_nonzero(void)
+{
+   return tsc_socket0_nonzero;
+}
+EXPORT_SYMBOL_GPL(check_tsc_socket0_nonzero);


Is there a real reason to export these functions? I can't see the UV early
boot code and tsc_sync being built as modules in the forseeable future, but
perhaps you know more than I do :)


Yes, that was a mistake.  I originally inserted this by following the 
example of the check_tsc_unstable() function.  I had a later patch 
moving this to tsc_sync.c as a local flag but apparently it reverted 
back to the earlier version.  I'll fix that.


Aside of that I really do not like this kind of special case hackery. The
real question is whether we need to enforce TSC_ADJUST == 0 on the boot cpu
at all. In principle we don't anymore now that we handle that TSC deadline
timer wreckage cleanly.


I am hesitant to make such a global change as it appears the author 
intentionally added this.  It not only caused our internal tsc sync 
tests to become totally out of whack, it also generated an avalanche of 
error messages to the system console (>3000 messages for a 32 socket 
Skylake system).  And I don't have the means to test how major changes 
to the TSC adjust functions will affect standard whitebox PC's.


Our BIOS team did make a change to conform to the "TSC_ADJUST should be 
the same on all cpu threads on a single socket" requirement, so we were 
able to pass that part of the TSC validation functions.  (Prior to this, 
the TSC's were synced by writing directly to the TSC MSR and natural 
delays in the processor firmware caused the slight differences in the 
TSC ADJUST values.)




But the UV 'boot chassis at different times' brings me to a related
question:


Essentially what happens is the system reset signals are distributed in 
various ways which cause the different chassis to start up 
asynchronously with each other.  The UV system is not "hard" bound to 
each other but adapts to the system configuration as it starts up.




How is this setup dealing with ART (Always Running Timer, which is
distributed over PCIe for hardware timestamping and hardware assisted event
correlation)?

I assume that ART on UV is also per chassis, but that means that the
documented relation ship of:

TSC = ART * n/d + offset

where $offset is system wide (the TSC_ADJUST value of the boot cpu), is
not applicable.

Is there some other magic in play which makes ART work across chassis?

>
> Thanks,
>
>tglx
>

Sorry, I'm not sure how the UV hardware mimics the concept of 'ART'.  It 
does have an external clock generator that is distributed as part of the 
NumaLink protocol and signal set.  Since separate chassis can be 
configured to be either within the same SSI or in separate SSI's then it 
has the ability to configure which chassis are in sync with each other 
and which are on a different clock sync.  This is all within the purview 
of the BIOS folks.


We do have independent methods to verify if TSCs' are in sync with each 
other by measuring the skew rate.  Typical deviations on UV are within a 
two digit clock tick spread, which at an Uncore frequency of 2.5Ghz is 
in the small single digit or less nanosecond range.


I'll post the updated patch set shortly.

Thanks,
Mike

Re: [PATCH v2 1/2] x86/UV: Introduce a helper function to check UV system at earlier stage

[Mike Travis]

Acked-by: Mike Travis <tra...@sgi.com>

On 5/20/2017 5:02 AM, Baoquan He wrote:

The SGI BIOS adds UVsystab, and only systems running SGI BIOS
(and now HPE Hawks2) will have UVsystab. And UVsystab is detected in
efi_init() which is at very early stage. So introduce a new helper
function is_early_uv_system() for later usage.

Signed-off-by: Baoquan He <b...@redhat.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Ingo Molnar <mi...@redhat.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: x...@kernel.org
Cc: Russ Anderson <r...@hpe.com>
Cc: Dimitri Sivanich <sivan...@hpe.com>
Cc: "tra...@sgi.com" <tra...@sgi.com>
Cc: Mike Travis <mike.tra...@hpe.com>
Cc: Frank Ramsay <frank.ram...@hpe.com>
---
  arch/x86/include/asm/uv/uv.h | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h
index 6686820..159f698 100644
--- a/arch/x86/include/asm/uv/uv.h
+++ b/arch/x86/include/asm/uv/uv.h
@@ -19,6 +19,11 @@ extern const struct cpumask *uv_flush_tlb_others(const 
struct cpumask *cpumask,
 unsigned long start,
 unsigned long end,
 unsigned int cpu);
+#include 
+static inline int is_early_uv_system(void)
+{
+   return !((efi.uv_systab == EFI_INVALID_TABLE_ADDR) || !efi.uv_systab);
+}
  
  #else	/* X86_UV */
  
@@ -31,6 +36,7 @@ static inline const struct cpumask *

  uv_flush_tlb_others(const struct cpumask *cpumask, struct mm_struct *mm,
unsigned long start, unsigned long end, unsigned int cpu)
  { return cpumask; }
+static inline int is_early_uv_system(void) { return 0; }
  
  #endif	/* X86_UV */