nohz problem with idle time on old hardware

2013-11-13 Thread Matthew Whitehead
I was testing the 3.12 kernel on some _old_ hardware and I uncovered a bug.
It arises when nohz=on and goes away with nohz=off. On a crusty dual Pentium-1 
system that is completely idle, the sar utility reports 0% idle time on cpu0 
and 100% idle on cpu1. Cpu0 _should_ also be reporting 100% idle, but instead
it reports around 75% system time and 25% user time.

The problem was diagnosed by Steve Rostedt with help from John Stultz. The old
system declares the dual TSCs unstable, and backs down to a timesource of 
refined-jiffies. Apparently refined-jiffies and jiffies are not a usable 
timesourcefor nohz, but we don't check for that case because most modern
systems have several reliable hardware timesources.

John suggested that we turn off nohz unless a usable hardware timesource is
present.

- Matthew Whitehead tedheads...@gmail.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: nohz problem with idle time on old hardware

2013-11-13 Thread Matthew Whitehead
On Wed, Nov 13, 2013 at 03:07:45PM -0500, Steven Rostedt wrote:
 On Wed, 13 Nov 2013 21:01:57 +0100 (CET)
 Thomas Gleixner t...@linutronix.de wrote:
 
 
  
  Subject: NOHZ: Check for nohz active instead of nohz enabled
  
  RCU and the fine grained idle time accounting functions check
  tick_nohz_enabled. But that variable is merily telling that NOHZ has
  been enabled in the config and not been disabled on the command line.
  
  But it does not tell anything about nohz being active. That's what all
  this should check for.
  
  Matthew reported, that the idle accounting on his old P1 machine
  showed bogus values, when he enabled NOHZ in the config and did not
  disable it on the kernel command line. The reason is that his machine
  uses (refined) jiffies as a clocksource which explains why the fine
  grained accounting went into lala land, because it depends on when the
  system goes and leaves idle relative to the jiffies increment.
  
  Provide a tick_nohz_active indicator and let RCU and the accounting
  code use this instead of tick_nohz_enable.
  
  Reported-by: Matthew Whitehead tedheads...@gmail.com
 
 Matthew, can you test this patch to make sure it causes the idle issue
 to go away (remember to remove nohz=off from your command line).
 

Early testing looks good:

# Verify I haven't overridden nohz as a kernel parameter
root@host:~# grep nohz /proc/cmdline 

# See how my kernel chose its clocksource
root@host:~# dmesg | egrep TSC|clocksource
[0.00] tsc: Fast TSC calibration using PIT
[2.492468] Switched to clocksource refined-jiffies
[   24.197356] Switched to clocksource tsc
[   26.211058] Switched to clocksource refined-jiffies

# Check idle time since the reboot
root@host:~# sar -s 16:28:00 -P ALL 
Linux 3.12.0-rc6+ (host)  11/13/2013  _i586_  (2 CPU)

04:28:26 PM   LINUX RESTART

04:32:02 PM CPU %user %nice   %system   %iowait%steal %idle
04:34:02 PM all  4.98  0.00  1.03  0.04  0.00 93.96
04:34:02 PM   0  4.07  0.00  0.69  0.03  0.00 95.21
04:34:02 PM   1  5.88  0.00  1.37  0.06  0.00 92.70
04:36:01 PM all  4.12  0.00  1.13  0.02  0.00 94.73
04:36:01 PM   0  1.98  0.00  1.34  0.02  0.00 96.66
04:36:01 PM   1  6.28  0.00  0.91  0.03  0.00 92.79
04:38:01 PM all  0.39  0.00  0.65  0.05  0.00 98.90
04:38:01 PM   0  0.33  0.00  0.54  0.03  0.00 99.09
04:38:01 PM   1  0.45  0.00  0.75  0.07  0.00 98.73
04:40:01 PM all  0.14  0.00  0.40  0.02  0.00 99.44
04:40:01 PM   0  0.12  0.00  0.26  0.01  0.00 99.62
04:40:01 PM   1  0.16  0.00  0.55  0.02  0.00 99.27
04:42:01 PM all  0.13  0.00  0.28  0.01  0.00 99.58
04:42:01 PM   0  0.09  0.00  0.14  0.01  0.00 99.76
04:42:01 PM   1  0.16  0.00  0.43  0.02  0.00 99.40
Average:all  1.95  0.00  0.70  0.03  0.00 97.33
Average:  0  1.32  0.00  0.59  0.02  0.00 98.07
Average:  1  2.58  0.00  0.80  0.04  0.00 96.58

I will continue to test but I think this is good.

Tested-by: Matthew Whitehead tedheads...@gmail.com

- Matthew W

 Reviewed-by: Steven Rostedt rost...@goodmis.org
 
 -- Steve
 
  Signed-off-by: Thomas Gleixner t...@linutronix.de
  ---
  diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
  index 3822ac0..da6e6de 100644
  --- a/kernel/rcu/tree_plugin.h
  +++ b/kernel/rcu/tree_plugin.h
  @@ -1632,7 +1632,7 @@ module_param(rcu_idle_gp_delay, int, 0644);
   static int rcu_idle_lazy_gp_delay = RCU_IDLE_LAZY_GP_DELAY;
   module_param(rcu_idle_lazy_gp_delay, int, 0644);
   
  -extern int tick_nohz_enabled;
  +extern int tick_nohz_active;
   
   /*
* Try to advance callbacks for all flavors of RCU on the current CPU, but
  @@ -1729,7 +1729,7 @@ static void rcu_prepare_for_idle(int cpu)
  int tne;
   
  /* Handle nohz enablement switches conservatively. */
  -   tne = ACCESS_ONCE(tick_nohz_enabled);
  +   tne = ACCESS_ONCE(tick_nohz_active);
  if (tne != rdtp-tick_nohz_enabled_snap) {
  if (rcu_cpu_has_callbacks(cpu, NULL))
  invoke_rcu_core(); /* force nohz to see update. */
  diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
  index 3612fc7..a12df5a 100644
  --- a/kernel/time/tick-sched.c
  +++ b/kernel/time/tick-sched.c
  @@ -361,8 +361,8 @@ void __init tick_nohz_init(void)
   /*
* NO HZ enabled ?
*/
  -int tick_nohz_enabled __read_mostly  = 1;
  -
  +static int tick_nohz_enabled __read_mostly  = 1;
  +int tick_nohz_active  __read_mostly;
   /*
* Enable / Disable tickless mode
*/
  @@ -465,7 +465,7

[PATCH] x86/perf : Add check for CPUID instruction before using

2018-02-02 Thread Matthew Whitehead
We still officially support the ancient i486 cpu. First generation
versions of this processor do not have the CPUID instruction, though
later versions do. Therefore you must check that the cpu supports
it before using it. At present it fails with an "Illegal Instruction"
signal on the early processors.

This code was based on similar code in the gcc package.

Signed-off-by: Matthew Whitehead <tedheads...@gmail.com>
---
 tools/perf/arch/x86/util/header.c | 51 +++
 tools/perf/util/header.h  |  2 ++
 2 files changed, 53 insertions(+)

diff --git a/tools/perf/arch/x86/util/header.c 
b/tools/perf/arch/x86/util/header.c
index fb0d71afee8b..d4d12894c64d 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -7,6 +7,54 @@
 
 #include "../../util/header.h"
 
+/* This code based on gcc cpuid.h __get_cpuid_max() */
+unsigned int have_cpuid(void)
+{
+   unsigned int __eax, __ebx;
+
+#ifndef __x86_64__
+/* See if we can use cpuid.  On AMD64 we always can.  */
+#if __GNUC__ >= 3
+   __asm__ ("pushf{l|d}\n\t"
+   "pushf{l|d}\n\t"
+   "pop{l}\t%0\n\t"
+   "mov{l}\t{%0, %1|%1, %0}\n\t"
+   "xor{l}\t{%2, %0|%0, %2}\n\t"
+   "push{l}\t%0\n\t"
+   "popf{l|d}\n\t"
+   "pushf{l|d}\n\t"
+   "pop{l}\t%0\n\t"
+   "popf{l|d}\n\t"
+   : "=" (__eax), "=" (__ebx)
+   : "i" (0x0020));
+#else
+/* Host GCCs older than 3.0 weren't supporting Intel asm syntax
+ * nor alternatives in i386 code.
+ */
+   __asm__ ("pushfl\n\t"
+   "pushfl\n\t"
+   "popl\t%0\n\t"
+   "movl\t%0, %1\n\t"
+   "xorl\t%2, %0\n\t"
+   "pushl\t%0\n\t"
+   "popfl\n\t"
+   "pushfl\n\t"
+   "popl\t%0\n\t"
+   "popfl\n\t"
+   : "=" (__eax), "=" (__ebx)
+   : "i" (0x0020));
+#endif
+
+   if (!((__eax ^ __ebx) & 0x0020))
+   return 0;
+   else
+   return 1;
+#endif
+
+/* All x86_64 support cpuid */
+   return 1;
+}
+
 static inline void
 cpuid(unsigned int op, unsigned int *a, unsigned int *b, unsigned int *c,
   unsigned int *d)
@@ -28,6 +76,9 @@ __get_cpuid(char *buffer, size_t sz, const char *fmt)
int nb;
char vendor[16];
 
+   if (!have_cpuid())
+   return -1;
+
cpuid(0, , , , );
strncpy([0], (char *)(), 4);
strncpy([4], (char *)(), 4);
diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index f283a440..ce31fca36077 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -171,6 +171,8 @@ int write_padded(struct feat_fd *fd, const void *bf,
 /*
  * arch specific callback
  */
+unsigned int have_cpuid(void);
+
 int get_cpuid(char *buffer, size_t sz);
 
 char *get_cpuid_str(struct perf_pmu *pmu __maybe_unused);
-- 
2.13.6



[PATCH v2] x86/perf : Add check for CPUID instruction before using

2018-02-02 Thread Matthew Whitehead
We still officially support the ancient i486 cpu. First generation
versions of this processor do not have the CPUID instruction, though
later versions do. Therefore you must check that the cpu supports
it before using it. At present it fails with an "Illegal Instruction"
signal on the early processors.

v1: cpuid detection code based on GCC gcc/config/i386/cpuid.h

https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/config/i386/cpuid.h;hb=HEAD
v2: cpuid detection code based on Linux kernel arch/x86/kernel/cpu/common.c

Signed-off-by: Matthew Whitehead <tedheads...@gmail.com>
---
 tools/perf/arch/x86/util/header.c | 54 +++
 tools/perf/util/header.h  |  2 ++
 2 files changed, 56 insertions(+)

diff --git a/tools/perf/arch/x86/util/header.c 
b/tools/perf/arch/x86/util/header.c
index fb0d71a..d2508b3 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -7,6 +7,57 @@
 
 #include "../../util/header.h"
 
+#ifndef __x86_64__
+
+/* This code based on arch/x86/kernel/cpu/common.c
+ * Standard macro to see if a specific flag is changeable.
+ */
+static inline int flag_is_changeable_p(u32 flag)
+{
+   u32 f1, f2;
+
+   /*
+* Cyrix and IDT cpus allow disabling of CPUID
+* so the code below may return different results
+* when it is executed before and after enabling
+* the CPUID. Add "volatile" to not allow gcc to
+* optimize the subsequent calls to this function.
+*/
+   asm volatile ("pushfl   \n\t"
+ "pushfl   \n\t"
+ "popl %0  \n\t"
+ "movl %0, %1  \n\t"
+ "xorl %2, %0  \n\t"
+ "pushl %0 \n\t"
+ "popfl\n\t"
+ "pushfl   \n\t"
+ "popl %0  \n\t"
+ "popfl\n\t"
+
+ : "=" (f1), "=" (f2)
+ : "ir" (flag));
+
+   return ((f1^f2) & flag) != 0;
+}
+
+#define X86_EFLAGS_ID 0x0020
+
+/* Probe for the CPUID instruction */
+int have_cpuid_p(void)
+{
+   return flag_is_changeable_p(X86_EFLAGS_ID);
+}
+
+#else  /* CONFIG_X86_64 */
+
+/* All X86_64 have cpuid instruction */
+int have_cpuid_p(void)
+{
+   return 1;
+}
+
+#endif /* CONFIG_X86_64 */
+
 static inline void
 cpuid(unsigned int op, unsigned int *a, unsigned int *b, unsigned int *c,
   unsigned int *d)
@@ -28,6 +79,9 @@
int nb;
char vendor[16];
 
+   if (!have_cpuid_p())
+   return -1;
+
cpuid(0, , , , );
strncpy([0], (char *)(), 4);
strncpy([4], (char *)(), 4);
diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index f28..f4de656 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -171,6 +171,8 @@ int write_padded(struct feat_fd *fd, const void *bf,
 /*
  * arch specific callback
  */
+int have_cpuid_p(void);
+
 int get_cpuid(char *buffer, size_t sz);
 
 char *get_cpuid_str(struct perf_pmu *pmu __maybe_unused);
-- 
1.8.3.1



[PATCH 3/3] x86/Kconfig : Explicitly enumerate i686-class cpus in Kconfig

2018-02-03 Thread Matthew Whitehead
The X86_P6_NOP config class leaves out many i686-class cpus. Instead,
explicitly enumerate all these cpus.

Using a configuration with M686 currently sets X86_MINIMUM_CPU_FAMILY=5
instead of the correct value 6.

Booting on an i586 it will fail to generate the "This kernel
requires an i686 CPU, but only detected an i586 CPU" message and
intentional halt as expected. It will instead just silently hang
when it hits i686-specific instructions.

Signed-off-by: Matthew Whitehead <tedheads...@gmail.com>
---
 arch/x86/Kconfig.cpu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index ec64aa7..8b8d229 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -385,7 +385,7 @@ config X86_CMOV
 config X86_MINIMUM_CPU_FAMILY
int
default "64" if X86_64
-   default "6" if X86_32 && X86_P6_NOP
+   default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || 
MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MCRUSOE || 
MCORE2 || MK7 || MK8)
default "5" if X86_32 && X86_CMPXCHG64
default "4"
 
-- 
1.8.3.1



[PATCH 1/3] x86/Kconfig : Add missing i586-class cpus to X86_CMPXCHG64 Kconfig group

2018-02-03 Thread Matthew Whitehead
Several i586-class cpus supporting this instruction are missing from
the X86_CMPXCHG64 config group.

Using a configuration with either M586TSC or M586MMX currently sets
X86_MINIMUM_CPU_FAMILY=4 instead of the correct value 5.

Booting on an i486 it will fail to generate the "This kernel
requires an i586 CPU, but only detected an i486 CPU" message and
intentional halt as expected. It will instead just silently hang
when it hits i586-specific instructions.

The M586 cpu is not in this list because at least the Cyrix 5x86
lacks this instruction, and perhaps others.

Signed-off-by: Matthew Whitehead <tedheads...@gmail.com>
---
 arch/x86/Kconfig.cpu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 65a9a47..ec64aa7 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -374,7 +374,7 @@ config X86_TSC
 
 config X86_CMPXCHG64
def_bool y
-   depends on X86_PAE || X86_64 || MCORE2 || MPENTIUM4 || MPENTIUMM || 
MPENTIUMIII || MPENTIUMII || M686 || MATOM
+   depends on X86_PAE || X86_64 || MCORE2 || MPENTIUM4 || MPENTIUMM || 
MPENTIUMIII || MPENTIUMII || M686 || M586TSC || M586MMX || MATOM || MGEODE_LX 
|| MGEODEGX1 || MK6 || MK7 || MK8
 
 # this should be set for all -march=.. options where the compiler
 # generates cmov.
-- 
1.8.3.1



[PATCH 2/3] x86/Kconfig : Exclude i586-class cpus lacking PAE support from HIGHMEM64G Kconfig group

2018-02-03 Thread Matthew Whitehead
i586-class machines also lack support for Physical Address Extension (PAE),
so add them to the exclusion list

Signed-off-by: Matthew Whitehead <tedheads...@gmail.com>
---
 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 423e4b6..c45fe6d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1359,7 +1359,7 @@ config HIGHMEM4G
 
 config HIGHMEM64G
bool "64GB"
-   depends on !M486
+   depends on !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && 
!MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !WINCHIP3D && !MK6
select X86_PAE
---help---
  Select this if you have a 32-bit processor and more than 4
-- 
1.8.3.1



[PATCH 3/3] x86/Kconfig : Explicitly enumerate i686-class cpus in Kconfig

2018-02-15 Thread Matthew Whitehead
The X86_P6_NOP config class leaves out many i686-class cpus. Instead,
explicitly enumerate all these cpus.

Using a configuration with M686 currently sets X86_MINIMUM_CPU_FAMILY=5
instead of the correct value 6.

Booting on an i586 it will fail to generate the "This kernel
requires an i686 CPU, but only detected an i586 CPU" message and
intentional halt as expected. It will instead just silently hang
when it hits i686-specific instructions.

Signed-off-by: Matthew Whitehead <tedheads...@gmail.com>
---
 arch/x86/Kconfig.cpu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index ec64aa7..8b8d229 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -385,7 +385,7 @@ config X86_CMOV
 config X86_MINIMUM_CPU_FAMILY
int
default "64" if X86_64
-   default "6" if X86_32 && X86_P6_NOP
+   default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || 
MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MCRUSOE || 
MCORE2 || MK7 || MK8)
default "5" if X86_32 && X86_CMPXCHG64
default "4"
 
-- 
1.8.3.1



[PATCH 2/3] x86/Kconfig : Exclude i586-class cpus lacking PAE support from HIGHMEM64G Kconfig group

2018-02-15 Thread Matthew Whitehead
i586-class machines also lack support for Physical Address Extension (PAE),
so add them to the exclusion list

Signed-off-by: Matthew Whitehead <tedheads...@gmail.com>
---
 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 72d5149..89bf3fa 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1360,7 +1360,7 @@ config HIGHMEM4G
 
 config HIGHMEM64G
bool "64GB"
-   depends on !M486
+   depends on !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && 
!MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !WINCHIP3D && !MK6
select X86_PAE
---help---
  Select this if you have a 32-bit processor and more than 4
-- 
1.8.3.1



[PATCH 1/3] x86/Kconfig : Add missing i586-class cpus to X86_CMPXCHG64 Kconfig group

2018-02-15 Thread Matthew Whitehead
Several i586-class cpus supporting this instruction are missing from
the X86_CMPXCHG64 config group.

Using a configuration with either M586TSC or M586MMX currently sets
X86_MINIMUM_CPU_FAMILY=4 instead of the correct value 5.

Booting on an i486 it will fail to generate the "This kernel
requires an i586 CPU, but only detected an i486 CPU" message and
intentional halt as expected. It will instead just silently hang
when it hits i586-specific instructions.

The M586 cpu is not in this list because at least the Cyrix 5x86
lacks this instruction, and perhaps others.

Signed-off-by: Matthew Whitehead <tedheads...@gmail.com>
---
 arch/x86/Kconfig.cpu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 65a9a47..ec64aa7 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -374,7 +374,7 @@ config X86_TSC
 
 config X86_CMPXCHG64
def_bool y
-   depends on X86_PAE || X86_64 || MCORE2 || MPENTIUM4 || MPENTIUMM || 
MPENTIUMIII || MPENTIUMII || M686 || MATOM
+   depends on X86_PAE || X86_64 || MCORE2 || MPENTIUM4 || MPENTIUMM || 
MPENTIUMIII || MPENTIUMII || M686 || M586TSC || M586MMX || MATOM || MGEODE_LX 
|| MGEODEGX1 || MK6 || MK7 || MK8
 
 # this should be set for all -march=.. options where the compiler
 # generates cmov.
-- 
1.8.3.1



[PATCH] x86: kvm: Restrict X86_FEATURE_VMMCALL to x86_64 platform

2018-07-30 Thread Matthew Whitehead
early_init_amd() is called on all AMD processors, both 64 and 32 bit.
Presently 32 bit processors get the X86_FEATURE_VMMCALL feature set, which
they do not support. Add conditionals to restrict it to 64 bit processors.

Cc: Paolo Bonzini 
Signed-off-by: Matthew Whitehead 
---
 arch/x86/kernel/cpu/amd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 38915fbfae73..df06919324cd 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -662,12 +662,14 @@ static void early_init_amd(struct cpuinfo_x86 *c)
}
 #endif
 
+#ifdef CONFIG_X86_64
/*
 * This is only needed to tell the kernel whether to use VMCALL
 * and VMMCALL.  VMMCALL is never executed except under virt, so
 * we can set it unconditionally.
 */
set_cpu_cap(c, X86_FEATURE_VMMCALL);
+#endif
 
/* F16h erratum 793, CVE-2013-6885 */
if (c->x86 == 0x16 && c->x86_model <= 0xf)
-- 
2.16.1



[PATCH] x86/cpu: Enable cpuid instruction on Cyrix 6x86/6x86L processors

2018-09-20 Thread Matthew Whitehead
On power up, the cpuid instruction is disabled on Cyrix 6x86 and 6x86L
processors and it needs to be enabled. There is code to do this, but it
does not work because it uses the broken {set,get}Cx86_old() macros.

There are comments in processor-cyrix.h advising you to _not_ make calls
using the deprecated macros in this style:

  setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);

This is because it expands the macro into a non-functioning calling
sequence. The new macros fix this problem, so we use them instead.

We also need to forcibly enable X86_FEATURE_CPUID. This is because
early_identify_cpu() does not know that the call to
identify_cpu_without_cpuid() actually enables the cpuid instruction in the
odd Cyrix case, and it turns X86_FEATURE_CPUID off after it has just been
enabled on the processor.

This was tested on actual Cyrix hardware.

Signed-off-by: Matthew Whitehead 
---
 arch/x86/kernel/cpu/cyrix.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index 8949b7a..e603cc5 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -437,10 +437,11 @@ static void cyrix_identify(struct cpuinfo_x86 *c)
/* enable MAPEN  */
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);
/* enable cpuid  */
-   setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);
+   setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x80);
/* disable MAPEN */
setCx86(CX86_CCR3, ccr3);
local_irq_restore(flags);
+   setup_force_cpu_cap(X86_FEATURE_CPUID);
}
}
 }
-- 
1.8.3.1



[PATCH v2 1/2] x86/cpu: Use correct macros for Cyrix calls

2018-09-21 Thread Matthew Whitehead
There are comments in processor-cyrix.h advising you to _not_ make calls
using the deprecated macros in this style:

  setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);

This is because it expands the macro into a non-functioning calling
sequence. The calling order must be:

  outb(CX86_CCR2, 0x22);
  inb(0x23);

>From the comments:

 * When using the old macros a line like
 *   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
 * gets expanded to:
 *  do {
 *outb((CX86_CCR2), 0x22);
 *outb((({
 *outb((CX86_CCR2), 0x22);
 *inb(0x23);
 *}) | 0x88), 0x23);
 *  } while (0);

The new macros fix this problem, so we use them instead.

Reviewed-by: Andy Lutomirski 
Signed-off-by: Matthew Whitehead 
---
 arch/x86/kernel/cpu/cyrix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index 8949b7ae6d92..d12226f60168 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -437,7 +437,7 @@ static void cyrix_identify(struct cpuinfo_x86 *c)
/* enable MAPEN  */
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);
/* enable cpuid  */
-   setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);
+   setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x80);
/* disable MAPEN */
setCx86(CX86_CCR3, ccr3);
local_irq_restore(flags);
-- 
2.16.4



[PATCH v2 2/2] x86/cpu: Change query logic so cpuid is enabled before testing

2018-09-21 Thread Matthew Whitehead
Presently we check for cpuid to be enabled first. If it is not already
enabled, then we next call identify_cpu_without_cpuid() and clear
X86_FEATURE_CPUID.

Unfortunately, identify_cpu_without_cpuid() is the function where cpuid
becomes _enabled_ on Cyrix 6x86/6x86L cpus. So we must reverse the
calling sequence so that cpuid is first enabled, and then check a second
time to see if the feature has now been activated.

Reviewed-by: Andy Lutomirski 
Signed-off-by: Matthew Whitehead 
---
 arch/x86/kernel/cpu/common.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index eb4cb3efd20e..60c7c5ce7e55 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1040,6 +1040,9 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
*c)
memset(>x86_capability, 0, sizeof c->x86_capability);
c->extended_cpuid_level = 0;
 
+   if (!have_cpuid_p())
+   identify_cpu_without_cpuid(c);
+   
/* cyrix could have cpuid enabled via c_identify()*/
if (have_cpuid_p()) {
cpu_detect(c);
@@ -1057,7 +1060,6 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
*c)
if (this_cpu->c_bsp_init)
this_cpu->c_bsp_init(c);
} else {
-   identify_cpu_without_cpuid(c);
setup_clear_cpu_cap(X86_FEATURE_CPUID);
}
 
-- 
2.16.4



[PATCH v2 0/2] x86/cpu: Enable cpuid on Cyrix 6x86/6x86L processors

2018-09-21 Thread Matthew Whitehead
On power up, the cpuid instruction is disabled on Cyrix 6x86 and 6x86L
processors and needs to be enabled. This patchset enables it.

Matthew Whitehead (2):
  x86/cpu: Use correct macros for Cyrix calls
  x86/cpu: Change query logic so cpuid is enabled before testing

 arch/x86/kernel/cpu/common.c | 4 +++-
 arch/x86/kernel/cpu/cyrix.c  | 2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.16.4



nohz problem with idle time on old hardware

2013-11-13 Thread Matthew Whitehead
I was testing the 3.12 kernel on some _old_ hardware and I uncovered a bug.
It arises when nohz=on and goes away with nohz=off. On a crusty dual Pentium-1 
system that is completely idle, the sar utility reports 0% idle time on cpu0 
and 100% idle on cpu1. Cpu0 _should_ also be reporting 100% idle, but instead
it reports around 75% system time and 25% user time.

The problem was diagnosed by Steve Rostedt with help from John Stultz. The old
system declares the dual TSCs unstable, and backs down to a timesource of 
refined-jiffies. Apparently refined-jiffies and jiffies are not a usable 
timesourcefor nohz, but we don't check for that case because most modern
systems have several reliable hardware timesources.

John suggested that we turn off nohz unless a usable hardware timesource is
present.

- Matthew Whitehead 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: nohz problem with idle time on old hardware

2013-11-13 Thread Matthew Whitehead
On Wed, Nov 13, 2013 at 03:07:45PM -0500, Steven Rostedt wrote:
> On Wed, 13 Nov 2013 21:01:57 +0100 (CET)
> Thomas Gleixner  wrote:
> 
> 
> > >
> > Subject: NOHZ: Check for nohz active instead of nohz enabled
> > 
> > RCU and the fine grained idle time accounting functions check
> > tick_nohz_enabled. But that variable is merily telling that NOHZ has
> > been enabled in the config and not been disabled on the command line.
> > 
> > But it does not tell anything about nohz being active. That's what all
> > this should check for.
> > 
> > Matthew reported, that the idle accounting on his old P1 machine
> > showed bogus values, when he enabled NOHZ in the config and did not
> > disable it on the kernel command line. The reason is that his machine
> > uses (refined) jiffies as a clocksource which explains why the "fine"
> > grained accounting went into lala land, because it depends on when the
> > system goes and leaves idle relative to the jiffies increment.
> > 
> > Provide a tick_nohz_active indicator and let RCU and the accounting
> > code use this instead of tick_nohz_enable.
> > 
> > Reported-by: Matthew Whitehead 
> 
> Matthew, can you test this patch to make sure it causes the idle issue
> to go away (remember to remove nohz=off from your command line).
> 

Early testing looks good:

# Verify I haven't overridden nohz as a kernel parameter
root@host:~# grep nohz /proc/cmdline 

# See how my kernel chose its clocksource
root@host:~# dmesg | egrep "TSC|clocksource"
[0.00] tsc: Fast TSC calibration using PIT
[2.492468] Switched to clocksource refined-jiffies
[   24.197356] Switched to clocksource tsc
[   26.211058] Switched to clocksource refined-jiffies

# Check idle time since the reboot
root@host:~# sar -s 16:28:00 -P ALL 
Linux 3.12.0-rc6+ (host)  11/13/2013  _i586_  (2 CPU)

04:28:26 PM   LINUX RESTART

04:32:02 PM CPU %user %nice   %system   %iowait%steal %idle
04:34:02 PM all  4.98  0.00  1.03  0.04  0.00 93.96
04:34:02 PM   0  4.07  0.00  0.69  0.03  0.00 95.21
04:34:02 PM   1  5.88  0.00  1.37  0.06  0.00 92.70
04:36:01 PM all  4.12  0.00  1.13  0.02  0.00 94.73
04:36:01 PM   0  1.98  0.00  1.34  0.02  0.00 96.66
04:36:01 PM   1  6.28  0.00  0.91  0.03  0.00 92.79
04:38:01 PM all  0.39  0.00  0.65  0.05  0.00 98.90
04:38:01 PM   0  0.33  0.00  0.54  0.03  0.00 99.09
04:38:01 PM   1  0.45  0.00  0.75  0.07  0.00 98.73
04:40:01 PM all  0.14  0.00  0.40  0.02  0.00 99.44
04:40:01 PM   0  0.12  0.00  0.26  0.01  0.00 99.62
04:40:01 PM   1  0.16  0.00  0.55  0.02  0.00 99.27
04:42:01 PM all  0.13  0.00  0.28  0.01  0.00 99.58
04:42:01 PM   0  0.09  0.00  0.14  0.01  0.00 99.76
04:42:01 PM   1  0.16  0.00  0.43  0.02  0.00 99.40
Average:all  1.95  0.00  0.70  0.03  0.00 97.33
Average:  0  1.32  0.00  0.59  0.02  0.00 98.07
Average:  1  2.58  0.00  0.80  0.04  0.00 96.58

I will continue to test but I think this is good.

Tested-by: Matthew Whitehead 

- Matthew W

> Reviewed-by: Steven Rostedt 
> 
> -- Steve
> 
> > Signed-off-by: Thomas Gleixner 
> > ---
> > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> > index 3822ac0..da6e6de 100644
> > --- a/kernel/rcu/tree_plugin.h
> > +++ b/kernel/rcu/tree_plugin.h
> > @@ -1632,7 +1632,7 @@ module_param(rcu_idle_gp_delay, int, 0644);
> >  static int rcu_idle_lazy_gp_delay = RCU_IDLE_LAZY_GP_DELAY;
> >  module_param(rcu_idle_lazy_gp_delay, int, 0644);
> >  
> > -extern int tick_nohz_enabled;
> > +extern int tick_nohz_active;
> >  
> >  /*
> >   * Try to advance callbacks for all flavors of RCU on the current CPU, but
> > @@ -1729,7 +1729,7 @@ static void rcu_prepare_for_idle(int cpu)
> > int tne;
> >  
> > /* Handle nohz enablement switches conservatively. */
> > -   tne = ACCESS_ONCE(tick_nohz_enabled);
> > +   tne = ACCESS_ONCE(tick_nohz_active);
> > if (tne != rdtp->tick_nohz_enabled_snap) {
> > if (rcu_cpu_has_callbacks(cpu, NULL))
> > invoke_rcu_core(); /* force nohz to see update. */
> > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > index 3612fc7..a12df5a 100644
> 

[PATCH 3/3] x86/Kconfig : Explicitly enumerate i686-class cpus in Kconfig

2018-02-15 Thread Matthew Whitehead
The X86_P6_NOP config class leaves out many i686-class cpus. Instead,
explicitly enumerate all these cpus.

Using a configuration with M686 currently sets X86_MINIMUM_CPU_FAMILY=5
instead of the correct value 6.

Booting on an i586 it will fail to generate the "This kernel
requires an i686 CPU, but only detected an i586 CPU" message and
intentional halt as expected. It will instead just silently hang
when it hits i686-specific instructions.

Signed-off-by: Matthew Whitehead 
---
 arch/x86/Kconfig.cpu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index ec64aa7..8b8d229 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -385,7 +385,7 @@ config X86_CMOV
 config X86_MINIMUM_CPU_FAMILY
int
default "64" if X86_64
-   default "6" if X86_32 && X86_P6_NOP
+   default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || 
MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MCRUSOE || 
MCORE2 || MK7 || MK8)
default "5" if X86_32 && X86_CMPXCHG64
default "4"
 
-- 
1.8.3.1



[PATCH 2/3] x86/Kconfig : Exclude i586-class cpus lacking PAE support from HIGHMEM64G Kconfig group

2018-02-15 Thread Matthew Whitehead
i586-class machines also lack support for Physical Address Extension (PAE),
so add them to the exclusion list

Signed-off-by: Matthew Whitehead 
---
 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 72d5149..89bf3fa 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1360,7 +1360,7 @@ config HIGHMEM4G
 
 config HIGHMEM64G
bool "64GB"
-   depends on !M486
+   depends on !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && 
!MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !WINCHIP3D && !MK6
select X86_PAE
---help---
  Select this if you have a 32-bit processor and more than 4
-- 
1.8.3.1



[PATCH 1/3] x86/Kconfig : Add missing i586-class cpus to X86_CMPXCHG64 Kconfig group

2018-02-15 Thread Matthew Whitehead
Several i586-class cpus supporting this instruction are missing from
the X86_CMPXCHG64 config group.

Using a configuration with either M586TSC or M586MMX currently sets
X86_MINIMUM_CPU_FAMILY=4 instead of the correct value 5.

Booting on an i486 it will fail to generate the "This kernel
requires an i586 CPU, but only detected an i486 CPU" message and
intentional halt as expected. It will instead just silently hang
when it hits i586-specific instructions.

The M586 cpu is not in this list because at least the Cyrix 5x86
lacks this instruction, and perhaps others.

Signed-off-by: Matthew Whitehead 
---
 arch/x86/Kconfig.cpu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 65a9a47..ec64aa7 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -374,7 +374,7 @@ config X86_TSC
 
 config X86_CMPXCHG64
def_bool y
-   depends on X86_PAE || X86_64 || MCORE2 || MPENTIUM4 || MPENTIUMM || 
MPENTIUMIII || MPENTIUMII || M686 || MATOM
+   depends on X86_PAE || X86_64 || MCORE2 || MPENTIUM4 || MPENTIUMM || 
MPENTIUMIII || MPENTIUMII || M686 || M586TSC || M586MMX || MATOM || MGEODE_LX 
|| MGEODEGX1 || MK6 || MK7 || MK8
 
 # this should be set for all -march=.. options where the compiler
 # generates cmov.
-- 
1.8.3.1



[PATCH] x86/perf : Add check for CPUID instruction before using

2018-02-02 Thread Matthew Whitehead
We still officially support the ancient i486 cpu. First generation
versions of this processor do not have the CPUID instruction, though
later versions do. Therefore you must check that the cpu supports
it before using it. At present it fails with an "Illegal Instruction"
signal on the early processors.

This code was based on similar code in the gcc package.

Signed-off-by: Matthew Whitehead 
---
 tools/perf/arch/x86/util/header.c | 51 +++
 tools/perf/util/header.h  |  2 ++
 2 files changed, 53 insertions(+)

diff --git a/tools/perf/arch/x86/util/header.c 
b/tools/perf/arch/x86/util/header.c
index fb0d71afee8b..d4d12894c64d 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -7,6 +7,54 @@
 
 #include "../../util/header.h"
 
+/* This code based on gcc cpuid.h __get_cpuid_max() */
+unsigned int have_cpuid(void)
+{
+   unsigned int __eax, __ebx;
+
+#ifndef __x86_64__
+/* See if we can use cpuid.  On AMD64 we always can.  */
+#if __GNUC__ >= 3
+   __asm__ ("pushf{l|d}\n\t"
+   "pushf{l|d}\n\t"
+   "pop{l}\t%0\n\t"
+   "mov{l}\t{%0, %1|%1, %0}\n\t"
+   "xor{l}\t{%2, %0|%0, %2}\n\t"
+   "push{l}\t%0\n\t"
+   "popf{l|d}\n\t"
+   "pushf{l|d}\n\t"
+   "pop{l}\t%0\n\t"
+   "popf{l|d}\n\t"
+   : "=" (__eax), "=" (__ebx)
+   : "i" (0x0020));
+#else
+/* Host GCCs older than 3.0 weren't supporting Intel asm syntax
+ * nor alternatives in i386 code.
+ */
+   __asm__ ("pushfl\n\t"
+   "pushfl\n\t"
+   "popl\t%0\n\t"
+   "movl\t%0, %1\n\t"
+   "xorl\t%2, %0\n\t"
+   "pushl\t%0\n\t"
+   "popfl\n\t"
+   "pushfl\n\t"
+   "popl\t%0\n\t"
+   "popfl\n\t"
+   : "=" (__eax), "=" (__ebx)
+   : "i" (0x0020));
+#endif
+
+   if (!((__eax ^ __ebx) & 0x0020))
+   return 0;
+   else
+   return 1;
+#endif
+
+/* All x86_64 support cpuid */
+   return 1;
+}
+
 static inline void
 cpuid(unsigned int op, unsigned int *a, unsigned int *b, unsigned int *c,
   unsigned int *d)
@@ -28,6 +76,9 @@ __get_cpuid(char *buffer, size_t sz, const char *fmt)
int nb;
char vendor[16];
 
+   if (!have_cpuid())
+   return -1;
+
cpuid(0, , , , );
strncpy([0], (char *)(), 4);
strncpy([4], (char *)(), 4);
diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index f283a440..ce31fca36077 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -171,6 +171,8 @@ int write_padded(struct feat_fd *fd, const void *bf,
 /*
  * arch specific callback
  */
+unsigned int have_cpuid(void);
+
 int get_cpuid(char *buffer, size_t sz);
 
 char *get_cpuid_str(struct perf_pmu *pmu __maybe_unused);
-- 
2.13.6



[PATCH v2] x86/perf : Add check for CPUID instruction before using

2018-02-02 Thread Matthew Whitehead
We still officially support the ancient i486 cpu. First generation
versions of this processor do not have the CPUID instruction, though
later versions do. Therefore you must check that the cpu supports
it before using it. At present it fails with an "Illegal Instruction"
signal on the early processors.

v1: cpuid detection code based on GCC gcc/config/i386/cpuid.h

https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/config/i386/cpuid.h;hb=HEAD
v2: cpuid detection code based on Linux kernel arch/x86/kernel/cpu/common.c

Signed-off-by: Matthew Whitehead 
---
 tools/perf/arch/x86/util/header.c | 54 +++
 tools/perf/util/header.h  |  2 ++
 2 files changed, 56 insertions(+)

diff --git a/tools/perf/arch/x86/util/header.c 
b/tools/perf/arch/x86/util/header.c
index fb0d71a..d2508b3 100644
--- a/tools/perf/arch/x86/util/header.c
+++ b/tools/perf/arch/x86/util/header.c
@@ -7,6 +7,57 @@
 
 #include "../../util/header.h"
 
+#ifndef __x86_64__
+
+/* This code based on arch/x86/kernel/cpu/common.c
+ * Standard macro to see if a specific flag is changeable.
+ */
+static inline int flag_is_changeable_p(u32 flag)
+{
+   u32 f1, f2;
+
+   /*
+* Cyrix and IDT cpus allow disabling of CPUID
+* so the code below may return different results
+* when it is executed before and after enabling
+* the CPUID. Add "volatile" to not allow gcc to
+* optimize the subsequent calls to this function.
+*/
+   asm volatile ("pushfl   \n\t"
+ "pushfl   \n\t"
+ "popl %0  \n\t"
+ "movl %0, %1  \n\t"
+ "xorl %2, %0  \n\t"
+ "pushl %0 \n\t"
+ "popfl\n\t"
+ "pushfl   \n\t"
+ "popl %0  \n\t"
+ "popfl\n\t"
+
+ : "=" (f1), "=" (f2)
+ : "ir" (flag));
+
+   return ((f1^f2) & flag) != 0;
+}
+
+#define X86_EFLAGS_ID 0x0020
+
+/* Probe for the CPUID instruction */
+int have_cpuid_p(void)
+{
+   return flag_is_changeable_p(X86_EFLAGS_ID);
+}
+
+#else  /* CONFIG_X86_64 */
+
+/* All X86_64 have cpuid instruction */
+int have_cpuid_p(void)
+{
+   return 1;
+}
+
+#endif /* CONFIG_X86_64 */
+
 static inline void
 cpuid(unsigned int op, unsigned int *a, unsigned int *b, unsigned int *c,
   unsigned int *d)
@@ -28,6 +79,9 @@
int nb;
char vendor[16];
 
+   if (!have_cpuid_p())
+   return -1;
+
cpuid(0, , , , );
strncpy([0], (char *)(), 4);
strncpy([4], (char *)(), 4);
diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h
index f28..f4de656 100644
--- a/tools/perf/util/header.h
+++ b/tools/perf/util/header.h
@@ -171,6 +171,8 @@ int write_padded(struct feat_fd *fd, const void *bf,
 /*
  * arch specific callback
  */
+int have_cpuid_p(void);
+
 int get_cpuid(char *buffer, size_t sz);
 
 char *get_cpuid_str(struct perf_pmu *pmu __maybe_unused);
-- 
1.8.3.1



[PATCH 2/3] x86/Kconfig : Exclude i586-class cpus lacking PAE support from HIGHMEM64G Kconfig group

2018-02-03 Thread Matthew Whitehead
i586-class machines also lack support for Physical Address Extension (PAE),
so add them to the exclusion list

Signed-off-by: Matthew Whitehead 
---
 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 423e4b6..c45fe6d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1359,7 +1359,7 @@ config HIGHMEM4G
 
 config HIGHMEM64G
bool "64GB"
-   depends on !M486
+   depends on !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && 
!MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !WINCHIP3D && !MK6
select X86_PAE
---help---
  Select this if you have a 32-bit processor and more than 4
-- 
1.8.3.1



[PATCH 1/3] x86/Kconfig : Add missing i586-class cpus to X86_CMPXCHG64 Kconfig group

2018-02-03 Thread Matthew Whitehead
Several i586-class cpus supporting this instruction are missing from
the X86_CMPXCHG64 config group.

Using a configuration with either M586TSC or M586MMX currently sets
X86_MINIMUM_CPU_FAMILY=4 instead of the correct value 5.

Booting on an i486 it will fail to generate the "This kernel
requires an i586 CPU, but only detected an i486 CPU" message and
intentional halt as expected. It will instead just silently hang
when it hits i586-specific instructions.

The M586 cpu is not in this list because at least the Cyrix 5x86
lacks this instruction, and perhaps others.

Signed-off-by: Matthew Whitehead 
---
 arch/x86/Kconfig.cpu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 65a9a47..ec64aa7 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -374,7 +374,7 @@ config X86_TSC
 
 config X86_CMPXCHG64
def_bool y
-   depends on X86_PAE || X86_64 || MCORE2 || MPENTIUM4 || MPENTIUMM || 
MPENTIUMIII || MPENTIUMII || M686 || MATOM
+   depends on X86_PAE || X86_64 || MCORE2 || MPENTIUM4 || MPENTIUMM || 
MPENTIUMIII || MPENTIUMII || M686 || M586TSC || M586MMX || MATOM || MGEODE_LX 
|| MGEODEGX1 || MK6 || MK7 || MK8
 
 # this should be set for all -march=.. options where the compiler
 # generates cmov.
-- 
1.8.3.1



[PATCH 3/3] x86/Kconfig : Explicitly enumerate i686-class cpus in Kconfig

2018-02-03 Thread Matthew Whitehead
The X86_P6_NOP config class leaves out many i686-class cpus. Instead,
explicitly enumerate all these cpus.

Using a configuration with M686 currently sets X86_MINIMUM_CPU_FAMILY=5
instead of the correct value 6.

Booting on an i586 it will fail to generate the "This kernel
requires an i686 CPU, but only detected an i586 CPU" message and
intentional halt as expected. It will instead just silently hang
when it hits i686-specific instructions.

Signed-off-by: Matthew Whitehead 
---
 arch/x86/Kconfig.cpu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index ec64aa7..8b8d229 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -385,7 +385,7 @@ config X86_CMOV
 config X86_MINIMUM_CPU_FAMILY
int
default "64" if X86_64
-   default "6" if X86_32 && X86_P6_NOP
+   default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || 
MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MCRUSOE || 
MCORE2 || MK7 || MK8)
default "5" if X86_32 && X86_CMPXCHG64
default "4"
 
-- 
1.8.3.1



[PATCH] x86: kvm: Restrict X86_FEATURE_VMMCALL to x86_64 platform

2018-07-30 Thread Matthew Whitehead
early_init_amd() is called on all AMD processors, both 64 and 32 bit.
Presently 32 bit processors get the X86_FEATURE_VMMCALL feature set, which
they do not support. Add conditionals to restrict it to 64 bit processors.

Cc: Paolo Bonzini 
Signed-off-by: Matthew Whitehead 
---
 arch/x86/kernel/cpu/amd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 38915fbfae73..df06919324cd 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -662,12 +662,14 @@ static void early_init_amd(struct cpuinfo_x86 *c)
}
 #endif
 
+#ifdef CONFIG_X86_64
/*
 * This is only needed to tell the kernel whether to use VMCALL
 * and VMMCALL.  VMMCALL is never executed except under virt, so
 * we can set it unconditionally.
 */
set_cpu_cap(c, X86_FEATURE_VMMCALL);
+#endif
 
/* F16h erratum 793, CVE-2013-6885 */
if (c->x86 == 0x16 && c->x86_model <= 0xf)
-- 
2.16.1



[PATCH] x86/cpu: Enable cpuid instruction on Cyrix 6x86/6x86L processors

2018-09-20 Thread Matthew Whitehead
On power up, the cpuid instruction is disabled on Cyrix 6x86 and 6x86L
processors and it needs to be enabled. There is code to do this, but it
does not work because it uses the broken {set,get}Cx86_old() macros.

There are comments in processor-cyrix.h advising you to _not_ make calls
using the deprecated macros in this style:

  setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);

This is because it expands the macro into a non-functioning calling
sequence. The new macros fix this problem, so we use them instead.

We also need to forcibly enable X86_FEATURE_CPUID. This is because
early_identify_cpu() does not know that the call to
identify_cpu_without_cpuid() actually enables the cpuid instruction in the
odd Cyrix case, and it turns X86_FEATURE_CPUID off after it has just been
enabled on the processor.

This was tested on actual Cyrix hardware.

Signed-off-by: Matthew Whitehead 
---
 arch/x86/kernel/cpu/cyrix.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index 8949b7a..e603cc5 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -437,10 +437,11 @@ static void cyrix_identify(struct cpuinfo_x86 *c)
/* enable MAPEN  */
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);
/* enable cpuid  */
-   setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);
+   setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x80);
/* disable MAPEN */
setCx86(CX86_CCR3, ccr3);
local_irq_restore(flags);
+   setup_force_cpu_cap(X86_FEATURE_CPUID);
}
}
 }
-- 
1.8.3.1



[PATCH v2 0/2] x86/cpu: Enable cpuid on Cyrix 6x86/6x86L processors

2018-09-21 Thread Matthew Whitehead
On power up, the cpuid instruction is disabled on Cyrix 6x86 and 6x86L
processors and needs to be enabled. This patchset enables it.

Matthew Whitehead (2):
  x86/cpu: Use correct macros for Cyrix calls
  x86/cpu: Change query logic so cpuid is enabled before testing

 arch/x86/kernel/cpu/common.c | 4 +++-
 arch/x86/kernel/cpu/cyrix.c  | 2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.16.4



[PATCH v2 1/2] x86/cpu: Use correct macros for Cyrix calls

2018-09-21 Thread Matthew Whitehead
There are comments in processor-cyrix.h advising you to _not_ make calls
using the deprecated macros in this style:

  setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);

This is because it expands the macro into a non-functioning calling
sequence. The calling order must be:

  outb(CX86_CCR2, 0x22);
  inb(0x23);

>From the comments:

 * When using the old macros a line like
 *   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
 * gets expanded to:
 *  do {
 *outb((CX86_CCR2), 0x22);
 *outb((({
 *outb((CX86_CCR2), 0x22);
 *inb(0x23);
 *}) | 0x88), 0x23);
 *  } while (0);

The new macros fix this problem, so we use them instead.

Reviewed-by: Andy Lutomirski 
Signed-off-by: Matthew Whitehead 
---
 arch/x86/kernel/cpu/cyrix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index 8949b7ae6d92..d12226f60168 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -437,7 +437,7 @@ static void cyrix_identify(struct cpuinfo_x86 *c)
/* enable MAPEN  */
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);
/* enable cpuid  */
-   setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);
+   setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x80);
/* disable MAPEN */
setCx86(CX86_CCR3, ccr3);
local_irq_restore(flags);
-- 
2.16.4



[PATCH v2 2/2] x86/cpu: Change query logic so cpuid is enabled before testing

2018-09-21 Thread Matthew Whitehead
Presently we check for cpuid to be enabled first. If it is not already
enabled, then we next call identify_cpu_without_cpuid() and clear
X86_FEATURE_CPUID.

Unfortunately, identify_cpu_without_cpuid() is the function where cpuid
becomes _enabled_ on Cyrix 6x86/6x86L cpus. So we must reverse the
calling sequence so that cpuid is first enabled, and then check a second
time to see if the feature has now been activated.

Reviewed-by: Andy Lutomirski 
Signed-off-by: Matthew Whitehead 
---
 arch/x86/kernel/cpu/common.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index eb4cb3efd20e..60c7c5ce7e55 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1040,6 +1040,9 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
*c)
memset(>x86_capability, 0, sizeof c->x86_capability);
c->extended_cpuid_level = 0;
 
+   if (!have_cpuid_p())
+   identify_cpu_without_cpuid(c);
+   
/* cyrix could have cpuid enabled via c_identify()*/
if (have_cpuid_p()) {
cpu_detect(c);
@@ -1057,7 +1060,6 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
*c)
if (this_cpu->c_bsp_init)
this_cpu->c_bsp_init(c);
} else {
-   identify_cpu_without_cpuid(c);
setup_clear_cpu_cap(X86_FEATURE_CPUID);
}
 
-- 
2.16.4



[PATCH 0/2] x86/CPU: Use correct Cyrix-specific macros

2019-03-14 Thread Matthew Whitehead
Replace the incorrect Cyrix-specific macro calls with the correct
setCx86() and getCx86() calls. Also remove the unused setCx86_old(),
getCx86_old() and their related comments in the code.

Matthew Whitehead (2):
  x86/CPU: Use correct macros for Cyrix calls on Geode processors
  x86/CPU: Remove {get,set}Cx86_old macros used for Cyrix processors

 arch/x86/include/asm/processor-cyrix.h | 21 -
 arch/x86/kernel/cpu/cyrix.c| 14 +++---
 2 files changed, 7 insertions(+), 28 deletions(-)

-- 
1.8.3.1



[PATCH 1/2] x86/CPU: Use correct macros for Cyrix calls on Geode processors

2019-03-14 Thread Matthew Whitehead
There are comments in processor-cyrix.h advising you to _not_ make calls
using the deprecated macros in this style:

  setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);

This is because it expands the macro into a non-functioning calling
sequence. The calling order must be:

  outb(CX86_CCR2, 0x22);
  inb(0x23);

>From the comments:

 * When using the old macros a line like
 *   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
 * gets expanded to:
 *  do {
 *outb((CX86_CCR2), 0x22);
 *outb((({
 *outb((CX86_CCR2), 0x22);
 *inb(0x23);
 *}) | 0x88), 0x23);
 *  } while (0);

The new macros fix this problem, so use them instead. Tested on an
actual Geode processor.

Signed-off-by: Matthew Whitehead 
---
 arch/x86/kernel/cpu/cyrix.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index d12226f..1d9b8aa 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -124,7 +124,7 @@ static void set_cx86_reorder(void)
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
 
/* Load/Store Serialize to mem access disable (=reorder it) */
-   setCx86_old(CX86_PCR0, getCx86_old(CX86_PCR0) & ~0x80);
+   setCx86(CX86_PCR0, getCx86(CX86_PCR0) & ~0x80);
/* set load/store serialize from 1GB to 4GB */
ccr3 |= 0xe0;
setCx86(CX86_CCR3, ccr3);
@@ -135,11 +135,11 @@ static void set_cx86_memwb(void)
pr_info("Enable Memory-Write-back mode on Cyrix/NSC processor.\n");
 
/* CCR2 bit 2: unlock NW bit */
-   setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) & ~0x04);
+   setCx86(CX86_CCR2, getCx86(CX86_CCR2) & ~0x04);
/* set 'Not Write-through' */
write_cr0(read_cr0() | X86_CR0_NW);
/* CCR2 bit 2: lock NW bit and set WT1 */
-   setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) | 0x14);
+   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x14);
 }
 
 /*
@@ -153,14 +153,14 @@ static void geode_configure(void)
local_irq_save(flags);
 
/* Suspend on halt power saving and enable #SUSP pin */
-   setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) | 0x88);
+   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
 
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);   /* enable MAPEN */
 
 
/* FPU fast, DTE cache, Mem bypass */
-   setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x38);
+   setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x38);
setCx86(CX86_CCR3, ccr3);   /* disable MAPEN */
 
set_cx86_memwb();
@@ -296,7 +296,7 @@ static void init_cyrix(struct cpuinfo_x86 *c)
/* GXm supports extended cpuid levels 'ala' AMD */
if (c->cpuid_level == 2) {
/* Enable cxMMX extensions (GX1 Datasheet 54) */
-   setCx86_old(CX86_CCR7, getCx86_old(CX86_CCR7) | 1);
+   setCx86(CX86_CCR7, getCx86(CX86_CCR7) | 1);
 
/*
 * GXm : 0x30 ... 0x5f GXm  datasheet 51
@@ -319,7 +319,7 @@ static void init_cyrix(struct cpuinfo_x86 *c)
if (dir1 > 7) {
dir0_msn++;  /* M II */
/* Enable MMX extensions (App note 108) */
-   setCx86_old(CX86_CCR7, getCx86_old(CX86_CCR7)|1);
+   setCx86(CX86_CCR7, getCx86(CX86_CCR7)|1);
} else {
/* A 6x86MX - it has the bug. */
set_cpu_bug(c, X86_BUG_COMA);
-- 
1.8.3.1



[PATCH 2/2] x86/CPU: Remove {get,set}Cx86_old macros used for Cyrix processors

2019-03-14 Thread Matthew Whitehead
The getCx86_old() and setCx86_old() macros have been replaced with
correctly working getCx86() and setCx86(), so remove these unused macros.

Signed-off-by: Matthew Whitehead 
---
 arch/x86/include/asm/processor-cyrix.h | 21 -
 1 file changed, 21 deletions(-)

diff --git a/arch/x86/include/asm/processor-cyrix.h 
b/arch/x86/include/asm/processor-cyrix.h
index aaedd73..df700a6 100644
--- a/arch/x86/include/asm/processor-cyrix.h
+++ b/arch/x86/include/asm/processor-cyrix.h
@@ -3,19 +3,6 @@
  * NSC/Cyrix CPU indexed register access. Must be inlined instead of
  * macros to ensure correct access ordering
  * Access order is always 0x22 (=offset), 0x23 (=value)
- *
- * When using the old macros a line like
- *   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
- * gets expanded to:
- *  do {
- *outb((CX86_CCR2), 0x22);
- *outb((({
- *outb((CX86_CCR2), 0x22);
- *inb(0x23);
- *}) | 0x88), 0x23);
- *  } while (0);
- *
- * which in fact violates the access order (= 0x22, 0x22, 0x23, 0x23).
  */
 
 static inline u8 getCx86(u8 reg)
@@ -29,11 +16,3 @@ static inline void setCx86(u8 reg, u8 data)
outb(reg, 0x22);
outb(data, 0x23);
 }
-
-#define getCx86_old(reg) ({ outb((reg), 0x22); inb(0x23); })
-
-#define setCx86_old(reg, data) do { \
-   outb((reg), 0x22); \
-   outb((data), 0x23); \
-} while (0)
-
-- 
1.8.3.1



[PATCH] x86/CPU: Use correct macros for Cyrix calls on Geode processors

2019-03-06 Thread Matthew Whitehead
There are comments in processor-cyrix.h advising you to _not_ make calls
using the deprecated macros in this style:

  setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);

This is because it expands the macro into a non-functioning calling
sequence. The calling order must be:

  outb(CX86_CCR2, 0x22);
  inb(0x23);

>From the comments:

 * When using the old macros a line like
 *   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
 * gets expanded to:
 *  do {
 *outb((CX86_CCR2), 0x22);
 *outb((({
 *outb((CX86_CCR2), 0x22);
 *inb(0x23);
 *}) | 0x88), 0x23);
 *  } while (0);

The new macros fix this problem, so use them instead. Tested on an
actual Geode processor.

Signed-off-by: Matthew Whitehead 
---
 arch/x86/kernel/cpu/cyrix.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index d12226f..1d9b8aa 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -124,7 +124,7 @@ static void set_cx86_reorder(void)
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
 
/* Load/Store Serialize to mem access disable (=reorder it) */
-   setCx86_old(CX86_PCR0, getCx86_old(CX86_PCR0) & ~0x80);
+   setCx86(CX86_PCR0, getCx86(CX86_PCR0) & ~0x80);
/* set load/store serialize from 1GB to 4GB */
ccr3 |= 0xe0;
setCx86(CX86_CCR3, ccr3);
@@ -135,11 +135,11 @@ static void set_cx86_memwb(void)
pr_info("Enable Memory-Write-back mode on Cyrix/NSC processor.\n");
 
/* CCR2 bit 2: unlock NW bit */
-   setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) & ~0x04);
+   setCx86(CX86_CCR2, getCx86(CX86_CCR2) & ~0x04);
/* set 'Not Write-through' */
write_cr0(read_cr0() | X86_CR0_NW);
/* CCR2 bit 2: lock NW bit and set WT1 */
-   setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) | 0x14);
+   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x14);
 }
 
 /*
@@ -153,14 +153,14 @@ static void geode_configure(void)
local_irq_save(flags);
 
/* Suspend on halt power saving and enable #SUSP pin */
-   setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) | 0x88);
+   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
 
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);   /* enable MAPEN */
 
 
/* FPU fast, DTE cache, Mem bypass */
-   setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x38);
+   setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x38);
setCx86(CX86_CCR3, ccr3);   /* disable MAPEN */
 
set_cx86_memwb();
@@ -296,7 +296,7 @@ static void init_cyrix(struct cpuinfo_x86 *c)
/* GXm supports extended cpuid levels 'ala' AMD */
if (c->cpuid_level == 2) {
/* Enable cxMMX extensions (GX1 Datasheet 54) */
-   setCx86_old(CX86_CCR7, getCx86_old(CX86_CCR7) | 1);
+   setCx86(CX86_CCR7, getCx86(CX86_CCR7) | 1);
 
/*
 * GXm : 0x30 ... 0x5f GXm  datasheet 51
@@ -319,7 +319,7 @@ static void init_cyrix(struct cpuinfo_x86 *c)
if (dir1 > 7) {
dir0_msn++;  /* M II */
/* Enable MMX extensions (App note 108) */
-   setCx86_old(CX86_CCR7, getCx86_old(CX86_CCR7)|1);
+   setCx86(CX86_CCR7, getCx86(CX86_CCR7)|1);
} else {
/* A 6x86MX - it has the bug. */
set_cpu_bug(c, X86_BUG_COMA);
-- 
1.8.3.1



[PATCH 1/2] x86/CPU: Use correct macros for Cyrix calls on Geode processors

2019-03-06 Thread Matthew Whitehead
There are comments in processor-cyrix.h advising you to _not_ make calls
using the deprecated macros in this style:

  setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);

This is because it expands the macro into a non-functioning calling
sequence. The calling order must be:

  outb(CX86_CCR2, 0x22);
  inb(0x23);

>From the comments:

 * When using the old macros a line like
 *   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
 * gets expanded to:
 *  do {
 *outb((CX86_CCR2), 0x22);
 *outb((({
 *outb((CX86_CCR2), 0x22);
 *inb(0x23);
 *}) | 0x88), 0x23);
 *  } while (0);

The new macros fix this problem, so use them instead. Tested on an
actual Geode processor.

Signed-off-by: Matthew Whitehead 
---
 arch/x86/kernel/cpu/cyrix.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index d12226f..1d9b8aa 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -124,7 +124,7 @@ static void set_cx86_reorder(void)
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
 
/* Load/Store Serialize to mem access disable (=reorder it) */
-   setCx86_old(CX86_PCR0, getCx86_old(CX86_PCR0) & ~0x80);
+   setCx86(CX86_PCR0, getCx86(CX86_PCR0) & ~0x80);
/* set load/store serialize from 1GB to 4GB */
ccr3 |= 0xe0;
setCx86(CX86_CCR3, ccr3);
@@ -135,11 +135,11 @@ static void set_cx86_memwb(void)
pr_info("Enable Memory-Write-back mode on Cyrix/NSC processor.\n");
 
/* CCR2 bit 2: unlock NW bit */
-   setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) & ~0x04);
+   setCx86(CX86_CCR2, getCx86(CX86_CCR2) & ~0x04);
/* set 'Not Write-through' */
write_cr0(read_cr0() | X86_CR0_NW);
/* CCR2 bit 2: lock NW bit and set WT1 */
-   setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) | 0x14);
+   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x14);
 }
 
 /*
@@ -153,14 +153,14 @@ static void geode_configure(void)
local_irq_save(flags);
 
/* Suspend on halt power saving and enable #SUSP pin */
-   setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) | 0x88);
+   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
 
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);   /* enable MAPEN */
 
 
/* FPU fast, DTE cache, Mem bypass */
-   setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x38);
+   setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x38);
setCx86(CX86_CCR3, ccr3);   /* disable MAPEN */
 
set_cx86_memwb();
@@ -296,7 +296,7 @@ static void init_cyrix(struct cpuinfo_x86 *c)
/* GXm supports extended cpuid levels 'ala' AMD */
if (c->cpuid_level == 2) {
/* Enable cxMMX extensions (GX1 Datasheet 54) */
-   setCx86_old(CX86_CCR7, getCx86_old(CX86_CCR7) | 1);
+   setCx86(CX86_CCR7, getCx86(CX86_CCR7) | 1);
 
/*
 * GXm : 0x30 ... 0x5f GXm  datasheet 51
@@ -319,7 +319,7 @@ static void init_cyrix(struct cpuinfo_x86 *c)
if (dir1 > 7) {
dir0_msn++;  /* M II */
/* Enable MMX extensions (App note 108) */
-   setCx86_old(CX86_CCR7, getCx86_old(CX86_CCR7)|1);
+   setCx86(CX86_CCR7, getCx86(CX86_CCR7)|1);
} else {
/* A 6x86MX - it has the bug. */
set_cpu_bug(c, X86_BUG_COMA);
-- 
1.8.3.1



[PATCH 0/2] x86/CPU: Use correct Cyrix-specific macros

2019-03-06 Thread Matthew Whitehead
Replace the incorrect Cyrix-specific macro calls with the correct
setCx86() and getCx86() calls. Also remove the unused setCx86_old(),
getCx86_old() and their related comments in the code.

Matthew Whitehead (2):
  x86/CPU: Use correct macros for Cyrix calls on Geode processors
  x86/CPU: Remove {get,set}Cx86_old macros used for Cyrix processors

 arch/x86/include/asm/processor-cyrix.h | 21 -
 arch/x86/kernel/cpu/cyrix.c| 14 +++---
 2 files changed, 7 insertions(+), 28 deletions(-)

-- 
1.8.3.1



[PATCH 2/2] x86/CPU: Remove {get,set}Cx86_old macros used for Cyrix processors

2019-03-06 Thread Matthew Whitehead
The getCx86_old() and setCx86_old() macros have been replaced with
correctly working getCx86() and setCx86(), so remove these unused macros.

Signed-off-by: Matthew Whitehead 
---
 arch/x86/include/asm/processor-cyrix.h | 21 -
 1 file changed, 21 deletions(-)

diff --git a/arch/x86/include/asm/processor-cyrix.h 
b/arch/x86/include/asm/processor-cyrix.h
index aaedd73..df700a6 100644
--- a/arch/x86/include/asm/processor-cyrix.h
+++ b/arch/x86/include/asm/processor-cyrix.h
@@ -3,19 +3,6 @@
  * NSC/Cyrix CPU indexed register access. Must be inlined instead of
  * macros to ensure correct access ordering
  * Access order is always 0x22 (=offset), 0x23 (=value)
- *
- * When using the old macros a line like
- *   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
- * gets expanded to:
- *  do {
- *outb((CX86_CCR2), 0x22);
- *outb((({
- *outb((CX86_CCR2), 0x22);
- *inb(0x23);
- *}) | 0x88), 0x23);
- *  } while (0);
- *
- * which in fact violates the access order (= 0x22, 0x22, 0x23, 0x23).
  */
 
 static inline u8 getCx86(u8 reg)
@@ -29,11 +16,3 @@ static inline void setCx86(u8 reg, u8 data)
outb(reg, 0x22);
outb(data, 0x23);
 }
-
-#define getCx86_old(reg) ({ outb((reg), 0x22); inb(0x23); })
-
-#define setCx86_old(reg, data) do { \
-   outb((reg), 0x22); \
-   outb((data), 0x23); \
-} while (0)
-
-- 
1.8.3.1



[PATCH 3.16] Backport of x86/vdso: Fix vDSO syscall fallback asm constraint regression

2019-01-19 Thread Matthew Whitehead
On Fri, Jan 18, 2019 at 9:07 PM tedheadster  wrote:
>
> I do not see this problem with the upstream kernel, so 3.16 probably
> needs a missing upstream patch.

This was indeed fixed by Andy Lutomirski's follow-up patch "x86/vdso: Fix vDSO 
syscall fallback asm constraint regression". I tested part of Andy's patch and 
it resolved the failure.

The 3.16 LTS kernel does not have the tools/testing/selftests/x86/test_vdso.c 
code, so a partial patch is indicated, unless Andy wants to provide that.

Kindly backport to 3.16 LTS series.

reported-by: Matthew Whitehead 
tested-by: Matthew Whitehead 
---
 arch/x86/vdso/vclock_gettime.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index 00b5ea4..a3d5326 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -147,11 +147,11 @@ notrace static long vdso_fallback_gettime(long clock, 
struct timespec *ts)
 
asm (
"mov %%ebx, %%edx \n"
-   "mov %2, %%ebx \n"
+   "mov %[clock], %%ebx \n"
"call __kernel_vsyscall \n"
"mov %%edx, %%ebx \n"
: "=a" (ret), "=m" (*ts)
-   : "0" (__NR_clock_gettime), "g" (clock), "c" (ts)
+   : "0" (__NR_clock_gettime), [clock] "g" (clock), "c" (ts)
: "memory", "edx");
return ret;
 }
@@ -162,11 +162,11 @@ notrace static long vdso_fallback_gtod(struct timeval 
*tv, struct timezone *tz)
 
asm (
"mov %%ebx, %%edx \n"
-   "mov %2, %%ebx \n"
+   "mov %[tv], %%ebx \n"
"call __kernel_vsyscall \n"
"mov %%edx, %%ebx \n"
: "=a" (ret), "=m" (*tv), "=m" (*tz)
-   : "0" (__NR_gettimeofday), "g" (tv), "c" (tz)
+   : "0" (__NR_gettimeofday), [tv] "g" (tv), "c" (tz)
: "memory", "edx");
return ret;
 }
-- 
1.8.3.1



[tip:x86/urgent] x86/Kconfig: Explicitly enumerate i686-class CPUs in Kconfig

2018-02-16 Thread tip-bot for Matthew Whitehead
Commit-ID:  25d76ac888216c369dea91768764728b83769799
Gitweb: https://git.kernel.org/tip/25d76ac888216c369dea91768764728b83769799
Author: Matthew Whitehead <tedheads...@gmail.com>
AuthorDate: Thu, 15 Feb 2018 11:54:56 -0500
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Fri, 16 Feb 2018 10:36:39 +0100

x86/Kconfig: Explicitly enumerate i686-class CPUs in Kconfig

The X86_P6_NOP config class leaves out many i686-class CPUs. Instead,
explicitly enumerate all these CPUs.

Using a configuration with M686 currently sets X86_MINIMUM_CPU_FAMILY=5
instead of the correct value of 6.

Booting on an i586 it will fail to generate the "This kernel
requires an i686 CPU, but only detected an i586 CPU" message and
intentional halt as expected. It will instead just silently hang
when it hits i686-specific instructions.

Signed-off-by: Matthew Whitehead <tedheads...@gmail.com>
Cc: Andy Lutomirski <l...@kernel.org>
Cc: Arjan van de Ven <ar...@linux.intel.com>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Link: 
http://lkml.kernel.org/r/1518713696-11360-3-git-send-email-tedheads...@gmail.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 arch/x86/Kconfig.cpu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index ec64aa7..8b8d229 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -385,7 +385,7 @@ config X86_CMOV
 config X86_MINIMUM_CPU_FAMILY
int
default "64" if X86_64
-   default "6" if X86_32 && X86_P6_NOP
+   default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || 
MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MCRUSOE || 
MCORE2 || MK7 || MK8)
default "5" if X86_32 && X86_CMPXCHG64
default "4"
 


[tip:x86/urgent] x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G Kconfig group

2018-02-16 Thread tip-bot for Matthew Whitehead
Commit-ID:  69b8d3fcabdc81d9efd82b4a506c8279cbaba692
Gitweb: https://git.kernel.org/tip/69b8d3fcabdc81d9efd82b4a506c8279cbaba692
Author: Matthew Whitehead <tedheads...@gmail.com>
AuthorDate: Thu, 15 Feb 2018 11:54:55 -0500
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Fri, 16 Feb 2018 10:36:39 +0100

x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G 
Kconfig group

i586-class machines also lack support for Physical Address Extension (PAE),
so add them to the exclusion list.

Signed-off-by: Matthew Whitehead <tedheads...@gmail.com>
Cc: Andy Lutomirski <l...@kernel.org>
Cc: Arjan van de Ven <ar...@linux.intel.com>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Link: 
http://lkml.kernel.org/r/1518713696-11360-2-git-send-email-tedheads...@gmail.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a528c14..c1236b1 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1404,7 +1404,7 @@ config HIGHMEM4G
 
 config HIGHMEM64G
bool "64GB"
-   depends on !M486
+   depends on !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && 
!MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !WINCHIP3D && !MK6
select X86_PAE
---help---
  Select this if you have a 32-bit processor and more than 4


[tip:x86/urgent] x86/Kconfig: Add missing i586-class CPUs to the X86_CMPXCHG64 Kconfig group

2018-02-16 Thread tip-bot for Matthew Whitehead
Commit-ID:  f960cfd12650fad43c1cde07a1f7642cf2c57f97
Gitweb: https://git.kernel.org/tip/f960cfd12650fad43c1cde07a1f7642cf2c57f97
Author: Matthew Whitehead <tedheads...@gmail.com>
AuthorDate: Thu, 15 Feb 2018 11:54:54 -0500
Committer:  Ingo Molnar <mi...@kernel.org>
CommitDate: Fri, 16 Feb 2018 10:36:39 +0100

x86/Kconfig: Add missing i586-class CPUs to the X86_CMPXCHG64 Kconfig group

Several i586-class CPUs supporting this instruction are missing from
the X86_CMPXCHG64 config group.

Using a configuration with either M586TSC or M586MMX currently sets
X86_MINIMUM_CPU_FAMILY=4 instead of the correct value of 5.

Booting on an i486 it will fail to generate the "This kernel
requires an i586 CPU, but only detected an i486 CPU" message and
intentional halt as expected. It will instead just silently hang
when it hits i586-specific instructions.

The M586 CPU is not in this list because at least the Cyrix 5x86
lacks this instruction, and perhaps others.

Signed-off-by: Matthew Whitehead <tedheads...@gmail.com>
Cc: Andy Lutomirski <l...@kernel.org>
Cc: Arjan van de Ven <ar...@linux.intel.com>
Cc: Borislav Petkov <b...@alien8.de>
Cc: Brian Gerst <brge...@gmail.com>
Cc: Denys Vlasenko <dvlas...@redhat.com>
Cc: H. Peter Anvin <h...@zytor.com>
Cc: Josh Poimboeuf <jpoim...@redhat.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Link: 
http://lkml.kernel.org/r/1518713696-11360-1-git-send-email-tedheads...@gmail.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
 arch/x86/Kconfig.cpu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 65a9a47..ec64aa7 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -374,7 +374,7 @@ config X86_TSC
 
 config X86_CMPXCHG64
def_bool y
-   depends on X86_PAE || X86_64 || MCORE2 || MPENTIUM4 || MPENTIUMM || 
MPENTIUMIII || MPENTIUMII || M686 || MATOM
+   depends on X86_PAE || X86_64 || MCORE2 || MPENTIUM4 || MPENTIUMM || 
MPENTIUMIII || MPENTIUMII || M686 || M586TSC || M586MMX || MATOM || MGEODE_LX 
|| MGEODEGX1 || MK6 || MK7 || MK8
 
 # this should be set for all -march=.. options where the compiler
 # generates cmov.


[tip:x86/cpu] x86/CPU: Use correct macros for Cyrix calls

2018-09-22 Thread tip-bot for Matthew Whitehead
Commit-ID:  03b099bdcdf7125d4a63dc9ddeefdd454e05123d
Gitweb: https://git.kernel.org/tip/03b099bdcdf7125d4a63dc9ddeefdd454e05123d
Author: Matthew Whitehead 
AuthorDate: Fri, 21 Sep 2018 17:20:40 -0400
Committer:  Borislav Petkov 
CommitDate: Sat, 22 Sep 2018 11:46:56 +0200

x86/CPU: Use correct macros for Cyrix calls

There are comments in processor-cyrix.h advising you to _not_ make calls
using the deprecated macros in this style:

  setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);

This is because it expands the macro into a non-functioning calling
sequence. The calling order must be:

  outb(CX86_CCR2, 0x22);
  inb(0x23);

>From the comments:

 * When using the old macros a line like
 *   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
 * gets expanded to:
 *  do {
 *outb((CX86_CCR2), 0x22);
 *outb((({
 *outb((CX86_CCR2), 0x22);
 *inb(0x23);
 *}) | 0x88), 0x23);
 *  } while (0);

The new macros fix this problem, so use them instead.

Signed-off-by: Matthew Whitehead 
Signed-off-by: Borislav Petkov 
Reviewed-by: Andy Lutomirski 
Cc: Greg Kroah-Hartman 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jia Zhang 
Cc: Peter Zijlstra 
Cc: Philippe Ombredanne 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20180921212041.13096-2-tedheads...@gmail.com
---
 arch/x86/kernel/cpu/cyrix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index 8949b7ae6d92..d12226f60168 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -437,7 +437,7 @@ static void cyrix_identify(struct cpuinfo_x86 *c)
/* enable MAPEN  */
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);
/* enable cpuid  */
-   setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);
+   setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x80);
/* disable MAPEN */
setCx86(CX86_CCR3, ccr3);
local_irq_restore(flags);


[tip:x86/cpu] x86/CPU: Change query logic so CPUID is enabled before testing

2018-09-22 Thread tip-bot for Matthew Whitehead
Commit-ID:  2893cc8ff892fa74972d8dc0e1d0dc65116daaa3
Gitweb: https://git.kernel.org/tip/2893cc8ff892fa74972d8dc0e1d0dc65116daaa3
Author: Matthew Whitehead 
AuthorDate: Fri, 21 Sep 2018 17:20:41 -0400
Committer:  Borislav Petkov 
CommitDate: Sat, 22 Sep 2018 11:47:39 +0200

x86/CPU: Change query logic so CPUID is enabled before testing

Presently we check first if CPUID is enabled. If it is not already
enabled, then we next call identify_cpu_without_cpuid() and clear
X86_FEATURE_CPUID.

Unfortunately, identify_cpu_without_cpuid() is the function where CPUID
becomes _enabled_ on Cyrix 6x86/6x86L CPUs.

Reverse the calling sequence so that CPUID is first enabled, and then
check a second time to see if the feature has now been activated.

[ bp: Massage commit message and remove trailing whitespace. ]

Suggested-by: Andy Lutomirski 
Signed-off-by: Matthew Whitehead 
Signed-off-by: Borislav Petkov 
Reviewed-by: Andy Lutomirski 
Cc: David Woodhouse 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Konrad Rzeszutek Wilk 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20180921212041.13096-3-tedheads...@gmail.com
---
 arch/x86/kernel/cpu/common.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 44c4ef3d989b..658c85d16a9b 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1076,6 +1076,9 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
*c)
memset(>x86_capability, 0, sizeof c->x86_capability);
c->extended_cpuid_level = 0;
 
+   if (!have_cpuid_p())
+   identify_cpu_without_cpuid(c);
+
/* cyrix could have cpuid enabled via c_identify()*/
if (have_cpuid_p()) {
cpu_detect(c);
@@ -1093,7 +1096,6 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
*c)
if (this_cpu->c_bsp_init)
this_cpu->c_bsp_init(c);
} else {
-   identify_cpu_without_cpuid(c);
setup_clear_cpu_cap(X86_FEATURE_CPUID);
}
 


[tip:x86/urgent] x86/Kconfig: Add missing i586-class CPUs to the X86_CMPXCHG64 Kconfig group

2018-02-16 Thread tip-bot for Matthew Whitehead
Commit-ID:  f960cfd12650fad43c1cde07a1f7642cf2c57f97
Gitweb: https://git.kernel.org/tip/f960cfd12650fad43c1cde07a1f7642cf2c57f97
Author: Matthew Whitehead 
AuthorDate: Thu, 15 Feb 2018 11:54:54 -0500
Committer:  Ingo Molnar 
CommitDate: Fri, 16 Feb 2018 10:36:39 +0100

x86/Kconfig: Add missing i586-class CPUs to the X86_CMPXCHG64 Kconfig group

Several i586-class CPUs supporting this instruction are missing from
the X86_CMPXCHG64 config group.

Using a configuration with either M586TSC or M586MMX currently sets
X86_MINIMUM_CPU_FAMILY=4 instead of the correct value of 5.

Booting on an i486 it will fail to generate the "This kernel
requires an i586 CPU, but only detected an i486 CPU" message and
intentional halt as expected. It will instead just silently hang
when it hits i586-specific instructions.

The M586 CPU is not in this list because at least the Cyrix 5x86
lacks this instruction, and perhaps others.

Signed-off-by: Matthew Whitehead 
Cc: Andy Lutomirski 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1518713696-11360-1-git-send-email-tedheads...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/Kconfig.cpu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 65a9a47..ec64aa7 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -374,7 +374,7 @@ config X86_TSC
 
 config X86_CMPXCHG64
def_bool y
-   depends on X86_PAE || X86_64 || MCORE2 || MPENTIUM4 || MPENTIUMM || 
MPENTIUMIII || MPENTIUMII || M686 || MATOM
+   depends on X86_PAE || X86_64 || MCORE2 || MPENTIUM4 || MPENTIUMM || 
MPENTIUMIII || MPENTIUMII || M686 || M586TSC || M586MMX || MATOM || MGEODE_LX 
|| MGEODEGX1 || MK6 || MK7 || MK8
 
 # this should be set for all -march=.. options where the compiler
 # generates cmov.


[tip:x86/urgent] x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G Kconfig group

2018-02-16 Thread tip-bot for Matthew Whitehead
Commit-ID:  69b8d3fcabdc81d9efd82b4a506c8279cbaba692
Gitweb: https://git.kernel.org/tip/69b8d3fcabdc81d9efd82b4a506c8279cbaba692
Author: Matthew Whitehead 
AuthorDate: Thu, 15 Feb 2018 11:54:55 -0500
Committer:  Ingo Molnar 
CommitDate: Fri, 16 Feb 2018 10:36:39 +0100

x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G 
Kconfig group

i586-class machines also lack support for Physical Address Extension (PAE),
so add them to the exclusion list.

Signed-off-by: Matthew Whitehead 
Cc: Andy Lutomirski 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1518713696-11360-2-git-send-email-tedheads...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a528c14..c1236b1 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1404,7 +1404,7 @@ config HIGHMEM4G
 
 config HIGHMEM64G
bool "64GB"
-   depends on !M486
+   depends on !M486 && !M586 && !M586TSC && !M586MMX && !MGEODE_LX && 
!MGEODEGX1 && !MCYRIXIII && !MELAN && !MWINCHIPC6 && !WINCHIP3D && !MK6
select X86_PAE
---help---
  Select this if you have a 32-bit processor and more than 4


[tip:x86/urgent] x86/Kconfig: Explicitly enumerate i686-class CPUs in Kconfig

2018-02-16 Thread tip-bot for Matthew Whitehead
Commit-ID:  25d76ac888216c369dea91768764728b83769799
Gitweb: https://git.kernel.org/tip/25d76ac888216c369dea91768764728b83769799
Author: Matthew Whitehead 
AuthorDate: Thu, 15 Feb 2018 11:54:56 -0500
Committer:  Ingo Molnar 
CommitDate: Fri, 16 Feb 2018 10:36:39 +0100

x86/Kconfig: Explicitly enumerate i686-class CPUs in Kconfig

The X86_P6_NOP config class leaves out many i686-class CPUs. Instead,
explicitly enumerate all these CPUs.

Using a configuration with M686 currently sets X86_MINIMUM_CPU_FAMILY=5
instead of the correct value of 6.

Booting on an i586 it will fail to generate the "This kernel
requires an i686 CPU, but only detected an i586 CPU" message and
intentional halt as expected. It will instead just silently hang
when it hits i686-specific instructions.

Signed-off-by: Matthew Whitehead 
Cc: Andy Lutomirski 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1518713696-11360-3-git-send-email-tedheads...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/Kconfig.cpu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index ec64aa7..8b8d229 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -385,7 +385,7 @@ config X86_CMOV
 config X86_MINIMUM_CPU_FAMILY
int
default "64" if X86_64
-   default "6" if X86_32 && X86_P6_NOP
+   default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || 
MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MCRUSOE || 
MCORE2 || MK7 || MK8)
default "5" if X86_32 && X86_CMPXCHG64
default "4"
 


[tip:x86/cpu] x86/CPU: Use correct macros for Cyrix calls

2018-09-22 Thread tip-bot for Matthew Whitehead
Commit-ID:  03b099bdcdf7125d4a63dc9ddeefdd454e05123d
Gitweb: https://git.kernel.org/tip/03b099bdcdf7125d4a63dc9ddeefdd454e05123d
Author: Matthew Whitehead 
AuthorDate: Fri, 21 Sep 2018 17:20:40 -0400
Committer:  Borislav Petkov 
CommitDate: Sat, 22 Sep 2018 11:46:56 +0200

x86/CPU: Use correct macros for Cyrix calls

There are comments in processor-cyrix.h advising you to _not_ make calls
using the deprecated macros in this style:

  setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);

This is because it expands the macro into a non-functioning calling
sequence. The calling order must be:

  outb(CX86_CCR2, 0x22);
  inb(0x23);

>From the comments:

 * When using the old macros a line like
 *   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
 * gets expanded to:
 *  do {
 *outb((CX86_CCR2), 0x22);
 *outb((({
 *outb((CX86_CCR2), 0x22);
 *inb(0x23);
 *}) | 0x88), 0x23);
 *  } while (0);

The new macros fix this problem, so use them instead.

Signed-off-by: Matthew Whitehead 
Signed-off-by: Borislav Petkov 
Reviewed-by: Andy Lutomirski 
Cc: Greg Kroah-Hartman 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jia Zhang 
Cc: Peter Zijlstra 
Cc: Philippe Ombredanne 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20180921212041.13096-2-tedheads...@gmail.com
---
 arch/x86/kernel/cpu/cyrix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index 8949b7ae6d92..d12226f60168 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -437,7 +437,7 @@ static void cyrix_identify(struct cpuinfo_x86 *c)
/* enable MAPEN  */
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);
/* enable cpuid  */
-   setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);
+   setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x80);
/* disable MAPEN */
setCx86(CX86_CCR3, ccr3);
local_irq_restore(flags);


[tip:x86/cpu] x86/CPU: Change query logic so CPUID is enabled before testing

2018-09-22 Thread tip-bot for Matthew Whitehead
Commit-ID:  2893cc8ff892fa74972d8dc0e1d0dc65116daaa3
Gitweb: https://git.kernel.org/tip/2893cc8ff892fa74972d8dc0e1d0dc65116daaa3
Author: Matthew Whitehead 
AuthorDate: Fri, 21 Sep 2018 17:20:41 -0400
Committer:  Borislav Petkov 
CommitDate: Sat, 22 Sep 2018 11:47:39 +0200

x86/CPU: Change query logic so CPUID is enabled before testing

Presently we check first if CPUID is enabled. If it is not already
enabled, then we next call identify_cpu_without_cpuid() and clear
X86_FEATURE_CPUID.

Unfortunately, identify_cpu_without_cpuid() is the function where CPUID
becomes _enabled_ on Cyrix 6x86/6x86L CPUs.

Reverse the calling sequence so that CPUID is first enabled, and then
check a second time to see if the feature has now been activated.

[ bp: Massage commit message and remove trailing whitespace. ]

Suggested-by: Andy Lutomirski 
Signed-off-by: Matthew Whitehead 
Signed-off-by: Borislav Petkov 
Reviewed-by: Andy Lutomirski 
Cc: David Woodhouse 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Konrad Rzeszutek Wilk 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20180921212041.13096-3-tedheads...@gmail.com
---
 arch/x86/kernel/cpu/common.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 44c4ef3d989b..658c85d16a9b 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1076,6 +1076,9 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
*c)
memset(>x86_capability, 0, sizeof c->x86_capability);
c->extended_cpuid_level = 0;
 
+   if (!have_cpuid_p())
+   identify_cpu_without_cpuid(c);
+
/* cyrix could have cpuid enabled via c_identify()*/
if (have_cpuid_p()) {
cpu_detect(c);
@@ -1093,7 +1096,6 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
*c)
if (this_cpu->c_bsp_init)
this_cpu->c_bsp_init(c);
} else {
-   identify_cpu_without_cpuid(c);
setup_clear_cpu_cap(X86_FEATURE_CPUID);
}
 


[tip:x86/urgent] x86/cpu/cyrix: Use correct macros for Cyrix calls on Geode processors

2019-03-21 Thread tip-bot for Matthew Whitehead
Commit-ID:  18fb053f9b827bd98cfc64f2a35df8ab19745a1d
Gitweb: https://git.kernel.org/tip/18fb053f9b827bd98cfc64f2a35df8ab19745a1d
Author: Matthew Whitehead 
AuthorDate: Thu, 14 Mar 2019 16:46:00 -0400
Committer:  Thomas Gleixner 
CommitDate: Thu, 21 Mar 2019 12:28:50 +0100

x86/cpu/cyrix: Use correct macros for Cyrix calls on Geode processors

There are comments in processor-cyrix.h advising you to _not_ make calls
using the deprecated macros in this style:

  setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);

This is because it expands the macro into a non-functioning calling
sequence. The calling order must be:

  outb(CX86_CCR2, 0x22);
  inb(0x23);

>From the comments:

 * When using the old macros a line like
 *   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
 * gets expanded to:
 *  do {
 *outb((CX86_CCR2), 0x22);
 *outb((({
 *outb((CX86_CCR2), 0x22);
 *inb(0x23);
 *}) | 0x88), 0x23);
 *  } while (0);

The new macros fix this problem, so use them instead. Tested on an
actual Geode processor.

Signed-off-by: Matthew Whitehead 
Signed-off-by: Thomas Gleixner 
Cc: l...@kernel.org
Link: 
https://lkml.kernel.org/r/1552596361-8967-2-git-send-email-tedheads...@gmail.com

---
 arch/x86/kernel/cpu/cyrix.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/cyrix.c b/arch/x86/kernel/cpu/cyrix.c
index d12226f60168..1d9b8aaea06c 100644
--- a/arch/x86/kernel/cpu/cyrix.c
+++ b/arch/x86/kernel/cpu/cyrix.c
@@ -124,7 +124,7 @@ static void set_cx86_reorder(void)
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
 
/* Load/Store Serialize to mem access disable (=reorder it) */
-   setCx86_old(CX86_PCR0, getCx86_old(CX86_PCR0) & ~0x80);
+   setCx86(CX86_PCR0, getCx86(CX86_PCR0) & ~0x80);
/* set load/store serialize from 1GB to 4GB */
ccr3 |= 0xe0;
setCx86(CX86_CCR3, ccr3);
@@ -135,11 +135,11 @@ static void set_cx86_memwb(void)
pr_info("Enable Memory-Write-back mode on Cyrix/NSC processor.\n");
 
/* CCR2 bit 2: unlock NW bit */
-   setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) & ~0x04);
+   setCx86(CX86_CCR2, getCx86(CX86_CCR2) & ~0x04);
/* set 'Not Write-through' */
write_cr0(read_cr0() | X86_CR0_NW);
/* CCR2 bit 2: lock NW bit and set WT1 */
-   setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) | 0x14);
+   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x14);
 }
 
 /*
@@ -153,14 +153,14 @@ static void geode_configure(void)
local_irq_save(flags);
 
/* Suspend on halt power saving and enable #SUSP pin */
-   setCx86_old(CX86_CCR2, getCx86_old(CX86_CCR2) | 0x88);
+   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
 
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);   /* enable MAPEN */
 
 
/* FPU fast, DTE cache, Mem bypass */
-   setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x38);
+   setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x38);
setCx86(CX86_CCR3, ccr3);   /* disable MAPEN */
 
set_cx86_memwb();
@@ -296,7 +296,7 @@ static void init_cyrix(struct cpuinfo_x86 *c)
/* GXm supports extended cpuid levels 'ala' AMD */
if (c->cpuid_level == 2) {
/* Enable cxMMX extensions (GX1 Datasheet 54) */
-   setCx86_old(CX86_CCR7, getCx86_old(CX86_CCR7) | 1);
+   setCx86(CX86_CCR7, getCx86(CX86_CCR7) | 1);
 
/*
 * GXm : 0x30 ... 0x5f GXm  datasheet 51
@@ -319,7 +319,7 @@ static void init_cyrix(struct cpuinfo_x86 *c)
if (dir1 > 7) {
dir0_msn++;  /* M II */
/* Enable MMX extensions (App note 108) */
-   setCx86_old(CX86_CCR7, getCx86_old(CX86_CCR7)|1);
+   setCx86(CX86_CCR7, getCx86(CX86_CCR7)|1);
} else {
/* A 6x86MX - it has the bug. */
set_cpu_bug(c, X86_BUG_COMA);


[tip:x86/urgent] x86/cpu/cyrix: Remove {get,set}Cx86_old macros used for Cyrix processors

2019-03-21 Thread tip-bot for Matthew Whitehead
Commit-ID:  0f4d3aa761b71cd6984330baca1e18bf0590e441
Gitweb: https://git.kernel.org/tip/0f4d3aa761b71cd6984330baca1e18bf0590e441
Author: Matthew Whitehead 
AuthorDate: Thu, 14 Mar 2019 16:46:01 -0400
Committer:  Thomas Gleixner 
CommitDate: Thu, 21 Mar 2019 12:28:50 +0100

x86/cpu/cyrix: Remove {get,set}Cx86_old macros used for Cyrix processors

The getCx86_old() and setCx86_old() macros have been replaced with
correctly working getCx86() and setCx86(), so remove these unused macros.

Signed-off-by: Matthew Whitehead 
Signed-off-by: Thomas Gleixner 
Cc: l...@kernel.org
Link: 
https://lkml.kernel.org/r/1552596361-8967-3-git-send-email-tedheads...@gmail.com

---
 arch/x86/include/asm/processor-cyrix.h | 21 -
 1 file changed, 21 deletions(-)

diff --git a/arch/x86/include/asm/processor-cyrix.h 
b/arch/x86/include/asm/processor-cyrix.h
index aaedd73ea2c6..df700a6cc869 100644
--- a/arch/x86/include/asm/processor-cyrix.h
+++ b/arch/x86/include/asm/processor-cyrix.h
@@ -3,19 +3,6 @@
  * NSC/Cyrix CPU indexed register access. Must be inlined instead of
  * macros to ensure correct access ordering
  * Access order is always 0x22 (=offset), 0x23 (=value)
- *
- * When using the old macros a line like
- *   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
- * gets expanded to:
- *  do {
- *outb((CX86_CCR2), 0x22);
- *outb((({
- *outb((CX86_CCR2), 0x22);
- *inb(0x23);
- *}) | 0x88), 0x23);
- *  } while (0);
- *
- * which in fact violates the access order (= 0x22, 0x22, 0x23, 0x23).
  */
 
 static inline u8 getCx86(u8 reg)
@@ -29,11 +16,3 @@ static inline void setCx86(u8 reg, u8 data)
outb(reg, 0x22);
outb(data, 0x23);
 }
-
-#define getCx86_old(reg) ({ outb((reg), 0x22); inb(0x23); })
-
-#define setCx86_old(reg, data) do { \
-   outb((reg), 0x22); \
-   outb((data), 0x23); \
-} while (0)
-