答复: 答复: Re: [tip:x86/urgent] x86/mce: Ensure offline CPUs don' t participate in rendezvous process

2019-05-30 Thread David Wang
> -Original Mail-
> Sender: Raj, Ashok 
> Time: 2019.05.31 1:11
> To : Tony W Wang-oc 
> CC: tip...@zytor.com; b...@suse.de; h...@zytor.com;
> linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-tip-comm...@vger.kernel.org; mi...@kernel.org; pet...@infradead.org;
> sta...@vger.kernel.org; t...@linutronix.de; tony.l...@intel.com;
> torva...@linux-foundation.org; David Wang ; Ashok
> Raj 
> Topic: Re: Re: Re: [tip:x86/urgent] x86/mce: Ensure offline CPUs don' t
> participate in rendezvous process
> 
> On Thu, May 30, 2019 at 09:13:39AM +, Tony W Wang-oc wrote:
> > On Thu, May 30, 2019, Tony W Wang-oc wrote:
> > > Hi Ashok,
> > > I have two questions about this patch, could you help to check:
> > >
> > > 1, for broadcast #MC exceptions, this patch seems require #MC
> > > exception errors set MCG_STATUS_RIPV = 1.
> > > But for Intel CPU, some #MC exception errors set MCG_STATUS_RIPV = 0
> > > (like "Recoverable-not-continuable SRAR Type" Errors), for these
> > > errors the patch doesn't seem to work, is that okay?
> > >
> > > 2, for LMCE exceptions, this patch seems require #MC exception
> > > errors set MCG_STATUS_RIPV = 0 to make sure LMCE be handled normally
> > > even on offline CPU.
> > > For LMCE errors set MCG_STAUS_RIPV = 1, the patch prevents offline
> > > CPU handle these LMCE errors, is that okay?
> > >
> >
> > More specifically, this patch seems require #MC exceptions meet the
> > condition "MCG_STATUS_RIPV ^ MCG_STATUS_LMCES == 1"; But on a Xeon
> > X5650 machine (SMP),
> 
> The offline CPU will never get a LMCE=1, since those only happen on the CPU
> that's doing active work. Offline CPUs just sitting in idle.
So, for intel CPU, LMCE is only for Thread level(or core level) error? If not, 
suppose 2 threads
share level-2 cache. And thread 0 is active, thread 1 was offlined by SW. When 
MCE for this level-2
cache occurred, thread 1 will be active. When thread 1 read mcgstatus.lmce, the 
result will be always 0?

Thanks.
> 
> The specific error here is a PCC=1, so irrespective of what happens We do 
> capture
> the errors in the per-cpu log, and kernel would panic.
> 
> What specifically this patch tries to achieve is to leave an error sitting 
> with
> MCG-STATUS.MCIP=1 and another recoverable error would shut the system
> dowm.
> 
> I don't see anything wrong with what this patch does..
> 
> > "Data CACHE Level-2 Generic Error" does not meet this condition.
> >
> > I got below message from:
> > https://www.centos.org/forums/viewtopic.php?p=292742
> >
> > Hardware event. This is not a software error.
> > MCE 0
> > CPU 4 BANK 6 TSC b7065eeaa18b0
> > TIME 1545643603 Mon Dec 24 10:26:43 2018 MCG status:MCIP MCi status:
> > Uncorrected error
> > Error enabled
> > Processor context corrupt
> > MCA: Data CACHE Level-2 Generic Error
> > STATUS b2008106 MCGSTATUS 4
> > MCGCAP 1c09 APICID 4 SOCKETID 0
> > CPUID Vendor Intel Family 6 Model 44
> >
> > > Thanks
> > > Tony W Wang-oc


[tip:x86/cpu] x86/power: Optimize C3 entry on Centaur CPUs

2019-04-19 Thread tip-bot for David Wang
Commit-ID:  987ddbe4870b53623d76ac64044c55a13e368113
Gitweb: https://git.kernel.org/tip/987ddbe4870b53623d76ac64044c55a13e368113
Author: David Wang 
AuthorDate: Thu, 27 Dec 2018 16:41:50 +0800
Committer:  Ingo Molnar 
CommitDate: Fri, 19 Apr 2019 19:28:06 +0200

x86/power: Optimize C3 entry on Centaur CPUs

For new Centaur CPUs the ucode will take care of the preservation of cache 
coherence
between CPU cores in C-states regardless of how deep the C-states are. So, it 
is not
necessary to flush the caches in software befor entering C3. This useless 
operation
will cause performance drop for the cores which share some caches with the 
idling core.

Signed-off-by: David Wang 
Reviewed-by: Thomas Gleixner 
Acked-by: Pavel Machek 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: brucech...@via-alliance.com
Cc: cooper...@zhaoxin.com
Cc: len.br...@intel.com
Cc: linux...@kernel.org
Cc: qiyuanw...@zhaoxin.com
Cc: r...@rjwysocki.net
Cc: tim...@zhaoxin.com
Link: 
http://lkml.kernel.org/r/1545900110-2757-1-git-send-email-davidw...@zhaoxin.com
[ Tidy up the comment. ]
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/acpi/cstate.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
index 158ad1483c43..cb6e076a6d39 100644
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -51,6 +51,18 @@ void acpi_processor_power_init_bm_check(struct 
acpi_processor_flags *flags,
if (c->x86_vendor == X86_VENDOR_INTEL &&
(c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
flags->bm_control = 0;
+   /*
+* For all recent Centaur CPUs, the ucode will make sure that each
+* core can keep cache coherence with each other while entering C3
+* type state. So, set bm_check to 1 to indicate that the kernel
+* doesn't need to execute a cache flush operation (WBINVD) when
+* entering C3 type state.
+*/
+   if (c->x86_vendor == X86_VENDOR_CENTAUR) {
+   if (c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0x0f &&
+   c->x86_stepping >= 0x0e))
+   flags->bm_check = 1;
+   }
 }
 EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
 


[PATCH v3] Optimize C3 entry on Centaur CPUs

2018-12-27 Thread David Wang
For new Centaur CPUs the ucode will take care of the preservation of cache 
coherence
between CPU cores in C-states regardless of how deep the C-states are. So, it 
is not
necessary to flush the caches in software befor entering C3. And this useless 
operation
will cause performance drop for the cores which share some caches with the 
idling core.  

Signed-off-by: David Wang 
Reviewed-by: Thomas Gleixner 

Changes from v2 to v3:
*1, Replace "c->x86_mask" with "c->x86_stepping".

Changes from v1 to v2:
* 1, Add some Family/Model/Stepping contrains to let this patch only apply
* to new centaur CPUs.
* 2, The arbiter disable/enable operations maybe needed for old VIA/Centaur
* platform. So, delete "flags->bm_control=0" in patch v1.

---
 arch/x86/kernel/acpi/cstate.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
index 158ad14..ed17640 100644
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -51,6 +51,18 @@ void acpi_processor_power_init_bm_check(struct 
acpi_processor_flags *flags,
if (c->x86_vendor == X86_VENDOR_INTEL &&
(c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
flags->bm_control = 0;
+   /*
+   * For all recent Centaur CPUs, the ucode will make sure that each
+   * core can keep cache coherence with each other while entering C3
+   * type state. So, set bm_check to 1 to indicate that the kernel
+   * need not execute a cache flush operation (WBINVD) when entering
+   * C3 type state.
+   */
+   if (c->x86_vendor == X86_VENDOR_CENTAUR) {
+   if (c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0x0f &&
+   c->x86_stepping >= 0x0e))
+   flags->bm_check = 1;
+   }
 }
 EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
 
-- 
1.9.1



Re: [PATCH v2] x86/mce: add CMCI support for Centaur CPUs

2018-07-03 Thread David Wang



> -Original Mail-
>  Sender: Borislav Petkov [mailto:b...@alien8.de]
>  Time: 2018年6月26日 22:30
>  Receiver: David Wang 
> CC: tony.l...@intel.com; mi...@redhat.com; t...@linutronix.de;
> h...@zytor.com; x...@kernel.org; linux-kernel@vger.kernel.org;
> linux-e...@vger.kernel.org; cooper...@zhaoxin.com;
> qiyuanw...@zhaoxin.com; benjamin...@viatech.com;
> luke...@viacpu.com; tim...@zhaoxin.com
> Topic : Re: [PATCH v2] x86/mce: add CMCI support for Centaur CPUs
> 
> On Mon, Jun 04, 2018 at 10:37:33AM +0800, David Wang wrote:
> > New Centaur CPU support CMCI mechanism, which is compatible with
> INTEL CMCI.
> >
> > Signed-off-by: David Wang 
> 
> ...
> 
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> > b/arch/x86/kernel/cpu/mcheck/mce.c
> > index cd76380..2ebafc7 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> > @@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct
> cpuinfo_x86 *c)
> > }
> >  }
> >
> > +#ifdef CONFIG_X86_MCE_CENTAUR
> >  static void mce_centaur_feature_init(struct cpuinfo_x86 *c)  {
> > struct mca_config *cfg = _cfg;
> > @@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct
> cpuinfo_x86 *c)
> > if (cfg->monarch_timeout < 0)
> > cfg->monarch_timeout = USEC_PER_SEC;
> > }
> > +   mce_intel_feature_init(c);
> > +   mce_adjust_timer = cmci_intel_adjust_timer;
> 
> This ...
> 
> >  }
> > +#else
> > +static inline void mce_centaur_feature_init(struct cpuinfo_x86 *c) {
> > +} #endif
> >
> >  static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)  { diff
> > --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> > b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> > index d05be30..5b1b68f 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> > @@ -85,7 +85,8 @@ static int cmci_supported(int *banks)
> >  * initialization is vendor keyed and this
> >  * makes sure none of the backdoors are entered otherwise.
> >  */
> > -   if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
> > +   if ((boot_cpu_data.x86_vendor != X86_VENDOR_INTEL &&
> > +   boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR))
> > return 0;
> > if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6)
> > return 0;
> > @@ -506,10 +507,20 @@ static void intel_ppin_init(struct cpuinfo_x86
> > *c)
> >
> >  void mce_intel_feature_init(struct cpuinfo_x86 *c)  {
> > -   intel_init_thermal(c);
> > -   intel_init_cmci();
> > -   intel_init_lmce();
> > -   intel_ppin_init(c);
> > +
> > +   switch (c->x86_vendor) {
> > +   case X86_VENDOR_INTEL:
> > +   intel_init_thermal(c);
> > +   intel_init_cmci();
> > +   intel_init_lmce();
> > +   intel_ppin_init(c);
> > +   break;
> > +   case X86_VENDOR_CENTAUR:
> > +   intel_init_cmci();
> 
> ... and this I really don't like for the simple reason that if the Intel side 
> gets
> changed, it could potentially break Centaur. And we don't want that. And
> the vendor should be free to change their code without asking another
> vendor for permission even if the other vendor is almost copying the
> code...
> 
> Long story short, I think you should extract the facilities you're going to
> need into generic, library-like ones and call them from centaur-specific
> compilation units which get enabled when CPU_SUP_CENTAUR is enabled.
> 
> So that the code can still be shared but there's no dependency on other
> vendors and so that one vendor doesn't break the other one and
> vice-versa.
> 
> IMO.
> 
> Thx.
> 
OK. I will adjust code.
Thank you.
> --
> Regards/Gruss,
> Boris.
> 
> Good mailing practices for 400: avoid top-posting and trim the reply.



Re: [PATCH v2] x86/mce: add CMCI support for Centaur CPUs

2018-07-03 Thread David Wang



> -Original Mail-
>  Sender: Borislav Petkov [mailto:b...@alien8.de]
>  Time: 2018年6月26日 22:30
>  Receiver: David Wang 
> CC: tony.l...@intel.com; mi...@redhat.com; t...@linutronix.de;
> h...@zytor.com; x...@kernel.org; linux-kernel@vger.kernel.org;
> linux-e...@vger.kernel.org; cooper...@zhaoxin.com;
> qiyuanw...@zhaoxin.com; benjamin...@viatech.com;
> luke...@viacpu.com; tim...@zhaoxin.com
> Topic : Re: [PATCH v2] x86/mce: add CMCI support for Centaur CPUs
> 
> On Mon, Jun 04, 2018 at 10:37:33AM +0800, David Wang wrote:
> > New Centaur CPU support CMCI mechanism, which is compatible with
> INTEL CMCI.
> >
> > Signed-off-by: David Wang 
> 
> ...
> 
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> > b/arch/x86/kernel/cpu/mcheck/mce.c
> > index cd76380..2ebafc7 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> > @@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct
> cpuinfo_x86 *c)
> > }
> >  }
> >
> > +#ifdef CONFIG_X86_MCE_CENTAUR
> >  static void mce_centaur_feature_init(struct cpuinfo_x86 *c)  {
> > struct mca_config *cfg = _cfg;
> > @@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct
> cpuinfo_x86 *c)
> > if (cfg->monarch_timeout < 0)
> > cfg->monarch_timeout = USEC_PER_SEC;
> > }
> > +   mce_intel_feature_init(c);
> > +   mce_adjust_timer = cmci_intel_adjust_timer;
> 
> This ...
> 
> >  }
> > +#else
> > +static inline void mce_centaur_feature_init(struct cpuinfo_x86 *c) {
> > +} #endif
> >
> >  static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)  { diff
> > --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> > b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> > index d05be30..5b1b68f 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> > @@ -85,7 +85,8 @@ static int cmci_supported(int *banks)
> >  * initialization is vendor keyed and this
> >  * makes sure none of the backdoors are entered otherwise.
> >  */
> > -   if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
> > +   if ((boot_cpu_data.x86_vendor != X86_VENDOR_INTEL &&
> > +   boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR))
> > return 0;
> > if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6)
> > return 0;
> > @@ -506,10 +507,20 @@ static void intel_ppin_init(struct cpuinfo_x86
> > *c)
> >
> >  void mce_intel_feature_init(struct cpuinfo_x86 *c)  {
> > -   intel_init_thermal(c);
> > -   intel_init_cmci();
> > -   intel_init_lmce();
> > -   intel_ppin_init(c);
> > +
> > +   switch (c->x86_vendor) {
> > +   case X86_VENDOR_INTEL:
> > +   intel_init_thermal(c);
> > +   intel_init_cmci();
> > +   intel_init_lmce();
> > +   intel_ppin_init(c);
> > +   break;
> > +   case X86_VENDOR_CENTAUR:
> > +   intel_init_cmci();
> 
> ... and this I really don't like for the simple reason that if the Intel side 
> gets
> changed, it could potentially break Centaur. And we don't want that. And
> the vendor should be free to change their code without asking another
> vendor for permission even if the other vendor is almost copying the
> code...
> 
> Long story short, I think you should extract the facilities you're going to
> need into generic, library-like ones and call them from centaur-specific
> compilation units which get enabled when CPU_SUP_CENTAUR is enabled.
> 
> So that the code can still be shared but there's no dependency on other
> vendors and so that one vendor doesn't break the other one and
> vice-versa.
> 
> IMO.
> 
> Thx.
> 
OK. I will adjust code.
Thank you.
> --
> Regards/Gruss,
> Boris.
> 
> Good mailing practices for 400: avoid top-posting and trim the reply.



[PATCH v2] x86/mce: add CMCI support for Centaur CPUs

2018-06-03 Thread David Wang
New Centaur CPU support CMCI mechanism, which is compatible with INTEL CMCI.

Signed-off-by: David Wang 

Changes from v1 to v2:
*1, add vendor check for Centaur CPU in cmci_supported.
*2, Only call intel_init_cmci for Centaur CPU in mce_intel_feature_init 
function.
---
 arch/x86/Kconfig   | 12 
 arch/x86/kernel/cpu/mcheck/mce.c   |  6 ++
 arch/x86/kernel/cpu/mcheck/mce_intel.c | 21 -
 3 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dda87a3..1adff5f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1130,6 +1130,18 @@ config X86_MCE_AMD
   Additional support for AMD specific MCE features such as
   the DRAM Error Threshold.
 
+config X86_MCE_CENTAUR
+   def_bool y
+   prompt "CENTAUR MCE features"
+   depends on CPU_SUP_CENTAUR && X86_MCE_INTEL
+   help
+  Additional support for Centaur specific MCE features such as
+  MCE broadcasting and CMCI support.
+  New Centaur CPU support MCE broadcasting.
+  New Centaur CPU support CMCI which is fully compliant with Intel 
CMCI.
+
+  If unsure, say N here.
+
 config X86_ANCIENT_MCE
bool "Support for old Pentium 5 / WinChip machine checks"
depends on X86_32 && X86_MCE
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index cd76380..2ebafc7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct cpuinfo_x86 *c)
}
 }
 
+#ifdef CONFIG_X86_MCE_CENTAUR
 static void mce_centaur_feature_init(struct cpuinfo_x86 *c)
 {
struct mca_config *cfg = _cfg;
@@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct cpuinfo_x86 
*c)
if (cfg->monarch_timeout < 0)
cfg->monarch_timeout = USEC_PER_SEC;
}
+   mce_intel_feature_init(c);
+   mce_adjust_timer = cmci_intel_adjust_timer;
 }
+#else
+static inline void mce_centaur_feature_init(struct cpuinfo_x86 *c) { }
+#endif
 
 static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
 {
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c 
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index d05be30..5b1b68f 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -85,7 +85,8 @@ static int cmci_supported(int *banks)
 * initialization is vendor keyed and this
 * makes sure none of the backdoors are entered otherwise.
 */
-   if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+   if ((boot_cpu_data.x86_vendor != X86_VENDOR_INTEL &&
+   boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR))
return 0;
if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6)
return 0;
@@ -506,10 +507,20 @@ static void intel_ppin_init(struct cpuinfo_x86 *c)
 
 void mce_intel_feature_init(struct cpuinfo_x86 *c)
 {
-   intel_init_thermal(c);
-   intel_init_cmci();
-   intel_init_lmce();
-   intel_ppin_init(c);
+
+   switch (c->x86_vendor) {
+   case X86_VENDOR_INTEL:
+   intel_init_thermal(c);
+   intel_init_cmci();
+   intel_init_lmce();
+   intel_ppin_init(c);
+   break;
+   case X86_VENDOR_CENTAUR:
+   intel_init_cmci();
+   break;
+   default:
+   break;
+   }
 }
 
 void mce_intel_feature_clear(struct cpuinfo_x86 *c)
-- 
1.9.1



[PATCH v2] x86/mce: add CMCI support for Centaur CPUs

2018-06-03 Thread David Wang
New Centaur CPU support CMCI mechanism, which is compatible with INTEL CMCI.

Signed-off-by: David Wang 

Changes from v1 to v2:
*1, add vendor check for Centaur CPU in cmci_supported.
*2, Only call intel_init_cmci for Centaur CPU in mce_intel_feature_init 
function.
---
 arch/x86/Kconfig   | 12 
 arch/x86/kernel/cpu/mcheck/mce.c   |  6 ++
 arch/x86/kernel/cpu/mcheck/mce_intel.c | 21 -
 3 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dda87a3..1adff5f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1130,6 +1130,18 @@ config X86_MCE_AMD
   Additional support for AMD specific MCE features such as
   the DRAM Error Threshold.
 
+config X86_MCE_CENTAUR
+   def_bool y
+   prompt "CENTAUR MCE features"
+   depends on CPU_SUP_CENTAUR && X86_MCE_INTEL
+   help
+  Additional support for Centaur specific MCE features such as
+  MCE broadcasting and CMCI support.
+  New Centaur CPU support MCE broadcasting.
+  New Centaur CPU support CMCI which is fully compliant with Intel 
CMCI.
+
+  If unsure, say N here.
+
 config X86_ANCIENT_MCE
bool "Support for old Pentium 5 / WinChip machine checks"
depends on X86_32 && X86_MCE
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index cd76380..2ebafc7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct cpuinfo_x86 *c)
}
 }
 
+#ifdef CONFIG_X86_MCE_CENTAUR
 static void mce_centaur_feature_init(struct cpuinfo_x86 *c)
 {
struct mca_config *cfg = _cfg;
@@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct cpuinfo_x86 
*c)
if (cfg->monarch_timeout < 0)
cfg->monarch_timeout = USEC_PER_SEC;
}
+   mce_intel_feature_init(c);
+   mce_adjust_timer = cmci_intel_adjust_timer;
 }
+#else
+static inline void mce_centaur_feature_init(struct cpuinfo_x86 *c) { }
+#endif
 
 static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
 {
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c 
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index d05be30..5b1b68f 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -85,7 +85,8 @@ static int cmci_supported(int *banks)
 * initialization is vendor keyed and this
 * makes sure none of the backdoors are entered otherwise.
 */
-   if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+   if ((boot_cpu_data.x86_vendor != X86_VENDOR_INTEL &&
+   boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR))
return 0;
if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6)
return 0;
@@ -506,10 +507,20 @@ static void intel_ppin_init(struct cpuinfo_x86 *c)
 
 void mce_intel_feature_init(struct cpuinfo_x86 *c)
 {
-   intel_init_thermal(c);
-   intel_init_cmci();
-   intel_init_lmce();
-   intel_ppin_init(c);
+
+   switch (c->x86_vendor) {
+   case X86_VENDOR_INTEL:
+   intel_init_thermal(c);
+   intel_init_cmci();
+   intel_init_lmce();
+   intel_ppin_init(c);
+   break;
+   case X86_VENDOR_CENTAUR:
+   intel_init_cmci();
+   break;
+   default:
+   break;
+   }
 }
 
 void mce_intel_feature_clear(struct cpuinfo_x86 *c)
-- 
1.9.1



Re: [PATCH] x86/mce: add CMCI support for Centaur CPUs

2018-06-03 Thread David Wang
> -Original Mail-
> Sender: Borislav Petkov [mailto:b...@alien8.de]
> Time: 2018年6月1日 17:38
> Receiver: David Wang 
> CC: tony.l...@intel.com; mi...@redhat.com; t...@linutronix.de;
> h...@zytor.com; gre...@linuxfoudation.org; x...@kernel.org;
> linux-kernel@vger.kernel.org; linux-e...@vger.kernel.org;
> brucech...@via-alliance.com; cooper...@zhaoxin.com;
> qiyuanw...@zhaoxin.com; benjamin...@viatech.com; luke...@viacpu.com;
> tim...@zhaoxin.com
> Topic : Re: [PATCH] x86/mce: add CMCI support for Centaur CPUs
> 
> On Thu, May 31, 2018 at 11:28:58AM +0800, David Wang wrote:
> > Newer Centaur support CMCI mechanism, which is compatible with INTEL
> CMCI.
> >
> > Signed-off-by: David Wang 
> > ---
> >  arch/x86/Kconfig | 12 
> >  arch/x86/kernel/cpu/mcheck/mce.c |  6 ++
> >  2 files changed, 18 insertions(+)
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index
> > dda87a3..1adff5f 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -1130,6 +1130,18 @@ config X86_MCE_AMD
> >Additional support for AMD specific MCE features such as
> >the DRAM Error Threshold.
> >
> > +config X86_MCE_CENTAUR
> > +   def_bool y
> > +   prompt "CENTAUR MCE features"
> > +   depends on CPU_SUP_CENTAUR && X86_MCE_INTEL
> > +   help
> > +  Additional support for Centaur specific MCE features such as
> > +  MCE broadcasting and CMCI support.
> > +  New Centaur CPU support MCE broadcasting.
> > +  New Centaur CPU support CMCI which is fully compliant with Intel
> CMCI.
> > +
> > +  If unsure, say N here.
> > +
> >  config X86_ANCIENT_MCE
> > bool "Support for old Pentium 5 / WinChip machine checks"
> > depends on X86_32 && X86_MCE
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> > b/arch/x86/kernel/cpu/mcheck/mce.c
> > index cd76380..2ebafc7 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> > @@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct
> cpuinfo_x86 *c)
> > }
> >  }
> >
> > +#ifdef CONFIG_X86_MCE_CENTAUR
> >  static void mce_centaur_feature_init(struct cpuinfo_x86 *c)  {
> > struct mca_config *cfg = _cfg;
> > @@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct
> cpuinfo_x86 *c)
> > if (cfg->monarch_timeout < 0)
> > cfg->monarch_timeout = USEC_PER_SEC;
> > }
> > +   mce_intel_feature_init(c);
> > +   mce_adjust_timer = cmci_intel_adjust_timer;
> 
> So far so good but above says "New Centaur CPU[s]" but you're calling
> mce_intel_feature_init() unconditionally here, for *all* centaur CPUs.
> Ditto for setting the CMCI handler.

There is a check for CMCI support or not In cmci_supported() function 
which will be called by mce_intel_feature_init.

return !!(cap & MCG_CMCI_P);
So, I didn't add Family/Model/Stepping check.

But, I am sorry to add another patch just as following:

@@ -85,7 +85,8 @@ static int cmci_supported(int *banks)
 * initialization is vendor keyed and this
 * makes sure none of the backdoors are entered otherwise.
 */
-   if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+   if ((boot_cpu_data.x86_vendor != X86_VENDOR_INTEL &&
+   boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR))
return 0;
if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6)
return 0;

I will send patch v4 later to include this patch.
Thank you.
> 
> Also mce_intel_feature_init() does more things than init CMCI so I think you
> wanna limit that to only intel_init_cmci(). IOW, something like the hunk 
> below.
> 
> And frankly I'm not crazy about adding centaur code to mce_intel.c but since 
> it
> is copying functionality, I think we should copy the sw support in the kernel 
> too
> instead of adding a mce_centaur.c duplicate. For now at least...
> 
> Thx.
> 
> ---
> diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> index d05be307d081..77d8a9b996a6 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> @@ -506,8 +506,15 @@ static void intel_ppin_init(struct cpuinfo_x86 *c)
> 
>  void mce_intel_feature_init(struct cpuinfo_x86 *c)  {
> - intel_init_thermal(c);
>   intel_init_cmci();
> +
> + /*
> +  * Some Centaur variants support CMCI.
> +  */
>

Re: [PATCH] x86/mce: add CMCI support for Centaur CPUs

2018-06-03 Thread David Wang
> -Original Mail-
> Sender: Borislav Petkov [mailto:b...@alien8.de]
> Time: 2018年6月1日 17:38
> Receiver: David Wang 
> CC: tony.l...@intel.com; mi...@redhat.com; t...@linutronix.de;
> h...@zytor.com; gre...@linuxfoudation.org; x...@kernel.org;
> linux-kernel@vger.kernel.org; linux-e...@vger.kernel.org;
> brucech...@via-alliance.com; cooper...@zhaoxin.com;
> qiyuanw...@zhaoxin.com; benjamin...@viatech.com; luke...@viacpu.com;
> tim...@zhaoxin.com
> Topic : Re: [PATCH] x86/mce: add CMCI support for Centaur CPUs
> 
> On Thu, May 31, 2018 at 11:28:58AM +0800, David Wang wrote:
> > Newer Centaur support CMCI mechanism, which is compatible with INTEL
> CMCI.
> >
> > Signed-off-by: David Wang 
> > ---
> >  arch/x86/Kconfig | 12 
> >  arch/x86/kernel/cpu/mcheck/mce.c |  6 ++
> >  2 files changed, 18 insertions(+)
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index
> > dda87a3..1adff5f 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -1130,6 +1130,18 @@ config X86_MCE_AMD
> >Additional support for AMD specific MCE features such as
> >the DRAM Error Threshold.
> >
> > +config X86_MCE_CENTAUR
> > +   def_bool y
> > +   prompt "CENTAUR MCE features"
> > +   depends on CPU_SUP_CENTAUR && X86_MCE_INTEL
> > +   help
> > +  Additional support for Centaur specific MCE features such as
> > +  MCE broadcasting and CMCI support.
> > +  New Centaur CPU support MCE broadcasting.
> > +  New Centaur CPU support CMCI which is fully compliant with Intel
> CMCI.
> > +
> > +  If unsure, say N here.
> > +
> >  config X86_ANCIENT_MCE
> > bool "Support for old Pentium 5 / WinChip machine checks"
> > depends on X86_32 && X86_MCE
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> > b/arch/x86/kernel/cpu/mcheck/mce.c
> > index cd76380..2ebafc7 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> > @@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct
> cpuinfo_x86 *c)
> > }
> >  }
> >
> > +#ifdef CONFIG_X86_MCE_CENTAUR
> >  static void mce_centaur_feature_init(struct cpuinfo_x86 *c)  {
> > struct mca_config *cfg = _cfg;
> > @@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct
> cpuinfo_x86 *c)
> > if (cfg->monarch_timeout < 0)
> > cfg->monarch_timeout = USEC_PER_SEC;
> > }
> > +   mce_intel_feature_init(c);
> > +   mce_adjust_timer = cmci_intel_adjust_timer;
> 
> So far so good but above says "New Centaur CPU[s]" but you're calling
> mce_intel_feature_init() unconditionally here, for *all* centaur CPUs.
> Ditto for setting the CMCI handler.

There is a check for CMCI support or not In cmci_supported() function 
which will be called by mce_intel_feature_init.

return !!(cap & MCG_CMCI_P);
So, I didn't add Family/Model/Stepping check.

But, I am sorry to add another patch just as following:

@@ -85,7 +85,8 @@ static int cmci_supported(int *banks)
 * initialization is vendor keyed and this
 * makes sure none of the backdoors are entered otherwise.
 */
-   if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+   if ((boot_cpu_data.x86_vendor != X86_VENDOR_INTEL &&
+   boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR))
return 0;
if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6)
return 0;

I will send patch v4 later to include this patch.
Thank you.
> 
> Also mce_intel_feature_init() does more things than init CMCI so I think you
> wanna limit that to only intel_init_cmci(). IOW, something like the hunk 
> below.
> 
> And frankly I'm not crazy about adding centaur code to mce_intel.c but since 
> it
> is copying functionality, I think we should copy the sw support in the kernel 
> too
> instead of adding a mce_centaur.c duplicate. For now at least...
> 
> Thx.
> 
> ---
> diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> index d05be307d081..77d8a9b996a6 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> @@ -506,8 +506,15 @@ static void intel_ppin_init(struct cpuinfo_x86 *c)
> 
>  void mce_intel_feature_init(struct cpuinfo_x86 *c)  {
> - intel_init_thermal(c);
>   intel_init_cmci();
> +
> + /*
> +  * Some Centaur variants support CMCI.
> +  */
>

[PATCH] x86/mce: add CMCI support for Centaur CPUs

2018-05-30 Thread David Wang
Newer Centaur support CMCI mechanism, which is compatible with INTEL CMCI.

Signed-off-by: David Wang 
---
 arch/x86/Kconfig | 12 
 arch/x86/kernel/cpu/mcheck/mce.c |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dda87a3..1adff5f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1130,6 +1130,18 @@ config X86_MCE_AMD
   Additional support for AMD specific MCE features such as
   the DRAM Error Threshold.
 
+config X86_MCE_CENTAUR
+   def_bool y
+   prompt "CENTAUR MCE features"
+   depends on CPU_SUP_CENTAUR && X86_MCE_INTEL
+   help
+  Additional support for Centaur specific MCE features such as
+  MCE broadcasting and CMCI support.
+  New Centaur CPU support MCE broadcasting.
+  New Centaur CPU support CMCI which is fully compliant with Intel 
CMCI.
+
+  If unsure, say N here.
+
 config X86_ANCIENT_MCE
bool "Support for old Pentium 5 / WinChip machine checks"
depends on X86_32 && X86_MCE
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index cd76380..2ebafc7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct cpuinfo_x86 *c)
}
 }
 
+#ifdef CONFIG_X86_MCE_CENTAUR
 static void mce_centaur_feature_init(struct cpuinfo_x86 *c)
 {
struct mca_config *cfg = _cfg;
@@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct cpuinfo_x86 
*c)
if (cfg->monarch_timeout < 0)
cfg->monarch_timeout = USEC_PER_SEC;
}
+   mce_intel_feature_init(c);
+   mce_adjust_timer = cmci_intel_adjust_timer;
 }
+#else
+static inline void mce_centaur_feature_init(struct cpuinfo_x86 *c) { }
+#endif
 
 static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
 {
-- 
1.9.1



[PATCH] x86/mce: add CMCI support for Centaur CPUs

2018-05-30 Thread David Wang
Newer Centaur support CMCI mechanism, which is compatible with INTEL CMCI.

Signed-off-by: David Wang 
---
 arch/x86/Kconfig | 12 
 arch/x86/kernel/cpu/mcheck/mce.c |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dda87a3..1adff5f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1130,6 +1130,18 @@ config X86_MCE_AMD
   Additional support for AMD specific MCE features such as
   the DRAM Error Threshold.
 
+config X86_MCE_CENTAUR
+   def_bool y
+   prompt "CENTAUR MCE features"
+   depends on CPU_SUP_CENTAUR && X86_MCE_INTEL
+   help
+  Additional support for Centaur specific MCE features such as
+  MCE broadcasting and CMCI support.
+  New Centaur CPU support MCE broadcasting.
+  New Centaur CPU support CMCI which is fully compliant with Intel 
CMCI.
+
+  If unsure, say N here.
+
 config X86_ANCIENT_MCE
bool "Support for old Pentium 5 / WinChip machine checks"
depends on X86_32 && X86_MCE
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index cd76380..2ebafc7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct cpuinfo_x86 *c)
}
 }
 
+#ifdef CONFIG_X86_MCE_CENTAUR
 static void mce_centaur_feature_init(struct cpuinfo_x86 *c)
 {
struct mca_config *cfg = _cfg;
@@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct cpuinfo_x86 
*c)
if (cfg->monarch_timeout < 0)
cfg->monarch_timeout = USEC_PER_SEC;
}
+   mce_intel_feature_init(c);
+   mce_adjust_timer = cmci_intel_adjust_timer;
 }
+#else
+static inline void mce_centaur_feature_init(struct cpuinfo_x86 *c) { }
+#endif
 
 static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
 {
-- 
1.9.1



[PATCH v3] Optimize C3 entry on Centaur CPUs

2018-05-29 Thread David Wang
For new Centaur CPUs the ucode will take care of the preservation of cache 
coherence
between CPU cores in C-states regardless of how deep the C-states are. So, it 
is not
necessary to flush the caches in software befor entering C3.

Signed-off-by: David Wang 

Changes from v2 to v3:
*1, Replace "c->x86_mask" with "c->x86_stepping".

Changes from v1 to v2:
* 1, Add some Family/Model/Stepping contrains to let this patch only apply
* to new centaur CPUs.
* 2, The arbiter disable/enable operations maybe needed for old VIA/Centaur
* platform. So, delete "flags->bm_control=0" in patch v1.

---
 arch/x86/kernel/acpi/cstate.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
index dde437f..a82fed6 100644
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -51,6 +51,19 @@ void acpi_processor_power_init_bm_check(struct 
acpi_processor_flags *flags,
if (c->x86_vendor == X86_VENDOR_INTEL &&
(c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
flags->bm_control = 0;
+
+   /*
+* For all recent Centaur CPUs, the ucode will make sure that each
+* core can keep cache coherence with each other while entering C3
+* type state. So, set bm_check to 1 to indicate that the kernel
+* need not execute a cache flush operation (WBINVD) when entering
+* C3 type state.
+*/
+   if (c->x86_vendor == X86_VENDOR_CENTAUR) {
+   if (c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0x0f &&
+   c->x86_stepping >= 0x0e))
+   flags->bm_check = 1;
+   }
 }
 EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
 
-- 
1.9.1



[PATCH v3] Optimize C3 entry on Centaur CPUs

2018-05-29 Thread David Wang
For new Centaur CPUs the ucode will take care of the preservation of cache 
coherence
between CPU cores in C-states regardless of how deep the C-states are. So, it 
is not
necessary to flush the caches in software befor entering C3.

Signed-off-by: David Wang 

Changes from v2 to v3:
*1, Replace "c->x86_mask" with "c->x86_stepping".

Changes from v1 to v2:
* 1, Add some Family/Model/Stepping contrains to let this patch only apply
* to new centaur CPUs.
* 2, The arbiter disable/enable operations maybe needed for old VIA/Centaur
* platform. So, delete "flags->bm_control=0" in patch v1.

---
 arch/x86/kernel/acpi/cstate.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
index dde437f..a82fed6 100644
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -51,6 +51,19 @@ void acpi_processor_power_init_bm_check(struct 
acpi_processor_flags *flags,
if (c->x86_vendor == X86_VENDOR_INTEL &&
(c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
flags->bm_control = 0;
+
+   /*
+* For all recent Centaur CPUs, the ucode will make sure that each
+* core can keep cache coherence with each other while entering C3
+* type state. So, set bm_check to 1 to indicate that the kernel
+* need not execute a cache flush operation (WBINVD) when entering
+* C3 type state.
+*/
+   if (c->x86_vendor == X86_VENDOR_CENTAUR) {
+   if (c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0x0f &&
+   c->x86_stepping >= 0x0e))
+   flags->bm_check = 1;
+   }
 }
 EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
 
-- 
1.9.1



[tip:x86/cpu] x86/CPU: Move cpu_detect_cache_sizes() into init_intel_cacheinfo()

2018-05-13 Thread tip-bot for David Wang
Commit-ID:  807e9bc8e2fe6b4907f9f77fd073f7ef5073af29
Gitweb: https://git.kernel.org/tip/807e9bc8e2fe6b4907f9f77fd073f7ef5073af29
Author: David Wang <davidw...@zhaoxin.com>
AuthorDate: Thu, 3 May 2018 10:32:45 +0800
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: Sun, 13 May 2018 16:14:24 +0200

x86/CPU: Move cpu_detect_cache_sizes() into init_intel_cacheinfo()

There is no point in having the conditional cpu_detect_cache_sizes() call
at the callsite of init_intel_cacheinfo().

Move it into init_intel_cacheinfo() and make init_intel_cacheinfo() void.

[ tglx: Made the init_intel_cacheinfo() void as the return value was
pointless. Adjust changelog accordingly ]

Signed-off-by: David Wang <davidw...@zhaoxin.com>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: gre...@linuxfoundation.org
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: h...@zytor.com
Cc: benjamin...@viatech.com
Link: 
https://lkml.kernel.org/r/1525314766-18910-3-git-send-email-davidw...@zhaoxin.com


---
 arch/x86/kernel/cpu/cacheinfo.c |  5 +++--
 arch/x86/kernel/cpu/cpu.h   |  2 +-
 arch/x86/kernel/cpu/intel.c | 14 --
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 58d472c84ba2..38354c66df81 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -691,7 +691,7 @@ void init_amd_cacheinfo(struct cpuinfo_x86 *c)
}
 }
 
-unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c)
+void init_intel_cacheinfo(struct cpuinfo_x86 *c)
 {
/* Cache sizes */
unsigned int trace = 0, l1i = 0, l1d = 0, l2 = 0, l3 = 0;
@@ -843,7 +843,8 @@ unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c)
 
c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i+l1d));
 
-   return l2;
+   if (!l2)
+   cpu_detect_cache_sizes(c);
 }
 
 static int __cache_amd_cpumap_setup(unsigned int cpu, int index,
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index efd6ef8ad14e..49bf8a080105 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -51,7 +51,7 @@ extern void init_scattered_cpuid_features(struct cpuinfo_x86 
*c);
 extern u32 get_scattered_cpuid_leaf(unsigned int level,
unsigned int sub_leaf,
enum cpuid_regs_idx reg);
-extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
+extern void init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
 
 extern int detect_num_cpu_cores(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index b54535be254a..ca141d159be1 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -635,8 +635,6 @@ static void init_intel_misc_features(struct cpuinfo_x86 *c)
 
 static void init_intel(struct cpuinfo_x86 *c)
 {
-   unsigned int l2 = 0;
-
early_init_intel(c);
 
intel_workarounds(c);
@@ -659,13 +657,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 #endif
}
 
-   l2 = init_intel_cacheinfo(c);
-
-   /* Detect legacy cache sizes if init_intel_cacheinfo did not */
-   if (l2 == 0) {
-   cpu_detect_cache_sizes(c);
-   l2 = c->x86_cache_size;
-   }
+   init_intel_cacheinfo(c);
 
if (c->cpuid_level > 9) {
unsigned eax = cpuid_eax(10);
@@ -678,7 +670,8 @@ static void init_intel(struct cpuinfo_x86 *c)
set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
 
if (boot_cpu_has(X86_FEATURE_DS)) {
-   unsigned int l1;
+   unsigned int l1, l2;
+
rdmsr(MSR_IA32_MISC_ENABLE, l1, l2);
if (!(l1 & (1<<11)))
set_cpu_cap(c, X86_FEATURE_BTS);
@@ -706,6 +699,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 * Dixon is NOT a Celeron.
 */
if (c->x86 == 6) {
+   unsigned int l2 = c->x86_cache_size;
char *p = NULL;
 
switch (c->x86_model) {


[tip:x86/cpu] x86/Centaur: Report correct CPU/cache topology

2018-05-13 Thread tip-bot for David Wang
Commit-ID:  a2aa578fec8c29436bce5e6c15e1e31729d539a3
Gitweb: https://git.kernel.org/tip/a2aa578fec8c29436bce5e6c15e1e31729d539a3
Author: David Wang <davidw...@zhaoxin.com>
AuthorDate: Thu, 3 May 2018 10:32:46 +0800
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: Sun, 13 May 2018 16:14:24 +0200

x86/Centaur: Report correct CPU/cache topology

Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
but the function is unused so for. The Centaur init code also misses to
initialize x86_info::max_cores, so the CPU topology can't be described
correctly.

Initialize x86_info::max_cores and invoke init_cacheinfo() to make
CPU and cache topology information available and correct.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: gre...@linuxfoundation.org
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: h...@zytor.com
Cc: benjamin...@viatech.com
Link: 
https://lkml.kernel.org/r/1525314766-18910-4-git-send-email-davidw...@zhaoxin.com


---
 arch/x86/kernel/cpu/centaur.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 80d5110481ec..c265494234e6 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -160,6 +160,11 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+   init_intel_cacheinfo(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
+#ifdef CONFIG_X86_32
+   detect_ht(c);
+#endif
 
if (c->cpuid_level > 9) {
unsigned int eax = cpuid_eax(10);


[tip:x86/cpu] x86/CPU: Move cpu_detect_cache_sizes() into init_intel_cacheinfo()

2018-05-13 Thread tip-bot for David Wang
Commit-ID:  807e9bc8e2fe6b4907f9f77fd073f7ef5073af29
Gitweb: https://git.kernel.org/tip/807e9bc8e2fe6b4907f9f77fd073f7ef5073af29
Author: David Wang 
AuthorDate: Thu, 3 May 2018 10:32:45 +0800
Committer:  Thomas Gleixner 
CommitDate: Sun, 13 May 2018 16:14:24 +0200

x86/CPU: Move cpu_detect_cache_sizes() into init_intel_cacheinfo()

There is no point in having the conditional cpu_detect_cache_sizes() call
at the callsite of init_intel_cacheinfo().

Move it into init_intel_cacheinfo() and make init_intel_cacheinfo() void.

[ tglx: Made the init_intel_cacheinfo() void as the return value was
pointless. Adjust changelog accordingly ]

Signed-off-by: David Wang 
Signed-off-by: Thomas Gleixner 
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: gre...@linuxfoundation.org
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: h...@zytor.com
Cc: benjamin...@viatech.com
Link: 
https://lkml.kernel.org/r/1525314766-18910-3-git-send-email-davidw...@zhaoxin.com


---
 arch/x86/kernel/cpu/cacheinfo.c |  5 +++--
 arch/x86/kernel/cpu/cpu.h   |  2 +-
 arch/x86/kernel/cpu/intel.c | 14 --
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 58d472c84ba2..38354c66df81 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -691,7 +691,7 @@ void init_amd_cacheinfo(struct cpuinfo_x86 *c)
}
 }
 
-unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c)
+void init_intel_cacheinfo(struct cpuinfo_x86 *c)
 {
/* Cache sizes */
unsigned int trace = 0, l1i = 0, l1d = 0, l2 = 0, l3 = 0;
@@ -843,7 +843,8 @@ unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c)
 
c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i+l1d));
 
-   return l2;
+   if (!l2)
+   cpu_detect_cache_sizes(c);
 }
 
 static int __cache_amd_cpumap_setup(unsigned int cpu, int index,
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index efd6ef8ad14e..49bf8a080105 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -51,7 +51,7 @@ extern void init_scattered_cpuid_features(struct cpuinfo_x86 
*c);
 extern u32 get_scattered_cpuid_leaf(unsigned int level,
unsigned int sub_leaf,
enum cpuid_regs_idx reg);
-extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
+extern void init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
 
 extern int detect_num_cpu_cores(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index b54535be254a..ca141d159be1 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -635,8 +635,6 @@ static void init_intel_misc_features(struct cpuinfo_x86 *c)
 
 static void init_intel(struct cpuinfo_x86 *c)
 {
-   unsigned int l2 = 0;
-
early_init_intel(c);
 
intel_workarounds(c);
@@ -659,13 +657,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 #endif
}
 
-   l2 = init_intel_cacheinfo(c);
-
-   /* Detect legacy cache sizes if init_intel_cacheinfo did not */
-   if (l2 == 0) {
-   cpu_detect_cache_sizes(c);
-   l2 = c->x86_cache_size;
-   }
+   init_intel_cacheinfo(c);
 
if (c->cpuid_level > 9) {
unsigned eax = cpuid_eax(10);
@@ -678,7 +670,8 @@ static void init_intel(struct cpuinfo_x86 *c)
set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
 
if (boot_cpu_has(X86_FEATURE_DS)) {
-   unsigned int l1;
+   unsigned int l1, l2;
+
rdmsr(MSR_IA32_MISC_ENABLE, l1, l2);
if (!(l1 & (1<<11)))
set_cpu_cap(c, X86_FEATURE_BTS);
@@ -706,6 +699,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 * Dixon is NOT a Celeron.
 */
if (c->x86 == 6) {
+   unsigned int l2 = c->x86_cache_size;
char *p = NULL;
 
switch (c->x86_model) {


[tip:x86/cpu] x86/Centaur: Report correct CPU/cache topology

2018-05-13 Thread tip-bot for David Wang
Commit-ID:  a2aa578fec8c29436bce5e6c15e1e31729d539a3
Gitweb: https://git.kernel.org/tip/a2aa578fec8c29436bce5e6c15e1e31729d539a3
Author: David Wang 
AuthorDate: Thu, 3 May 2018 10:32:46 +0800
Committer:  Thomas Gleixner 
CommitDate: Sun, 13 May 2018 16:14:24 +0200

x86/Centaur: Report correct CPU/cache topology

Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
but the function is unused so for. The Centaur init code also misses to
initialize x86_info::max_cores, so the CPU topology can't be described
correctly.

Initialize x86_info::max_cores and invoke init_cacheinfo() to make
CPU and cache topology information available and correct.

Signed-off-by: David Wang 
Signed-off-by: Thomas Gleixner 
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: gre...@linuxfoundation.org
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: h...@zytor.com
Cc: benjamin...@viatech.com
Link: 
https://lkml.kernel.org/r/1525314766-18910-4-git-send-email-davidw...@zhaoxin.com


---
 arch/x86/kernel/cpu/centaur.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 80d5110481ec..c265494234e6 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -160,6 +160,11 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+   init_intel_cacheinfo(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
+#ifdef CONFIG_X86_32
+   detect_ht(c);
+#endif
 
if (c->cpuid_level > 9) {
unsigned int eax = cpuid_eax(10);


[tip:x86/cpu] x86/CPU: Move cpu_detect_cache_sizes() into init_intel_cacheinfo()

2018-05-13 Thread tip-bot for David Wang
Commit-ID:  606e20959ef49f22cddb611f2cefef8e6501e3dd
Gitweb: https://git.kernel.org/tip/606e20959ef49f22cddb611f2cefef8e6501e3dd
Author: David Wang <davidw...@zhaoxin.com>
AuthorDate: Thu, 3 May 2018 10:32:45 +0800
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: Sun, 13 May 2018 12:06:12 +0200

x86/CPU: Move cpu_detect_cache_sizes() into init_intel_cacheinfo()

There is no point in having the conditional cpu_detect_cache_sizes() call
at the callsite of init_intel_cacheinfo().

Move it into init_intel_cacheinfo() and make init_intel_cacheinfo() void.

[ tglx: Made the init_intel_cacheinfo() void as the return value was
pointless. Adjust changelog accordingly ]

Signed-off-by: David Wang <davidw...@zhaoxin.com>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: gre...@linuxfoundation.org
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: h...@zytor.com
Cc: benjamin...@viatech.com
Link: 
https://lkml.kernel.org/r/1525314766-18910-3-git-send-email-davidw...@zhaoxin.com

---
 arch/x86/kernel/cpu/cacheinfo.c |  5 +++--
 arch/x86/kernel/cpu/cpu.h   |  2 +-
 arch/x86/kernel/cpu/intel.c | 13 +++--
 3 files changed, 7 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 58d472c84ba2..38354c66df81 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -691,7 +691,7 @@ void init_amd_cacheinfo(struct cpuinfo_x86 *c)
}
 }
 
-unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c)
+void init_intel_cacheinfo(struct cpuinfo_x86 *c)
 {
/* Cache sizes */
unsigned int trace = 0, l1i = 0, l1d = 0, l2 = 0, l3 = 0;
@@ -843,7 +843,8 @@ unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c)
 
c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i+l1d));
 
-   return l2;
+   if (!l2)
+   cpu_detect_cache_sizes(c);
 }
 
 static int __cache_amd_cpumap_setup(unsigned int cpu, int index,
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index efd6ef8ad14e..49bf8a080105 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -51,7 +51,7 @@ extern void init_scattered_cpuid_features(struct cpuinfo_x86 
*c);
 extern u32 get_scattered_cpuid_leaf(unsigned int level,
unsigned int sub_leaf,
enum cpuid_regs_idx reg);
-extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
+extern void init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
 
 extern int detect_num_cpu_cores(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index b54535be254a..615870420be2 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -635,8 +635,6 @@ static void init_intel_misc_features(struct cpuinfo_x86 *c)
 
 static void init_intel(struct cpuinfo_x86 *c)
 {
-   unsigned int l2 = 0;
-
early_init_intel(c);
 
intel_workarounds(c);
@@ -659,13 +657,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 #endif
}
 
-   l2 = init_intel_cacheinfo(c);
-
-   /* Detect legacy cache sizes if init_intel_cacheinfo did not */
-   if (l2 == 0) {
-   cpu_detect_cache_sizes(c);
-   l2 = c->x86_cache_size;
-   }
+   init_intel_cacheinfo(c);
 
if (c->cpuid_level > 9) {
unsigned eax = cpuid_eax(10);
@@ -678,7 +670,8 @@ static void init_intel(struct cpuinfo_x86 *c)
set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
 
if (boot_cpu_has(X86_FEATURE_DS)) {
-   unsigned int l1;
+   unsigned int l1, l2;
+
rdmsr(MSR_IA32_MISC_ENABLE, l1, l2);
if (!(l1 & (1<<11)))
set_cpu_cap(c, X86_FEATURE_BTS);


[tip:x86/cpu] x86/CPU: Move cpu_detect_cache_sizes() into init_intel_cacheinfo()

2018-05-13 Thread tip-bot for David Wang
Commit-ID:  606e20959ef49f22cddb611f2cefef8e6501e3dd
Gitweb: https://git.kernel.org/tip/606e20959ef49f22cddb611f2cefef8e6501e3dd
Author: David Wang 
AuthorDate: Thu, 3 May 2018 10:32:45 +0800
Committer:  Thomas Gleixner 
CommitDate: Sun, 13 May 2018 12:06:12 +0200

x86/CPU: Move cpu_detect_cache_sizes() into init_intel_cacheinfo()

There is no point in having the conditional cpu_detect_cache_sizes() call
at the callsite of init_intel_cacheinfo().

Move it into init_intel_cacheinfo() and make init_intel_cacheinfo() void.

[ tglx: Made the init_intel_cacheinfo() void as the return value was
pointless. Adjust changelog accordingly ]

Signed-off-by: David Wang 
Signed-off-by: Thomas Gleixner 
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: gre...@linuxfoundation.org
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: h...@zytor.com
Cc: benjamin...@viatech.com
Link: 
https://lkml.kernel.org/r/1525314766-18910-3-git-send-email-davidw...@zhaoxin.com

---
 arch/x86/kernel/cpu/cacheinfo.c |  5 +++--
 arch/x86/kernel/cpu/cpu.h   |  2 +-
 arch/x86/kernel/cpu/intel.c | 13 +++--
 3 files changed, 7 insertions(+), 13 deletions(-)

diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 58d472c84ba2..38354c66df81 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -691,7 +691,7 @@ void init_amd_cacheinfo(struct cpuinfo_x86 *c)
}
 }
 
-unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c)
+void init_intel_cacheinfo(struct cpuinfo_x86 *c)
 {
/* Cache sizes */
unsigned int trace = 0, l1i = 0, l1d = 0, l2 = 0, l3 = 0;
@@ -843,7 +843,8 @@ unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c)
 
c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i+l1d));
 
-   return l2;
+   if (!l2)
+   cpu_detect_cache_sizes(c);
 }
 
 static int __cache_amd_cpumap_setup(unsigned int cpu, int index,
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index efd6ef8ad14e..49bf8a080105 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -51,7 +51,7 @@ extern void init_scattered_cpuid_features(struct cpuinfo_x86 
*c);
 extern u32 get_scattered_cpuid_leaf(unsigned int level,
unsigned int sub_leaf,
enum cpuid_regs_idx reg);
-extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
+extern void init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
 
 extern int detect_num_cpu_cores(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index b54535be254a..615870420be2 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -635,8 +635,6 @@ static void init_intel_misc_features(struct cpuinfo_x86 *c)
 
 static void init_intel(struct cpuinfo_x86 *c)
 {
-   unsigned int l2 = 0;
-
early_init_intel(c);
 
intel_workarounds(c);
@@ -659,13 +657,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 #endif
}
 
-   l2 = init_intel_cacheinfo(c);
-
-   /* Detect legacy cache sizes if init_intel_cacheinfo did not */
-   if (l2 == 0) {
-   cpu_detect_cache_sizes(c);
-   l2 = c->x86_cache_size;
-   }
+   init_intel_cacheinfo(c);
 
if (c->cpuid_level > 9) {
unsigned eax = cpuid_eax(10);
@@ -678,7 +670,8 @@ static void init_intel(struct cpuinfo_x86 *c)
set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
 
if (boot_cpu_has(X86_FEATURE_DS)) {
-   unsigned int l1;
+   unsigned int l1, l2;
+
rdmsr(MSR_IA32_MISC_ENABLE, l1, l2);
if (!(l1 & (1<<11)))
set_cpu_cap(c, X86_FEATURE_BTS);


[tip:x86/cpu] x86/Centaur: Report correct CPU/cache topology

2018-05-13 Thread tip-bot for David Wang
Commit-ID:  5a19009043fcffd1591b04a588d53336a66855d5
Gitweb: https://git.kernel.org/tip/5a19009043fcffd1591b04a588d53336a66855d5
Author: David Wang <davidw...@zhaoxin.com>
AuthorDate: Thu, 3 May 2018 10:32:46 +0800
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: Sun, 13 May 2018 12:06:13 +0200

x86/Centaur: Report correct CPU/cache topology

Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
but the function is unused so for. The Centaur init code also misses to
initialize x86_info::max_cores, so the CPU topology can't be described
correctly.

Initialize x86_info::max_cores and invoke init_cacheinfo() to make
CPU and cache topology information available and correct.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: gre...@linuxfoundation.org
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: h...@zytor.com
Cc: benjamin...@viatech.com
Link: 
https://lkml.kernel.org/r/1525314766-18910-4-git-send-email-davidw...@zhaoxin.com

---
 arch/x86/kernel/cpu/centaur.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 80d5110481ec..c265494234e6 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -160,6 +160,11 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+   init_intel_cacheinfo(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
+#ifdef CONFIG_X86_32
+   detect_ht(c);
+#endif
 
if (c->cpuid_level > 9) {
unsigned int eax = cpuid_eax(10);


[tip:x86/cpu] x86/Centaur: Report correct CPU/cache topology

2018-05-13 Thread tip-bot for David Wang
Commit-ID:  5a19009043fcffd1591b04a588d53336a66855d5
Gitweb: https://git.kernel.org/tip/5a19009043fcffd1591b04a588d53336a66855d5
Author: David Wang 
AuthorDate: Thu, 3 May 2018 10:32:46 +0800
Committer:  Thomas Gleixner 
CommitDate: Sun, 13 May 2018 12:06:13 +0200

x86/Centaur: Report correct CPU/cache topology

Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
but the function is unused so for. The Centaur init code also misses to
initialize x86_info::max_cores, so the CPU topology can't be described
correctly.

Initialize x86_info::max_cores and invoke init_cacheinfo() to make
CPU and cache topology information available and correct.

Signed-off-by: David Wang 
Signed-off-by: Thomas Gleixner 
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: gre...@linuxfoundation.org
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: h...@zytor.com
Cc: benjamin...@viatech.com
Link: 
https://lkml.kernel.org/r/1525314766-18910-4-git-send-email-davidw...@zhaoxin.com

---
 arch/x86/kernel/cpu/centaur.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 80d5110481ec..c265494234e6 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -160,6 +160,11 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+   init_intel_cacheinfo(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
+#ifdef CONFIG_X86_32
+   detect_ht(c);
+#endif
 
if (c->cpuid_level > 9) {
unsigned int eax = cpuid_eax(10);


[tip:x86/cpu] x86/CPU: Make intel_num_cpu_cores() generic

2018-05-13 Thread tip-bot for David Wang
Commit-ID:  2cc61be60e37b1856a97ccbdcca3e86e593bf06a
Gitweb: https://git.kernel.org/tip/2cc61be60e37b1856a97ccbdcca3e86e593bf06a
Author: David Wang <davidw...@zhaoxin.com>
AuthorDate: Thu, 3 May 2018 10:32:44 +0800
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: Sun, 13 May 2018 12:06:12 +0200

x86/CPU: Make intel_num_cpu_cores() generic

intel_num_cpu_cores() is a static function in intel.c which can't be used
by other files. Define another function called detect_num_cpu_cores() in
common.c to replace this function so it can be reused.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: gre...@linuxfoundation.org
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: h...@zytor.com
Cc: benjamin...@viatech.com
Link: 
https://lkml.kernel.org/r/1525314766-18910-2-git-send-email-davidw...@zhaoxin.com

---
 arch/x86/kernel/cpu/common.c | 14 ++
 arch/x86/kernel/cpu/cpu.h|  1 +
 arch/x86/kernel/cpu/intel.c  | 20 +---
 3 files changed, 16 insertions(+), 19 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 37c7c8334a00..6993842e788c 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -584,6 +584,20 @@ static void get_model_name(struct cpuinfo_x86 *c)
*(s + 1) = '\0';
 }
 
+int detect_num_cpu_cores(struct cpuinfo_x86 *c)
+{
+   unsigned int eax, ebx, ecx, edx;
+
+   if (!IS_ENABLED(CONFIG_SMP) || c->cpuid_level < 4)
+   return 1;
+
+   cpuid_count(4, 0, , , , );
+   if (eax & 0x1f)
+   return (eax >> 26) + 1;
+   else
+   return 1;
+}
+
 void cpu_detect_cache_sizes(struct cpuinfo_x86 *c)
 {
unsigned int n, dummy, ebx, ecx, edx, l2size;
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index c415f99e9599..efd6ef8ad14e 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -54,6 +54,7 @@ extern u32 get_scattered_cpuid_leaf(unsigned int level,
 extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
 
+extern int detect_num_cpu_cores(struct cpuinfo_x86 *c);
 extern int detect_extended_topology(struct cpuinfo_x86 *c);
 extern void detect_ht(struct cpuinfo_x86 *c);
 
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index b9693b80fc21..b54535be254a 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -453,24 +453,6 @@ static void srat_detect_node(struct cpuinfo_x86 *c)
 #endif
 }
 
-/*
- * find out the number of processor cores on the die
- */
-static int intel_num_cpu_cores(struct cpuinfo_x86 *c)
-{
-   unsigned int eax, ebx, ecx, edx;
-
-   if (!IS_ENABLED(CONFIG_SMP) || c->cpuid_level < 4)
-   return 1;
-
-   /* Intel has a non-standard dependency on %ecx for this CPUID level. */
-   cpuid_count(4, 0, , , , );
-   if (eax & 0x1f)
-   return (eax >> 26) + 1;
-   else
-   return 1;
-}
-
 static void detect_vmx_virtcap(struct cpuinfo_x86 *c)
 {
/* Intel VMX MSR indicated features */
@@ -671,7 +653,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 * let's use the legacy cpuid vector 0x1 and 0x4 for topology
 * detection.
 */
-   c->x86_max_cores = intel_num_cpu_cores(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
 #ifdef CONFIG_X86_32
detect_ht(c);
 #endif


[tip:x86/cpu] x86/CPU: Make intel_num_cpu_cores() generic

2018-05-13 Thread tip-bot for David Wang
Commit-ID:  2cc61be60e37b1856a97ccbdcca3e86e593bf06a
Gitweb: https://git.kernel.org/tip/2cc61be60e37b1856a97ccbdcca3e86e593bf06a
Author: David Wang 
AuthorDate: Thu, 3 May 2018 10:32:44 +0800
Committer:  Thomas Gleixner 
CommitDate: Sun, 13 May 2018 12:06:12 +0200

x86/CPU: Make intel_num_cpu_cores() generic

intel_num_cpu_cores() is a static function in intel.c which can't be used
by other files. Define another function called detect_num_cpu_cores() in
common.c to replace this function so it can be reused.

Signed-off-by: David Wang 
Signed-off-by: Thomas Gleixner 
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: gre...@linuxfoundation.org
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: h...@zytor.com
Cc: benjamin...@viatech.com
Link: 
https://lkml.kernel.org/r/1525314766-18910-2-git-send-email-davidw...@zhaoxin.com

---
 arch/x86/kernel/cpu/common.c | 14 ++
 arch/x86/kernel/cpu/cpu.h|  1 +
 arch/x86/kernel/cpu/intel.c  | 20 +---
 3 files changed, 16 insertions(+), 19 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 37c7c8334a00..6993842e788c 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -584,6 +584,20 @@ static void get_model_name(struct cpuinfo_x86 *c)
*(s + 1) = '\0';
 }
 
+int detect_num_cpu_cores(struct cpuinfo_x86 *c)
+{
+   unsigned int eax, ebx, ecx, edx;
+
+   if (!IS_ENABLED(CONFIG_SMP) || c->cpuid_level < 4)
+   return 1;
+
+   cpuid_count(4, 0, , , , );
+   if (eax & 0x1f)
+   return (eax >> 26) + 1;
+   else
+   return 1;
+}
+
 void cpu_detect_cache_sizes(struct cpuinfo_x86 *c)
 {
unsigned int n, dummy, ebx, ecx, edx, l2size;
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index c415f99e9599..efd6ef8ad14e 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -54,6 +54,7 @@ extern u32 get_scattered_cpuid_leaf(unsigned int level,
 extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
 
+extern int detect_num_cpu_cores(struct cpuinfo_x86 *c);
 extern int detect_extended_topology(struct cpuinfo_x86 *c);
 extern void detect_ht(struct cpuinfo_x86 *c);
 
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index b9693b80fc21..b54535be254a 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -453,24 +453,6 @@ static void srat_detect_node(struct cpuinfo_x86 *c)
 #endif
 }
 
-/*
- * find out the number of processor cores on the die
- */
-static int intel_num_cpu_cores(struct cpuinfo_x86 *c)
-{
-   unsigned int eax, ebx, ecx, edx;
-
-   if (!IS_ENABLED(CONFIG_SMP) || c->cpuid_level < 4)
-   return 1;
-
-   /* Intel has a non-standard dependency on %ecx for this CPUID level. */
-   cpuid_count(4, 0, , , , );
-   if (eax & 0x1f)
-   return (eax >> 26) + 1;
-   else
-   return 1;
-}
-
 static void detect_vmx_virtcap(struct cpuinfo_x86 *c)
 {
/* Intel VMX MSR indicated features */
@@ -671,7 +653,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 * let's use the legacy cpuid vector 0x1 and 0x4 for topology
 * detection.
 */
-   c->x86_max_cores = intel_num_cpu_cores(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
 #ifdef CONFIG_X86_32
detect_ht(c);
 #endif


[tip:ras/core] x86/MCE: Enable MCE broadcasting on new Centaur CPUs

2018-05-06 Thread tip-bot for David Wang
Commit-ID:  13e8582245267b872dc6eb4ab695fffc797d99f5
Gitweb: https://git.kernel.org/tip/13e8582245267b872dc6eb4ab695fffc797d99f5
Author: David Wang <davidw...@zhaoxin.com>
AuthorDate: Wed, 25 Apr 2018 18:33:39 +0800
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: Sun, 6 May 2018 12:46:25 +0200

x86/MCE: Enable MCE broadcasting on new Centaur CPUs

Newer Centaur multi-core CPUs also support MCE broadcasting to all
cores. Add a Centaur-specific init function setting that up.

 [ bp:
   - make mce_centaur_feature_init() static
   - flip check to do the f/m/s first for better readability
   - touch up text
  ]

Signed-off-by: David Wang <davidw...@zhaoxin.com>
Signed-off-by: Borislav Petkov <b...@suse.de>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: Greg KH <g...@kroah.com>
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: Tony Luck <tony.l...@intel.com>
Cc: benjamin...@viatech.com
Cc: linux-edac <linux-e...@vger.kernel.org>
Link: 
http://lkml.kernel.org/r/1524652420-17330-2-git-send-email-davidw...@zhaoxin.com

---
 arch/x86/kernel/cpu/mcheck/mce.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 42cf2880d0ed..cd76380af79f 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1727,6 +1727,21 @@ static void __mcheck_cpu_init_early(struct cpuinfo_x86 
*c)
}
 }
 
+static void mce_centaur_feature_init(struct cpuinfo_x86 *c)
+{
+   struct mca_config *cfg = _cfg;
+
+/*
+ * All newer Centaur CPUs support MCE broadcasting. Enable
+ * synchronization with a one second timeout.
+ */
+   if ((c->x86 == 6 && c->x86_model == 0xf && c->x86_stepping >= 0xe) ||
+c->x86 > 6) {
+   if (cfg->monarch_timeout < 0)
+   cfg->monarch_timeout = USEC_PER_SEC;
+   }
+}
+
 static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
 {
switch (c->x86_vendor) {
@@ -1739,6 +1754,9 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
mce_amd_feature_init(c);
break;
}
+   case X86_VENDOR_CENTAUR:
+   mce_centaur_feature_init(c);
+   break;
 
default:
break;


[tip:ras/core] x86/MCE: Enable MCE broadcasting on new Centaur CPUs

2018-05-06 Thread tip-bot for David Wang
Commit-ID:  13e8582245267b872dc6eb4ab695fffc797d99f5
Gitweb: https://git.kernel.org/tip/13e8582245267b872dc6eb4ab695fffc797d99f5
Author: David Wang 
AuthorDate: Wed, 25 Apr 2018 18:33:39 +0800
Committer:  Thomas Gleixner 
CommitDate: Sun, 6 May 2018 12:46:25 +0200

x86/MCE: Enable MCE broadcasting on new Centaur CPUs

Newer Centaur multi-core CPUs also support MCE broadcasting to all
cores. Add a Centaur-specific init function setting that up.

 [ bp:
   - make mce_centaur_feature_init() static
   - flip check to do the f/m/s first for better readability
   - touch up text
  ]

Signed-off-by: David Wang 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: Greg KH 
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: Tony Luck 
Cc: benjamin...@viatech.com
Cc: linux-edac 
Link: 
http://lkml.kernel.org/r/1524652420-17330-2-git-send-email-davidw...@zhaoxin.com

---
 arch/x86/kernel/cpu/mcheck/mce.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 42cf2880d0ed..cd76380af79f 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1727,6 +1727,21 @@ static void __mcheck_cpu_init_early(struct cpuinfo_x86 
*c)
}
 }
 
+static void mce_centaur_feature_init(struct cpuinfo_x86 *c)
+{
+   struct mca_config *cfg = _cfg;
+
+/*
+ * All newer Centaur CPUs support MCE broadcasting. Enable
+ * synchronization with a one second timeout.
+ */
+   if ((c->x86 == 6 && c->x86_model == 0xf && c->x86_stepping >= 0xe) ||
+c->x86 > 6) {
+   if (cfg->monarch_timeout < 0)
+   cfg->monarch_timeout = USEC_PER_SEC;
+   }
+}
+
 static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
 {
switch (c->x86_vendor) {
@@ -1739,6 +1754,9 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
mce_amd_feature_init(c);
break;
}
+   case X86_VENDOR_CENTAUR:
+   mce_centaur_feature_init(c);
+   break;
 
default:
break;


[PATCH 3/3] x86/Centaur: Report correct CPU/cache topology

2018-05-02 Thread David Wang
Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
but the function is unused so for. The Centaur init code also missies to
initialize x86_info::max_cores, so the CPU topology can't be described
correctly.

Initialize x86_info::max_cores and invoke init_intel_cacheinfo() to make
CPU and cache topology information available and correct.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 arch/x86/kernel/cpu/centaur.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 80d5110..c265494 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -160,6 +160,11 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+   init_intel_cacheinfo(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
+#ifdef CONFIG_X86_32
+   detect_ht(c);
+#endif
 
if (c->cpuid_level > 9) {
unsigned int eax = cpuid_eax(10);
-- 
1.9.1



[PATCH 3/3] x86/Centaur: Report correct CPU/cache topology

2018-05-02 Thread David Wang
Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
but the function is unused so for. The Centaur init code also missies to
initialize x86_info::max_cores, so the CPU topology can't be described
correctly.

Initialize x86_info::max_cores and invoke init_intel_cacheinfo() to make
CPU and cache topology information available and correct.

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/centaur.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 80d5110..c265494 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -160,6 +160,11 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+   init_intel_cacheinfo(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
+#ifdef CONFIG_X86_32
+   detect_ht(c);
+#endif
 
if (c->cpuid_level > 9) {
unsigned int eax = cpuid_eax(10);
-- 
1.9.1



[PATCH 0/3] x86/CPU: Report correct cpu/cache topo for Centaur CPUs and some minor changes

2018-05-02 Thread David Wang
There are three patches:

The first patch define detect_num_cpu_cores() in common.c to replace the
original intel_num_cpu_cores() which is defined in intel.c; 

The second patch is used to include the legacy cpu_detect_cache_sizes()
into the init_intel_cacheinfo() function;

The third patch is used to report correct CPU/Cache topology by using the
functions defined in the first and the second patch;

David Wang (3):
  x86/CPU: Replace intel_num_cpu_cores with detect_num_cpu_cores
  x86/cpu/intel_cacheinfo: include cpu_detect_cache_size in
init_intel_cacheinfo
  x86/Centaur: Report correct CPU/cache topology

 arch/x86/include/asm/processor.h  |  1 +
 arch/x86/kernel/cpu/centaur.c |  5 +
 arch/x86/kernel/cpu/common.c  | 14 ++
 arch/x86/kernel/cpu/intel.c   | 28 ++--
 arch/x86/kernel/cpu/intel_cacheinfo.c |  6 ++
 5 files changed, 28 insertions(+), 26 deletions(-)

-- 
1.9.1



[PATCH 0/3] x86/CPU: Report correct cpu/cache topo for Centaur CPUs and some minor changes

2018-05-02 Thread David Wang
There are three patches:

The first patch define detect_num_cpu_cores() in common.c to replace the
original intel_num_cpu_cores() which is defined in intel.c; 

The second patch is used to include the legacy cpu_detect_cache_sizes()
into the init_intel_cacheinfo() function;

The third patch is used to report correct CPU/Cache topology by using the
functions defined in the first and the second patch;

David Wang (3):
  x86/CPU: Replace intel_num_cpu_cores with detect_num_cpu_cores
  x86/cpu/intel_cacheinfo: include cpu_detect_cache_size in
init_intel_cacheinfo
  x86/Centaur: Report correct CPU/cache topology

 arch/x86/include/asm/processor.h  |  1 +
 arch/x86/kernel/cpu/centaur.c |  5 +
 arch/x86/kernel/cpu/common.c  | 14 ++
 arch/x86/kernel/cpu/intel.c   | 28 ++--
 arch/x86/kernel/cpu/intel_cacheinfo.c |  6 ++
 5 files changed, 28 insertions(+), 26 deletions(-)

-- 
1.9.1



[PATCH 1/3] x86/CPU: Replace intel_num_cpu_cores with detect_num_cpu_cores

2018-05-02 Thread David Wang
intel_num_cpu_cores() is a static defination in intel.c which can't be used by 
other files. Define another function called detect_num_cpu_cores() in common.c
to replace this function.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 arch/x86/include/asm/processor.h |  1 +
 arch/x86/kernel/cpu/common.c | 14 ++
 arch/x86/kernel/cpu/intel.c  | 20 +---
 3 files changed, 16 insertions(+), 19 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index e56fe7c..b0553f6 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -192,6 +192,7 @@ extern u32 get_scattered_cpuid_leaf(unsigned int level,
enum cpuid_regs_idx reg);
 extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
+extern int detect_num_cpu_cores(struct cpuinfo_x86 *c);
 
 extern void detect_extended_topology(struct cpuinfo_x86 *c);
 extern void detect_ht(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 8a5b185..0c80d50 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -577,6 +577,20 @@ static void get_model_name(struct cpuinfo_x86 *c)
*(s + 1) = '\0';
 }
 
+int detect_num_cpu_cores(struct cpuinfo_x86 *c)
+{
+   unsigned int eax, ebx, ecx, edx;
+
+   if (!IS_ENABLED(CONFIG_SMP) || c->cpuid_level < 4)
+   return 1;
+
+   cpuid_count(4, 0, , , , );
+   if (eax & 0x1f)
+   return (eax >> 26) + 1;
+   else
+   return 1;
+}
+
 void cpu_detect_cache_sizes(struct cpuinfo_x86 *c)
 {
unsigned int n, dummy, ebx, ecx, edx, l2size;
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 60d1897..f683f7d 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -453,24 +453,6 @@ static void srat_detect_node(struct cpuinfo_x86 *c)
 #endif
 }
 
-/*
- * find out the number of processor cores on the die
- */
-static int intel_num_cpu_cores(struct cpuinfo_x86 *c)
-{
-   unsigned int eax, ebx, ecx, edx;
-
-   if (!IS_ENABLED(CONFIG_SMP) || c->cpuid_level < 4)
-   return 1;
-
-   /* Intel has a non-standard dependency on %ecx for this CPUID level. */
-   cpuid_count(4, 0, , , , );
-   if (eax & 0x1f)
-   return (eax >> 26) + 1;
-   else
-   return 1;
-}
-
 static void detect_vmx_virtcap(struct cpuinfo_x86 *c)
 {
/* Intel VMX MSR indicated features */
@@ -671,7 +653,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 * let's use the legacy cpuid vector 0x1 and 0x4 for topology
 * detection.
 */
-   c->x86_max_cores = intel_num_cpu_cores(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
 #ifdef CONFIG_X86_32
detect_ht(c);
 #endif
-- 
1.9.1



[PATCH 1/3] x86/CPU: Replace intel_num_cpu_cores with detect_num_cpu_cores

2018-05-02 Thread David Wang
intel_num_cpu_cores() is a static defination in intel.c which can't be used by 
other files. Define another function called detect_num_cpu_cores() in common.c
to replace this function.

Signed-off-by: David Wang 
---
 arch/x86/include/asm/processor.h |  1 +
 arch/x86/kernel/cpu/common.c | 14 ++
 arch/x86/kernel/cpu/intel.c  | 20 +---
 3 files changed, 16 insertions(+), 19 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index e56fe7c..b0553f6 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -192,6 +192,7 @@ extern u32 get_scattered_cpuid_leaf(unsigned int level,
enum cpuid_regs_idx reg);
 extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
+extern int detect_num_cpu_cores(struct cpuinfo_x86 *c);
 
 extern void detect_extended_topology(struct cpuinfo_x86 *c);
 extern void detect_ht(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 8a5b185..0c80d50 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -577,6 +577,20 @@ static void get_model_name(struct cpuinfo_x86 *c)
*(s + 1) = '\0';
 }
 
+int detect_num_cpu_cores(struct cpuinfo_x86 *c)
+{
+   unsigned int eax, ebx, ecx, edx;
+
+   if (!IS_ENABLED(CONFIG_SMP) || c->cpuid_level < 4)
+   return 1;
+
+   cpuid_count(4, 0, , , , );
+   if (eax & 0x1f)
+   return (eax >> 26) + 1;
+   else
+   return 1;
+}
+
 void cpu_detect_cache_sizes(struct cpuinfo_x86 *c)
 {
unsigned int n, dummy, ebx, ecx, edx, l2size;
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 60d1897..f683f7d 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -453,24 +453,6 @@ static void srat_detect_node(struct cpuinfo_x86 *c)
 #endif
 }
 
-/*
- * find out the number of processor cores on the die
- */
-static int intel_num_cpu_cores(struct cpuinfo_x86 *c)
-{
-   unsigned int eax, ebx, ecx, edx;
-
-   if (!IS_ENABLED(CONFIG_SMP) || c->cpuid_level < 4)
-   return 1;
-
-   /* Intel has a non-standard dependency on %ecx for this CPUID level. */
-   cpuid_count(4, 0, , , , );
-   if (eax & 0x1f)
-   return (eax >> 26) + 1;
-   else
-   return 1;
-}
-
 static void detect_vmx_virtcap(struct cpuinfo_x86 *c)
 {
/* Intel VMX MSR indicated features */
@@ -671,7 +653,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 * let's use the legacy cpuid vector 0x1 and 0x4 for topology
 * detection.
 */
-   c->x86_max_cores = intel_num_cpu_cores(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
 #ifdef CONFIG_X86_32
detect_ht(c);
 #endif
-- 
1.9.1



[PATCH 2/3] x86/cpu: Include cpu_detect_cache_sizes in init_intel_cacheinfo

2018-05-02 Thread David Wang
Clean up the silly cpu_detect_cache_sizes() calling by including the
cpu_detect_cache_sizes() inside the init_intel_cacheinfo(). 

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 arch/x86/kernel/cpu/intel.c   | 8 +---
 arch/x86/kernel/cpu/intel_cacheinfo.c | 6 ++
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index f683f7d..56e3259 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -659,13 +659,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 #endif
}
 
-   l2 = init_intel_cacheinfo(c);
-
-   /* Detect legacy cache sizes if init_intel_cacheinfo did not */
-   if (l2 == 0) {
-   cpu_detect_cache_sizes(c);
-   l2 = c->x86_cache_size;
-   }
+   init_intel_cacheinfo(c);
 
if (c->cpuid_level > 9) {
unsigned eax = cpuid_eax(10);
diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index 54d04d5..2a0597c 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 
+#include "cpu.h"
+
 #define LVL_1_INST 1
 #define LVL_1_DATA 2
 #define LVL_2  3
@@ -802,6 +804,10 @@ unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c)
 
c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i+l1d));
 
+   if (!l2) {
+   cpu_detect_cache_sizes(c);
+   l2 = c->x86_cache_size;
+   }
return l2;
 }
 
-- 
1.9.1



[PATCH 2/3] x86/cpu: Include cpu_detect_cache_sizes in init_intel_cacheinfo

2018-05-02 Thread David Wang
Clean up the silly cpu_detect_cache_sizes() calling by including the
cpu_detect_cache_sizes() inside the init_intel_cacheinfo(). 

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/intel.c   | 8 +---
 arch/x86/kernel/cpu/intel_cacheinfo.c | 6 ++
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index f683f7d..56e3259 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -659,13 +659,7 @@ static void init_intel(struct cpuinfo_x86 *c)
 #endif
}
 
-   l2 = init_intel_cacheinfo(c);
-
-   /* Detect legacy cache sizes if init_intel_cacheinfo did not */
-   if (l2 == 0) {
-   cpu_detect_cache_sizes(c);
-   l2 = c->x86_cache_size;
-   }
+   init_intel_cacheinfo(c);
 
if (c->cpuid_level > 9) {
unsigned eax = cpuid_eax(10);
diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index 54d04d5..2a0597c 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 
+#include "cpu.h"
+
 #define LVL_1_INST 1
 #define LVL_1_DATA 2
 #define LVL_2  3
@@ -802,6 +804,10 @@ unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c)
 
c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i+l1d));
 
+   if (!l2) {
+   cpu_detect_cache_sizes(c);
+   l2 = c->x86_cache_size;
+   }
return l2;
 }
 
-- 
1.9.1



Re: [PATCH v3 2/2] x86/mce: add CMCI support for Centaur CPUs

2018-05-02 Thread David Wang


> -Original Mail-
> Sender: Borislav Petkov [mailto:b...@alien8.de]
> Time: 2018年4月30日 17:48
> Receiver: David Wang <davidw...@zhaoxin.com>
> CC: tony.l...@intel.com; t...@linutronix.de; mi...@redhat.com;
> h...@zytor.com; gre...@linuxfoundation.org; x...@kernel.org; linux-
> ker...@vger.kernel.org; linux-e...@vger.kernel.org; brucechang@via-
> alliance.com; cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> Subject: Re: [PATCH v3 2/2] x86/mce: add CMCI support for Centaur CPUs
> 
> On Wed, Apr 25, 2018 at 06:33:40PM +0800, David Wang wrote:
> > Newer Centaur support CMCI mechnism, which is compatible with INTEL
> CMCI.
> >
> > Signed-off-by: David Wang <davidw...@zhaoxin.com>
> > ---
> >  arch/x86/kernel/cpu/mcheck/mce.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> > b/arch/x86/kernel/cpu/mcheck/mce.c
> > index 38ccab8..f9a7295 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> > @@ -1757,6 +1757,8 @@ static void __mcheck_cpu_init_vendor(struct
> cpuinfo_x86 *c)
> > }
> > case X86_VENDOR_CENTAUR:
> > mce_centaur_feature_init(c);
> > +   mce_intel_feature_init(c);
> > +   mce_adjust_timer = cmci_intel_adjust_timer;
> 
> This won't work in configs with CONFIG_X86_MCE_INTEL disabled.
> 
> You need to define CONFIG_X86_MCE_CENTAUR or so which depends on
> CONFIG_CPU_SUP_CENTAUR and CONFIG_X86_MCE_INTEL and which then
> makes sure the intel CMCI et al stuff is enabled.
> 
> --
> Regards/Gruss,
> Boris.
> 
> Good mailing practices for 400: avoid top-posting and trim the reply.

OK. I got it.
I will send another patch.
Thank you.

---
David





Re: [PATCH v3 2/2] x86/mce: add CMCI support for Centaur CPUs

2018-05-02 Thread David Wang


> -Original Mail-
> Sender: Borislav Petkov [mailto:b...@alien8.de]
> Time: 2018年4月30日 17:48
> Receiver: David Wang 
> CC: tony.l...@intel.com; t...@linutronix.de; mi...@redhat.com;
> h...@zytor.com; gre...@linuxfoundation.org; x...@kernel.org; linux-
> ker...@vger.kernel.org; linux-e...@vger.kernel.org; brucechang@via-
> alliance.com; cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> Subject: Re: [PATCH v3 2/2] x86/mce: add CMCI support for Centaur CPUs
> 
> On Wed, Apr 25, 2018 at 06:33:40PM +0800, David Wang wrote:
> > Newer Centaur support CMCI mechnism, which is compatible with INTEL
> CMCI.
> >
> > Signed-off-by: David Wang 
> > ---
> >  arch/x86/kernel/cpu/mcheck/mce.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> > b/arch/x86/kernel/cpu/mcheck/mce.c
> > index 38ccab8..f9a7295 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> > @@ -1757,6 +1757,8 @@ static void __mcheck_cpu_init_vendor(struct
> cpuinfo_x86 *c)
> > }
> > case X86_VENDOR_CENTAUR:
> > mce_centaur_feature_init(c);
> > +   mce_intel_feature_init(c);
> > +   mce_adjust_timer = cmci_intel_adjust_timer;
> 
> This won't work in configs with CONFIG_X86_MCE_INTEL disabled.
> 
> You need to define CONFIG_X86_MCE_CENTAUR or so which depends on
> CONFIG_CPU_SUP_CENTAUR and CONFIG_X86_MCE_INTEL and which then
> makes sure the intel CMCI et al stuff is enabled.
> 
> --
> Regards/Gruss,
> Boris.
> 
> Good mailing practices for 400: avoid top-posting and trim the reply.

OK. I got it.
I will send another patch.
Thank you.

---
David





Re: [PATCH v3] report correct CPU/cache topology

2018-05-02 Thread David Wang


> -Original Mail-
> Sender: Thomas Gleixner [mailto:t...@linutronix.de]
> Time: 2018年4月26日 19:56
> Receiver: David Wang <davidw...@zhaoxin.com>
> CC: mi...@redhat.com; h...@zytor.com; gre...@linuxfoundation.org;
> x...@kernel.org; linux-kernel@vger.kernel.org; brucechang@via-
> alliance.com; cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> Subject: Re: [PATCH v3] report correct CPU/cache topology
> 
> 
> 
> On Thu, 26 Apr 2018, David Wang wrote:
> 
> > Centaur CPUs enumerate the cache topology in the same way as Intel
> > CPUs, but the function is unused so far.
> > The Centaur init code also misses to initialize x86_info::max_cores,
> > so the CPU topology can't be described correctly.
> >
> > Initialize x86_info::max_cores and invoke init_intel_cachinfo() to
> > make CPU and cache topology information avaliable and correct
> 
> Now that looks pretty good.
> 
> > Signed-off-by: David Wang <davidw...@zhaoxin.com>
> >
> > Changes from v2 to v3:
> > *1 define new detect_num_cpu_cores() in common.c to replace the
> > original intel_num_cpu_cores;
> > *2 move cpu_detect_cache_sizes inside init_intel_cacheinfo.
> 
> But I asked for that being a separate patch with a separate changelog. And
> the intel_cache_info() change wants to be in a separate patch as well.
Then
> the third patch is the one which makes use of these changes for centaur.
> 
> Please read review comments carefully and rather ask when you have
> doubts about the meaning.
> 
> Thanks,
> 
>   tglx
> 
Sorry! 
I will split the changes to three separate patches.
Thank you.
---
David






Re: [PATCH v3] report correct CPU/cache topology

2018-05-02 Thread David Wang


> -Original Mail-
> Sender: Thomas Gleixner [mailto:t...@linutronix.de]
> Time: 2018年4月26日 19:56
> Receiver: David Wang 
> CC: mi...@redhat.com; h...@zytor.com; gre...@linuxfoundation.org;
> x...@kernel.org; linux-kernel@vger.kernel.org; brucechang@via-
> alliance.com; cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> Subject: Re: [PATCH v3] report correct CPU/cache topology
> 
> 
> 
> On Thu, 26 Apr 2018, David Wang wrote:
> 
> > Centaur CPUs enumerate the cache topology in the same way as Intel
> > CPUs, but the function is unused so far.
> > The Centaur init code also misses to initialize x86_info::max_cores,
> > so the CPU topology can't be described correctly.
> >
> > Initialize x86_info::max_cores and invoke init_intel_cachinfo() to
> > make CPU and cache topology information avaliable and correct
> 
> Now that looks pretty good.
> 
> > Signed-off-by: David Wang 
> >
> > Changes from v2 to v3:
> > *1 define new detect_num_cpu_cores() in common.c to replace the
> > original intel_num_cpu_cores;
> > *2 move cpu_detect_cache_sizes inside init_intel_cacheinfo.
> 
> But I asked for that being a separate patch with a separate changelog. And
> the intel_cache_info() change wants to be in a separate patch as well.
Then
> the third patch is the one which makes use of these changes for centaur.
> 
> Please read review comments carefully and rather ask when you have
> doubts about the meaning.
> 
> Thanks,
> 
>   tglx
> 
Sorry! 
I will split the changes to three separate patches.
Thank you.
---
David






[PATCH v3] report correct CPU/cache topology

2018-04-26 Thread David Wang
Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
but the function is unused so far.
The Centaur init code also misses to initialize x86_info::max_cores, so
the CPU topology can't be described correctly.

Initialize x86_info::max_cores and invoke init_intel_cachinfo() to make
CPU and cache topology information avaliable and correct

Signed-off-by: David Wang <davidw...@zhaoxin.com>

Changes from v2 to v3:
*1 define new detect_num_cpu_cores() in common.c to replace the original
intel_num_cpu_cores;  
*2 move cpu_detect_cache_sizes inside init_intel_cacheinfo.

Changes from v1 to v2:
*1 replace centaur_num_cpu_cores with early_init_centaur_mc according to 
suggestions from tglx;
*2 call cpu_detect_cache_sizes when init_intel_cacheinfo returns 0. For
some very old Centaur CPUs can't support the mechanisms defined in init_
intel_cacheinfo.

---
 arch/x86/include/asm/processor.h  |  1 +
 arch/x86/kernel/cpu/centaur.c |  5 +
 arch/x86/kernel/cpu/common.c  | 14 ++
 arch/x86/kernel/cpu/intel.c   | 28 ++--
 arch/x86/kernel/cpu/intel_cacheinfo.c |  6 ++
 5 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 21a1149..96e9070 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -192,6 +192,7 @@ extern u32 get_scattered_cpuid_leaf(unsigned int level,
enum cpuid_regs_idx reg);
 extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
+extern int detect_num_cpu_cores(struct cpuinfo_x86 *c);
 
 extern void detect_extended_topology(struct cpuinfo_x86 *c);
 extern void detect_ht(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 80d5110..c265494 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -160,6 +160,11 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+   init_intel_cacheinfo(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
+#ifdef CONFIG_X86_32
+   detect_ht(c);
+#endif
 
if (c->cpuid_level > 9) {
unsigned int eax = cpuid_eax(10);
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 8a5b185..0c80d50 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -577,6 +577,20 @@ static void get_model_name(struct cpuinfo_x86 *c)
*(s + 1) = '\0';
 }
 
+int detect_num_cpu_cores(struct cpuinfo_x86 *c)
+{
+   unsigned int eax, ebx, ecx, edx;
+
+   if (!IS_ENABLED(CONFIG_SMP) || c->cpuid_level < 4)
+   return 1;
+
+   cpuid_count(4, 0, , , , );
+   if (eax & 0x1f)
+   return (eax >> 26) + 1;
+   else
+   return 1;
+}
+
 void cpu_detect_cache_sizes(struct cpuinfo_x86 *c)
 {
unsigned int n, dummy, ebx, ecx, edx, l2size;
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index b9693b8..e1138da 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -453,24 +453,6 @@ static void srat_detect_node(struct cpuinfo_x86 *c)
 #endif
 }
 
-/*
- * find out the number of processor cores on the die
- */
-static int intel_num_cpu_cores(struct cpuinfo_x86 *c)
-{
-   unsigned int eax, ebx, ecx, edx;
-
-   if (!IS_ENABLED(CONFIG_SMP) || c->cpuid_level < 4)
-   return 1;
-
-   /* Intel has a non-standard dependency on %ecx for this CPUID level. */
-   cpuid_count(4, 0, , , , );
-   if (eax & 0x1f)
-   return (eax >> 26) + 1;
-   else
-   return 1;
-}
-
 static void detect_vmx_virtcap(struct cpuinfo_x86 *c)
 {
/* Intel VMX MSR indicated features */
@@ -671,19 +653,13 @@ static void init_intel(struct cpuinfo_x86 *c)
 * let's use the legacy cpuid vector 0x1 and 0x4 for topology
 * detection.
 */
-   c->x86_max_cores = intel_num_cpu_cores(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
 #ifdef CONFIG_X86_32
detect_ht(c);
 #endif
}
 
-   l2 = init_intel_cacheinfo(c);
-
-   /* Detect legacy cache sizes if init_intel_cacheinfo did not */
-   if (l2 == 0) {
-   cpu_detect_cache_sizes(c);
-   l2 = c->x86_cache_size;
-   }
+   init_intel_cacheinfo(c);
 
if (c->cpuid_level > 9) {
unsigned eax = cpuid_eax(10);
diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index 54d04d5..2a0597c 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 
+#include "cpu.h"
+
 #def

[PATCH v3] report correct CPU/cache topology

2018-04-26 Thread David Wang
Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
but the function is unused so far.
The Centaur init code also misses to initialize x86_info::max_cores, so
the CPU topology can't be described correctly.

Initialize x86_info::max_cores and invoke init_intel_cachinfo() to make
CPU and cache topology information avaliable and correct

Signed-off-by: David Wang 

Changes from v2 to v3:
*1 define new detect_num_cpu_cores() in common.c to replace the original
intel_num_cpu_cores;  
*2 move cpu_detect_cache_sizes inside init_intel_cacheinfo.

Changes from v1 to v2:
*1 replace centaur_num_cpu_cores with early_init_centaur_mc according to 
suggestions from tglx;
*2 call cpu_detect_cache_sizes when init_intel_cacheinfo returns 0. For
some very old Centaur CPUs can't support the mechanisms defined in init_
intel_cacheinfo.

---
 arch/x86/include/asm/processor.h  |  1 +
 arch/x86/kernel/cpu/centaur.c |  5 +
 arch/x86/kernel/cpu/common.c  | 14 ++
 arch/x86/kernel/cpu/intel.c   | 28 ++--
 arch/x86/kernel/cpu/intel_cacheinfo.c |  6 ++
 5 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 21a1149..96e9070 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -192,6 +192,7 @@ extern u32 get_scattered_cpuid_leaf(unsigned int level,
enum cpuid_regs_idx reg);
 extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
+extern int detect_num_cpu_cores(struct cpuinfo_x86 *c);
 
 extern void detect_extended_topology(struct cpuinfo_x86 *c);
 extern void detect_ht(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 80d5110..c265494 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -160,6 +160,11 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+   init_intel_cacheinfo(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
+#ifdef CONFIG_X86_32
+   detect_ht(c);
+#endif
 
if (c->cpuid_level > 9) {
unsigned int eax = cpuid_eax(10);
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 8a5b185..0c80d50 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -577,6 +577,20 @@ static void get_model_name(struct cpuinfo_x86 *c)
*(s + 1) = '\0';
 }
 
+int detect_num_cpu_cores(struct cpuinfo_x86 *c)
+{
+   unsigned int eax, ebx, ecx, edx;
+
+   if (!IS_ENABLED(CONFIG_SMP) || c->cpuid_level < 4)
+   return 1;
+
+   cpuid_count(4, 0, , , , );
+   if (eax & 0x1f)
+   return (eax >> 26) + 1;
+   else
+   return 1;
+}
+
 void cpu_detect_cache_sizes(struct cpuinfo_x86 *c)
 {
unsigned int n, dummy, ebx, ecx, edx, l2size;
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index b9693b8..e1138da 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -453,24 +453,6 @@ static void srat_detect_node(struct cpuinfo_x86 *c)
 #endif
 }
 
-/*
- * find out the number of processor cores on the die
- */
-static int intel_num_cpu_cores(struct cpuinfo_x86 *c)
-{
-   unsigned int eax, ebx, ecx, edx;
-
-   if (!IS_ENABLED(CONFIG_SMP) || c->cpuid_level < 4)
-   return 1;
-
-   /* Intel has a non-standard dependency on %ecx for this CPUID level. */
-   cpuid_count(4, 0, , , , );
-   if (eax & 0x1f)
-   return (eax >> 26) + 1;
-   else
-   return 1;
-}
-
 static void detect_vmx_virtcap(struct cpuinfo_x86 *c)
 {
/* Intel VMX MSR indicated features */
@@ -671,19 +653,13 @@ static void init_intel(struct cpuinfo_x86 *c)
 * let's use the legacy cpuid vector 0x1 and 0x4 for topology
 * detection.
 */
-   c->x86_max_cores = intel_num_cpu_cores(c);
+   c->x86_max_cores = detect_num_cpu_cores(c);
 #ifdef CONFIG_X86_32
detect_ht(c);
 #endif
}
 
-   l2 = init_intel_cacheinfo(c);
-
-   /* Detect legacy cache sizes if init_intel_cacheinfo did not */
-   if (l2 == 0) {
-   cpu_detect_cache_sizes(c);
-   l2 = c->x86_cache_size;
-   }
+   init_intel_cacheinfo(c);
 
if (c->cpuid_level > 9) {
unsigned eax = cpuid_eax(10);
diff --git a/arch/x86/kernel/cpu/intel_cacheinfo.c 
b/arch/x86/kernel/cpu/intel_cacheinfo.c
index 54d04d5..2a0597c 100644
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 
+#include "cpu.h"
+
 #define LVL_1_INST 1
 #define LVL_1_

Re: [PATCH v2] x86/centaur: report correct CPU/cache topology

2018-04-26 Thread David Wang


> -Original Mail-
> Sender: Thomas Gleixner [mailto:t...@linutronix.de]
> Time: 2018年4月26日 17:12
> Receiver: David Wang <davidw...@zhaoxin.com>
> CC: mi...@redhat.com; h...@zytor.com; gre...@linuxfoundation.org;
> x...@kernel.org; linux-kernel@vger.kernel.org; brucechang@via-
> alliance.com; cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> Subject: Re: [PATCH v2] x86/centaur: report correct CPU/cache topology
> 
> On Wed, 25 Apr 2018, David Wang wrote:
> >
> > +static void early_init_centaur_mc(struct cpuinfo_x86 *c) { #ifdef
> > +CONFIG_SMP
> > +   unsigned int eax, ebx, ecx, edx;
> > +
> > +   if (c->cpuid_level < 4)
> > +   return;
> > +
> > +   cpuid_count(4, 0, , , , );
> > +   if (eax & 0x1f)
> > +   c->x86_max_cores = (eax >> 26) + 1;
> > +   else
> > +   return;
> > +#endif
> > +}
> 
> My review comment from last time still stands:
> 
> > > This is a bad copy of intel_num_cpu_cores(). See for the subtle
> > > difference. Please rename the intel function and move it to common.c
> 
> In other words:
> 
> Make a patch which moves intel_num_cpu_cores() into common.c. Rename
> the function into something like detect_num_cpu_cores() and fix up the
call
> site in intel.c.
> 
> Then add your patch and use the very same function.
> 

OK. I got it.
> > +
> >  static void early_init_centaur(struct cpuinfo_x86 *c)  {
> > +   early_init_centaur_mc(c);
> > switch (c->x86) {
> >  #ifdef CONFIG_X86_32
> > case 5:
> > @@ -146,6 +163,7 @@ static void centaur_detect_vmx_virtcap(struct
> > cpuinfo_x86 *c)
> >
> >  static void init_centaur(struct cpuinfo_x86 *c)  {
> > +   unsigned int l2 = 0;
> >  #ifdef CONFIG_X86_32
> > char *name;
> > u32  fcr_set = 0;
> > @@ -161,6 +179,17 @@ static void init_centaur(struct cpuinfo_x86 *c)
> > #endif
> > early_init_centaur(c);
> >
> > +   l2 = init_intel_cacheinfo(c);
> > +
> > +   /* Detect legacy cache sizes if init_intel_cacheinfo did not */
> > +   if (l2 == 0) {
> > +   cpu_detect_cache_sizes(c);
> > +   }
> 
> Aside of the pointless parentheses, this really wants to be cleaned up as
well.
> 
> init_intel_cacheinfo() is called from the intel init code and it does the
same
> silly thing.
> 
> So the right thing to do is in a separate patch first
> 
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -679,12 +679,6 @@ static void init_intel(struct cpuinfo_x8
> 
>   l2 = init_intel_cacheinfo(c);
> 
> - /* Detect legacy cache sizes if init_intel_cacheinfo did not */
> - if (l2 == 0) {
> - cpu_detect_cache_sizes(c);
> - l2 = c->x86_cache_size;
> - }
> -
>   if (c->cpuid_level > 9) {
>   unsigned eax = cpuid_eax(10);
>   /* Check for version and the number of counters */
> --- a/arch/x86/kernel/cpu/intel_cacheinfo.c
> +++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
> @@ -802,6 +802,11 @@ unsigned int init_intel_cacheinfo(struct
> 
>   c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i+l1d));
> 
> + /* Detect legacy cache sizes if the above did not work */
> + if (!l2) {
> + cpu_detect_cache_sizes(c);
> + l2 = c->x86_cache_size;
> + }
>   return l2;
>  }
> 
> Hmm?
> 
>   tglx
> 
OK. I got it.
Patch v3 will be sent later.
Thank you.
---
David






Re: [PATCH v2] x86/centaur: report correct CPU/cache topology

2018-04-26 Thread David Wang


> -Original Mail-
> Sender: Thomas Gleixner [mailto:t...@linutronix.de]
> Time: 2018年4月26日 17:12
> Receiver: David Wang 
> CC: mi...@redhat.com; h...@zytor.com; gre...@linuxfoundation.org;
> x...@kernel.org; linux-kernel@vger.kernel.org; brucechang@via-
> alliance.com; cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> Subject: Re: [PATCH v2] x86/centaur: report correct CPU/cache topology
> 
> On Wed, 25 Apr 2018, David Wang wrote:
> >
> > +static void early_init_centaur_mc(struct cpuinfo_x86 *c) { #ifdef
> > +CONFIG_SMP
> > +   unsigned int eax, ebx, ecx, edx;
> > +
> > +   if (c->cpuid_level < 4)
> > +   return;
> > +
> > +   cpuid_count(4, 0, , , , );
> > +   if (eax & 0x1f)
> > +   c->x86_max_cores = (eax >> 26) + 1;
> > +   else
> > +   return;
> > +#endif
> > +}
> 
> My review comment from last time still stands:
> 
> > > This is a bad copy of intel_num_cpu_cores(). See for the subtle
> > > difference. Please rename the intel function and move it to common.c
> 
> In other words:
> 
> Make a patch which moves intel_num_cpu_cores() into common.c. Rename
> the function into something like detect_num_cpu_cores() and fix up the
call
> site in intel.c.
> 
> Then add your patch and use the very same function.
> 

OK. I got it.
> > +
> >  static void early_init_centaur(struct cpuinfo_x86 *c)  {
> > +   early_init_centaur_mc(c);
> > switch (c->x86) {
> >  #ifdef CONFIG_X86_32
> > case 5:
> > @@ -146,6 +163,7 @@ static void centaur_detect_vmx_virtcap(struct
> > cpuinfo_x86 *c)
> >
> >  static void init_centaur(struct cpuinfo_x86 *c)  {
> > +   unsigned int l2 = 0;
> >  #ifdef CONFIG_X86_32
> > char *name;
> > u32  fcr_set = 0;
> > @@ -161,6 +179,17 @@ static void init_centaur(struct cpuinfo_x86 *c)
> > #endif
> > early_init_centaur(c);
> >
> > +   l2 = init_intel_cacheinfo(c);
> > +
> > +   /* Detect legacy cache sizes if init_intel_cacheinfo did not */
> > +   if (l2 == 0) {
> > +   cpu_detect_cache_sizes(c);
> > +   }
> 
> Aside of the pointless parentheses, this really wants to be cleaned up as
well.
> 
> init_intel_cacheinfo() is called from the intel init code and it does the
same
> silly thing.
> 
> So the right thing to do is in a separate patch first
> 
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -679,12 +679,6 @@ static void init_intel(struct cpuinfo_x8
> 
>   l2 = init_intel_cacheinfo(c);
> 
> - /* Detect legacy cache sizes if init_intel_cacheinfo did not */
> - if (l2 == 0) {
> - cpu_detect_cache_sizes(c);
> - l2 = c->x86_cache_size;
> - }
> -
>   if (c->cpuid_level > 9) {
>   unsigned eax = cpuid_eax(10);
>   /* Check for version and the number of counters */
> --- a/arch/x86/kernel/cpu/intel_cacheinfo.c
> +++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
> @@ -802,6 +802,11 @@ unsigned int init_intel_cacheinfo(struct
> 
>   c->x86_cache_size = l3 ? l3 : (l2 ? l2 : (l1i+l1d));
> 
> + /* Detect legacy cache sizes if the above did not work */
> + if (!l2) {
> + cpu_detect_cache_sizes(c);
> + l2 = c->x86_cache_size;
> + }
>   return l2;
>  }
> 
> Hmm?
> 
>   tglx
> 
OK. I got it.
Patch v3 will be sent later.
Thank you.
---
David






[PATCH v3 1/2] x86/mce: new Centaur CPU support MCE broadcasting

2018-04-25 Thread David Wang
Newer Centaur multi-core CPU also support MCE broadcasting to all cores. But
no Centaur special code tell this truth to kernel.  

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 arch/x86/kernel/cpu/mcheck/mce.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 42cf288..38ccab8 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1727,6 +1727,22 @@ static void __mcheck_cpu_init_early(struct cpuinfo_x86 
*c)
}
 }
 
+void mce_centaur_feature_init(struct cpuinfo_x86 *c)
+{
+   struct mca_config *cfg = _cfg;
+
+/*
+ * All newer Centaur CPUs support MCE broadcasting. Enable
+ * synchronization with a one second timeout.
+ */
+   if (cfg->monarch_timeout < 0) {
+   if ((c->x86 == 6 && c->x86_model == 0xf &&
+   c->x86_stepping >= 0xe) || c->x86 > 6)
+   cfg->monarch_timeout = USEC_PER_SEC;
+   }
+}
+
+
 static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
 {
switch (c->x86_vendor) {
@@ -1739,6 +1755,9 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
mce_amd_feature_init(c);
break;
}
+   case X86_VENDOR_CENTAUR:
+   mce_centaur_feature_init(c);
+   break;
 
default:
break;
-- 
1.9.1



[PATCH v3 1/2] x86/mce: new Centaur CPU support MCE broadcasting

2018-04-25 Thread David Wang
Newer Centaur multi-core CPU also support MCE broadcasting to all cores. But
no Centaur special code tell this truth to kernel.  

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 42cf288..38ccab8 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1727,6 +1727,22 @@ static void __mcheck_cpu_init_early(struct cpuinfo_x86 
*c)
}
 }
 
+void mce_centaur_feature_init(struct cpuinfo_x86 *c)
+{
+   struct mca_config *cfg = _cfg;
+
+/*
+ * All newer Centaur CPUs support MCE broadcasting. Enable
+ * synchronization with a one second timeout.
+ */
+   if (cfg->monarch_timeout < 0) {
+   if ((c->x86 == 6 && c->x86_model == 0xf &&
+   c->x86_stepping >= 0xe) || c->x86 > 6)
+   cfg->monarch_timeout = USEC_PER_SEC;
+   }
+}
+
+
 static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
 {
switch (c->x86_vendor) {
@@ -1739,6 +1755,9 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
mce_amd_feature_init(c);
break;
}
+   case X86_VENDOR_CENTAUR:
+   mce_centaur_feature_init(c);
+   break;
 
default:
break;
-- 
1.9.1



[PATCH v3 2/2] x86/mce: add CMCI support for Centaur CPUs

2018-04-25 Thread David Wang
Newer Centaur support CMCI mechnism, which is compatible with INTEL CMCI.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 arch/x86/kernel/cpu/mcheck/mce.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 38ccab8..f9a7295 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1757,6 +1757,8 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
}
case X86_VENDOR_CENTAUR:
mce_centaur_feature_init(c);
+   mce_intel_feature_init(c);
+   mce_adjust_timer = cmci_intel_adjust_timer;
break;
 
default:
-- 
1.9.1



[PATCH v3 2/2] x86/mce: add CMCI support for Centaur CPUs

2018-04-25 Thread David Wang
Newer Centaur support CMCI mechnism, which is compatible with INTEL CMCI.

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 38ccab8..f9a7295 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1757,6 +1757,8 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
}
case X86_VENDOR_CENTAUR:
mce_centaur_feature_init(c);
+   mce_intel_feature_init(c);
+   mce_adjust_timer = cmci_intel_adjust_timer;
break;
 
default:
-- 
1.9.1



[PATCH v3 0/2] MCA support for Centaur CPUs

2018-04-25 Thread David Wang
This patch set is to provide MCA support for new Centaur CPU.

The first patch is used to tell the kernel that newer Centaur
CPU support MCE broadcasting.

The second patch is used to tell the kernel that newer Centaur
CPU support CMCI.

Changes from v2 to v3:
* move mca_cfg.monarch_timeout init from __mcheck_cpu_apply_quirks to
mce_centaur_feature_init according to request from Boris.

Changes from v1 to v2:
* Capatilize 'Centaur' in the comments

David Wang (2):
  x86/mce: new Centaur CPU support MCE broadcasting
  x86/mce: add CMCI support for Centaur CPUs

 arch/x86/kernel/cpu/mcheck/mce.c | 21 +
 1 file changed, 21 insertions(+)

-- 
1.9.1



[PATCH v3 0/2] MCA support for Centaur CPUs

2018-04-25 Thread David Wang
This patch set is to provide MCA support for new Centaur CPU.

The first patch is used to tell the kernel that newer Centaur
CPU support MCE broadcasting.

The second patch is used to tell the kernel that newer Centaur
CPU support CMCI.

Changes from v2 to v3:
* move mca_cfg.monarch_timeout init from __mcheck_cpu_apply_quirks to
mce_centaur_feature_init according to request from Boris.

Changes from v1 to v2:
* Capatilize 'Centaur' in the comments

David Wang (2):
  x86/mce: new Centaur CPU support MCE broadcasting
  x86/mce: add CMCI support for Centaur CPUs

 arch/x86/kernel/cpu/mcheck/mce.c | 21 +
 1 file changed, 21 insertions(+)

-- 
1.9.1



[PATCH v2] x86/centaur: report correct CPU/cache topology

2018-04-25 Thread David Wang
Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
but the functionality is unused so far.
The Centaur init code also misses to initialize x86_info::max_cores, so
the CPU topology can't be described correctly.

Initialize x86_cpuinfo:max_core and invoke init_intel_cacheinfo() to
make CPU and cache topology information avaliable and correct.

Signed-off-by: David Wang <davidw...@zhaoxin.com>

Changes from v1 to v2:
*1 replace centaur_num_cpu_cores with early_init_centaur_mc according to 
suggestions from tglx;
*2 call cpu_detect_cache_sizes when init_intel_cacheinfo returns 0. For
some very old Centaur CPUs can't support the mechanisms defined in init_
intel_cacheinfo.
 
---
 arch/x86/kernel/cpu/centaur.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 80d5110..367540b 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -96,8 +96,25 @@ enum {
EAMD3D  = 1<<20,
 };
 
+static void early_init_centaur_mc(struct cpuinfo_x86 *c)
+{
+#ifdef CONFIG_SMP
+   unsigned int eax, ebx, ecx, edx;
+
+   if (c->cpuid_level < 4)
+   return;
+
+   cpuid_count(4, 0, , , , );
+   if (eax & 0x1f)
+   c->x86_max_cores = (eax >> 26) + 1;
+   else
+   return;
+#endif
+}
+
 static void early_init_centaur(struct cpuinfo_x86 *c)
 {
+   early_init_centaur_mc(c);
switch (c->x86) {
 #ifdef CONFIG_X86_32
case 5:
@@ -146,6 +163,7 @@ static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 
*c)
 
 static void init_centaur(struct cpuinfo_x86 *c)
 {
+   unsigned int l2 = 0;
 #ifdef CONFIG_X86_32
char *name;
u32  fcr_set = 0;
@@ -161,6 +179,17 @@ static void init_centaur(struct cpuinfo_x86 *c)
 #endif
early_init_centaur(c);
 
+   l2 = init_intel_cacheinfo(c);
+
+   /* Detect legacy cache sizes if init_intel_cacheinfo did not */
+   if (l2 == 0) {
+   cpu_detect_cache_sizes(c);
+   }
+
+#ifdef CONFIG_X86_32
+   detect_ht(c);
+#endif
+
if (c->cpuid_level > 9) {
unsigned int eax = cpuid_eax(10);
 
-- 
1.9.1



[PATCH v2] x86/centaur: report correct CPU/cache topology

2018-04-25 Thread David Wang
Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
but the functionality is unused so far.
The Centaur init code also misses to initialize x86_info::max_cores, so
the CPU topology can't be described correctly.

Initialize x86_cpuinfo:max_core and invoke init_intel_cacheinfo() to
make CPU and cache topology information avaliable and correct.

Signed-off-by: David Wang 

Changes from v1 to v2:
*1 replace centaur_num_cpu_cores with early_init_centaur_mc according to 
suggestions from tglx;
*2 call cpu_detect_cache_sizes when init_intel_cacheinfo returns 0. For
some very old Centaur CPUs can't support the mechanisms defined in init_
intel_cacheinfo.
 
---
 arch/x86/kernel/cpu/centaur.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index 80d5110..367540b 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -96,8 +96,25 @@ enum {
EAMD3D  = 1<<20,
 };
 
+static void early_init_centaur_mc(struct cpuinfo_x86 *c)
+{
+#ifdef CONFIG_SMP
+   unsigned int eax, ebx, ecx, edx;
+
+   if (c->cpuid_level < 4)
+   return;
+
+   cpuid_count(4, 0, , , , );
+   if (eax & 0x1f)
+   c->x86_max_cores = (eax >> 26) + 1;
+   else
+   return;
+#endif
+}
+
 static void early_init_centaur(struct cpuinfo_x86 *c)
 {
+   early_init_centaur_mc(c);
switch (c->x86) {
 #ifdef CONFIG_X86_32
case 5:
@@ -146,6 +163,7 @@ static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 
*c)
 
 static void init_centaur(struct cpuinfo_x86 *c)
 {
+   unsigned int l2 = 0;
 #ifdef CONFIG_X86_32
char *name;
u32  fcr_set = 0;
@@ -161,6 +179,17 @@ static void init_centaur(struct cpuinfo_x86 *c)
 #endif
early_init_centaur(c);
 
+   l2 = init_intel_cacheinfo(c);
+
+   /* Detect legacy cache sizes if init_intel_cacheinfo did not */
+   if (l2 == 0) {
+   cpu_detect_cache_sizes(c);
+   }
+
+#ifdef CONFIG_X86_32
+   detect_ht(c);
+#endif
+
if (c->cpuid_level > 9) {
unsigned int eax = cpuid_eax(10);
 
-- 
1.9.1



Re: [PATCH] x86/centaur: report correct CPU/cache topology

2018-04-25 Thread David Wang


> -Original Mail-
>Sender: Thomas Gleixner [mailto:t...@linutronix.de]
> Time: 2018年4月17日 18:16
> Receiver: David Wang <davidw...@zhaoxin.com>
> CC: mi...@redhat.com; h...@zytor.com; mi...@kernel.org;
> x...@kernel.org; linux-kernel@vger.kernel.org; brucechang@via-
> alliance.com; cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> Subject: Re: [PATCH] x86/centaur: report correct CPU/cache topology
> 
> On Wed, 4 Apr 2018, David Wang wrote:
> 
> > This patch is used to support multi-core Centaur CPU. After using this
> > patch, we can get correct CPU topology and correct cache topology.
> 
> David. This changelog is pretty useless. First of all, please do not use
'This
> patch ..'. We all know already that this is a patch.
> Documentation/process/submitting-patches.rst has a good explanation
> about writing changelogs.
> 
> The changelog should explain why it does something. Let me give you an
> example:
> 
>   Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
>   but the functionality is unused so far. The Centaur init code also
misses
>   to initialize x86_cpuinfo::max_cores so the CPU topology cannot be
>   desribed correctly,
> 
>   Initialize x86_cpuinfo::max_cores and invoke init_intel_cacheinfo() to
>   make CPU and cache topology information available and correct.
> 
> See? I'm neither using 'this patch' nor 'We/I' as I'm not impersonatimg
the
> code. It's all factual instead.

OK. I got it.

> > Signed-off-by: David Wang <davidw...@zhaoxin.com>
> > ---
> >  arch/x86/kernel/cpu/centaur.c | 20 
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/centaur.c
> > b/arch/x86/kernel/cpu/centaur.c index e5ec0f1..713e4db 100644
> > --- a/arch/x86/kernel/cpu/centaur.c
> > +++ b/arch/x86/kernel/cpu/centaur.c
> > @@ -112,6 +112,19 @@ static void early_init_centaur(struct cpuinfo_x86
> *c)
> > }
> >  }
> >
> > +static int centaur_num_cpu_cores(struct cpuinfo_x86 *c) {
> > +   unsigned int eax, ebx, ecx, edx;
> > +
> > +   if (c->cpuid_level < 4)
> > +   return 1;
> > +   cpuid_count(4, 0, , , , );
> > +   if (eax & 0x1f)
> > +   return (eax >> 26) + 1;
> > +   else
> > +   return 1;
> 
> This is a bad copy of intel_num_cpu_cores(). See for the subtle
difference.
> Please rename the intel function and move it to common.c
> 
OK. I will adjust.

> >  static void init_centaur(struct cpuinfo_x86 *c)  {  #ifdef
> > CONFIG_X86_32 @@ -128,6 +141,13 @@ static void init_centaur(struct
> > cpuinfo_x86 *c)
> > clear_cpu_cap(c, 0*32+31);
> >  #endif
> > early_init_centaur(c);
> > +
> > +   init_intel_cacheinfo(c);
> > +   c->x86_max_cores = centaur_num_cpu_cores(c); #ifdef
> CONFIG_X86_32
> > +   detect_ht(c);
> > +#endif
> 
> Can you please create a stub inline of detect_ht() for the !32bit case and
get
> rid of these #ifdefs in the code. That wants to be a separate patch which
also
> cleans up the existing call sites.

The detect_ht() function will also be called by identify_cpu()
function for
!32bit case. So, I think it means that all 64-bit CPUs can use
detect_ht(),
but only some 32-bit CPUs can use detect_ht().
Please correct me, if I'm wrong.
> 
> Thanks,
> 
>   tglx

Thanks,

---
David





Re: [PATCH] x86/centaur: report correct CPU/cache topology

2018-04-25 Thread David Wang


> -Original Mail-
>Sender: Thomas Gleixner [mailto:t...@linutronix.de]
> Time: 2018年4月17日 18:16
> Receiver: David Wang 
> CC: mi...@redhat.com; h...@zytor.com; mi...@kernel.org;
> x...@kernel.org; linux-kernel@vger.kernel.org; brucechang@via-
> alliance.com; cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> Subject: Re: [PATCH] x86/centaur: report correct CPU/cache topology
> 
> On Wed, 4 Apr 2018, David Wang wrote:
> 
> > This patch is used to support multi-core Centaur CPU. After using this
> > patch, we can get correct CPU topology and correct cache topology.
> 
> David. This changelog is pretty useless. First of all, please do not use
'This
> patch ..'. We all know already that this is a patch.
> Documentation/process/submitting-patches.rst has a good explanation
> about writing changelogs.
> 
> The changelog should explain why it does something. Let me give you an
> example:
> 
>   Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
>   but the functionality is unused so far. The Centaur init code also
misses
>   to initialize x86_cpuinfo::max_cores so the CPU topology cannot be
>   desribed correctly,
> 
>   Initialize x86_cpuinfo::max_cores and invoke init_intel_cacheinfo() to
>   make CPU and cache topology information available and correct.
> 
> See? I'm neither using 'this patch' nor 'We/I' as I'm not impersonatimg
the
> code. It's all factual instead.

OK. I got it.

> > Signed-off-by: David Wang 
> > ---
> >  arch/x86/kernel/cpu/centaur.c | 20 
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/centaur.c
> > b/arch/x86/kernel/cpu/centaur.c index e5ec0f1..713e4db 100644
> > --- a/arch/x86/kernel/cpu/centaur.c
> > +++ b/arch/x86/kernel/cpu/centaur.c
> > @@ -112,6 +112,19 @@ static void early_init_centaur(struct cpuinfo_x86
> *c)
> > }
> >  }
> >
> > +static int centaur_num_cpu_cores(struct cpuinfo_x86 *c) {
> > +   unsigned int eax, ebx, ecx, edx;
> > +
> > +   if (c->cpuid_level < 4)
> > +   return 1;
> > +   cpuid_count(4, 0, , , , );
> > +   if (eax & 0x1f)
> > +   return (eax >> 26) + 1;
> > +   else
> > +   return 1;
> 
> This is a bad copy of intel_num_cpu_cores(). See for the subtle
difference.
> Please rename the intel function and move it to common.c
> 
OK. I will adjust.

> >  static void init_centaur(struct cpuinfo_x86 *c)  {  #ifdef
> > CONFIG_X86_32 @@ -128,6 +141,13 @@ static void init_centaur(struct
> > cpuinfo_x86 *c)
> > clear_cpu_cap(c, 0*32+31);
> >  #endif
> > early_init_centaur(c);
> > +
> > +   init_intel_cacheinfo(c);
> > +   c->x86_max_cores = centaur_num_cpu_cores(c); #ifdef
> CONFIG_X86_32
> > +   detect_ht(c);
> > +#endif
> 
> Can you please create a stub inline of detect_ht() for the !32bit case and
get
> rid of these #ifdefs in the code. That wants to be a separate patch which
also
> cleans up the existing call sites.

The detect_ht() function will also be called by identify_cpu()
function for
!32bit case. So, I think it means that all 64-bit CPUs can use
detect_ht(),
but only some 32-bit CPUs can use detect_ht().
Please correct me, if I'm wrong.
> 
> Thanks,
> 
>   tglx

Thanks,

---
David





[tip:x86/cpu] x86/Centaur: Initialize supported CPU features properly

2018-04-20 Thread tip-bot for David Wang
Commit-ID:  60882cc159e1416fb1d17210de60d4a3ba04e613
Gitweb: https://git.kernel.org/tip/60882cc159e1416fb1d17210de60d4a3ba04e613
Author: David Wang <davidw...@zhaoxin.com>
AuthorDate: Fri, 20 Apr 2018 16:29:28 +0800
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: Fri, 20 Apr 2018 12:08:17 +0200

x86/Centaur: Initialize supported CPU features properly

Centaur CPUs have some Intel compatible capabilities,including Permformance
Monitoring Counters and CPU virtualization capabilities. Initialize them in
the Centaur specific init code.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: gre...@linuxfoundation.org
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: h...@zytor.com
Cc: benjamin...@viatech.com
Link: 
https://lkml.kernel.org/r/1524212968-28998-1-git-send-email-davidw...@zhaoxin.com

---
 arch/x86/kernel/cpu/centaur.c | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index e5ec0f11c0de..80d5110481ec 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -18,6 +18,13 @@
 #define RNG_ENABLED(1 << 3)
 #define RNG_ENABLE (1 << 6)/* MSR_VIA_RNG */
 
+#define X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW   0x0020
+#define X86_VMX_FEATURE_PROC_CTLS_VNMI 0x0040
+#define X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS 0x8000
+#define X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC   0x0001
+#define X86_VMX_FEATURE_PROC_CTLS2_EPT 0x0002
+#define X86_VMX_FEATURE_PROC_CTLS2_VPID0x0020
+
 static void init_c3(struct cpuinfo_x86 *c)
 {
u32  lo, hi;
@@ -112,6 +119,31 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
}
 }
 
+static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 *c)
+{
+   u32 vmx_msr_low, vmx_msr_high, msr_ctl, msr_ctl2;
+
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, vmx_msr_low, vmx_msr_high);
+   msr_ctl = vmx_msr_high | vmx_msr_low;
+
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW)
+   set_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_VNMI)
+   set_cpu_cap(c, X86_FEATURE_VNMI);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS) {
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2,
+ vmx_msr_low, vmx_msr_high);
+   msr_ctl2 = vmx_msr_high | vmx_msr_low;
+   if ((msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC) &&
+   (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW))
+   set_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_EPT)
+   set_cpu_cap(c, X86_FEATURE_EPT);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VPID)
+   set_cpu_cap(c, X86_FEATURE_VPID);
+   }
+}
+
 static void init_centaur(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_X86_32
@@ -128,6 +160,19 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+
+   if (c->cpuid_level > 9) {
+   unsigned int eax = cpuid_eax(10);
+
+   /*
+* Check for version and the number of counters
+* Version(eax[7:0]) can't be 0;
+* Counters(eax[15:8]) should be greater than 1;
+*/
+   if ((eax & 0xff) && (((eax >> 8) & 0xff) > 1))
+   set_cpu_cap(c, X86_FEATURE_ARCH_PERFMON);
+   }
+
switch (c->x86) {
 #ifdef CONFIG_X86_32
case 5:
@@ -199,6 +244,9 @@ static void init_centaur(struct cpuinfo_x86 *c)
 #ifdef CONFIG_X86_64
set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
 #endif
+
+   if (cpu_has(c, X86_FEATURE_VMX))
+   centaur_detect_vmx_virtcap(c);
 }
 
 #ifdef CONFIG_X86_32


[tip:x86/cpu] x86/Centaur: Initialize supported CPU features properly

2018-04-20 Thread tip-bot for David Wang
Commit-ID:  60882cc159e1416fb1d17210de60d4a3ba04e613
Gitweb: https://git.kernel.org/tip/60882cc159e1416fb1d17210de60d4a3ba04e613
Author: David Wang 
AuthorDate: Fri, 20 Apr 2018 16:29:28 +0800
Committer:  Thomas Gleixner 
CommitDate: Fri, 20 Apr 2018 12:08:17 +0200

x86/Centaur: Initialize supported CPU features properly

Centaur CPUs have some Intel compatible capabilities,including Permformance
Monitoring Counters and CPU virtualization capabilities. Initialize them in
the Centaur specific init code.

Signed-off-by: David Wang 
Signed-off-by: Thomas Gleixner 
Cc: luke...@viacpu.com
Cc: qiyuanw...@zhaoxin.com
Cc: gre...@linuxfoundation.org
Cc: brucech...@via-alliance.com
Cc: tim...@zhaoxin.com
Cc: cooper...@zhaoxin.com
Cc: h...@zytor.com
Cc: benjamin...@viatech.com
Link: 
https://lkml.kernel.org/r/1524212968-28998-1-git-send-email-davidw...@zhaoxin.com

---
 arch/x86/kernel/cpu/centaur.c | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index e5ec0f11c0de..80d5110481ec 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -18,6 +18,13 @@
 #define RNG_ENABLED(1 << 3)
 #define RNG_ENABLE (1 << 6)/* MSR_VIA_RNG */
 
+#define X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW   0x0020
+#define X86_VMX_FEATURE_PROC_CTLS_VNMI 0x0040
+#define X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS 0x8000
+#define X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC   0x0001
+#define X86_VMX_FEATURE_PROC_CTLS2_EPT 0x0002
+#define X86_VMX_FEATURE_PROC_CTLS2_VPID0x0020
+
 static void init_c3(struct cpuinfo_x86 *c)
 {
u32  lo, hi;
@@ -112,6 +119,31 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
}
 }
 
+static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 *c)
+{
+   u32 vmx_msr_low, vmx_msr_high, msr_ctl, msr_ctl2;
+
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, vmx_msr_low, vmx_msr_high);
+   msr_ctl = vmx_msr_high | vmx_msr_low;
+
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW)
+   set_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_VNMI)
+   set_cpu_cap(c, X86_FEATURE_VNMI);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS) {
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2,
+ vmx_msr_low, vmx_msr_high);
+   msr_ctl2 = vmx_msr_high | vmx_msr_low;
+   if ((msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC) &&
+   (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW))
+   set_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_EPT)
+   set_cpu_cap(c, X86_FEATURE_EPT);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VPID)
+   set_cpu_cap(c, X86_FEATURE_VPID);
+   }
+}
+
 static void init_centaur(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_X86_32
@@ -128,6 +160,19 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+
+   if (c->cpuid_level > 9) {
+   unsigned int eax = cpuid_eax(10);
+
+   /*
+* Check for version and the number of counters
+* Version(eax[7:0]) can't be 0;
+* Counters(eax[15:8]) should be greater than 1;
+*/
+   if ((eax & 0xff) && (((eax >> 8) & 0xff) > 1))
+   set_cpu_cap(c, X86_FEATURE_ARCH_PERFMON);
+   }
+
switch (c->x86) {
 #ifdef CONFIG_X86_32
case 5:
@@ -199,6 +244,9 @@ static void init_centaur(struct cpuinfo_x86 *c)
 #ifdef CONFIG_X86_64
set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
 #endif
+
+   if (cpu_has(c, X86_FEATURE_VMX))
+   centaur_detect_vmx_virtcap(c);
 }
 
 #ifdef CONFIG_X86_32


[PATCH v2] x86/Centaur: show more HW features in /proc/cpuinfo

2018-04-20 Thread David Wang
Centaur CPU has some intel compatible capabilities,include PMC and some
CPU virtualization capabilities. These capabilities should be initialized
in the centaur init function.

Signed-off-by: David Wang <davidw...@zhaoxin.com>

Changes from v1 to v2:
*1, move some defines outside the centaur_detect_vmx_virtcap;
*2, Delete some unuseful cap clear operaions in centaur_detect_vmx_virtcap;
*3, other little changes according to sugesstions from tglx;
---
 arch/x86/kernel/cpu/centaur.c | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index e5ec0f1..80d5110 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -18,6 +18,13 @@
 #define RNG_ENABLED(1 << 3)
 #define RNG_ENABLE (1 << 6)/* MSR_VIA_RNG */
 
+#define X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW   0x0020
+#define X86_VMX_FEATURE_PROC_CTLS_VNMI 0x0040
+#define X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS 0x8000
+#define X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC   0x0001
+#define X86_VMX_FEATURE_PROC_CTLS2_EPT 0x0002
+#define X86_VMX_FEATURE_PROC_CTLS2_VPID0x0020
+
 static void init_c3(struct cpuinfo_x86 *c)
 {
u32  lo, hi;
@@ -112,6 +119,31 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
}
 }
 
+static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 *c)
+{
+   u32 vmx_msr_low, vmx_msr_high, msr_ctl, msr_ctl2;
+
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, vmx_msr_low, vmx_msr_high);
+   msr_ctl = vmx_msr_high | vmx_msr_low;
+
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW)
+   set_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_VNMI)
+   set_cpu_cap(c, X86_FEATURE_VNMI);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS) {
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2,
+ vmx_msr_low, vmx_msr_high);
+   msr_ctl2 = vmx_msr_high | vmx_msr_low;
+   if ((msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC) &&
+   (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW))
+   set_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_EPT)
+   set_cpu_cap(c, X86_FEATURE_EPT);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VPID)
+   set_cpu_cap(c, X86_FEATURE_VPID);
+   }
+}
+
 static void init_centaur(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_X86_32
@@ -128,6 +160,19 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+
+   if (c->cpuid_level > 9) {
+   unsigned int eax = cpuid_eax(10);
+
+   /*
+* Check for version and the number of counters
+* Version(eax[7:0]) can't be 0;
+* Counters(eax[15:8]) should be greater than 1;
+*/
+   if ((eax & 0xff) && (((eax >> 8) & 0xff) > 1))
+   set_cpu_cap(c, X86_FEATURE_ARCH_PERFMON);
+   }
+
switch (c->x86) {
 #ifdef CONFIG_X86_32
case 5:
@@ -199,6 +244,9 @@ static void init_centaur(struct cpuinfo_x86 *c)
 #ifdef CONFIG_X86_64
set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
 #endif
+
+   if (cpu_has(c, X86_FEATURE_VMX))
+   centaur_detect_vmx_virtcap(c);
 }
 
 #ifdef CONFIG_X86_32
-- 
1.9.1



[PATCH v2] x86/Centaur: show more HW features in /proc/cpuinfo

2018-04-20 Thread David Wang
Centaur CPU has some intel compatible capabilities,include PMC and some
CPU virtualization capabilities. These capabilities should be initialized
in the centaur init function.

Signed-off-by: David Wang 

Changes from v1 to v2:
*1, move some defines outside the centaur_detect_vmx_virtcap;
*2, Delete some unuseful cap clear operaions in centaur_detect_vmx_virtcap;
*3, other little changes according to sugesstions from tglx;
---
 arch/x86/kernel/cpu/centaur.c | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index e5ec0f1..80d5110 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -18,6 +18,13 @@
 #define RNG_ENABLED(1 << 3)
 #define RNG_ENABLE (1 << 6)/* MSR_VIA_RNG */
 
+#define X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW   0x0020
+#define X86_VMX_FEATURE_PROC_CTLS_VNMI 0x0040
+#define X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS 0x8000
+#define X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC   0x0001
+#define X86_VMX_FEATURE_PROC_CTLS2_EPT 0x0002
+#define X86_VMX_FEATURE_PROC_CTLS2_VPID0x0020
+
 static void init_c3(struct cpuinfo_x86 *c)
 {
u32  lo, hi;
@@ -112,6 +119,31 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
}
 }
 
+static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 *c)
+{
+   u32 vmx_msr_low, vmx_msr_high, msr_ctl, msr_ctl2;
+
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, vmx_msr_low, vmx_msr_high);
+   msr_ctl = vmx_msr_high | vmx_msr_low;
+
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW)
+   set_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_VNMI)
+   set_cpu_cap(c, X86_FEATURE_VNMI);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS) {
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2,
+ vmx_msr_low, vmx_msr_high);
+   msr_ctl2 = vmx_msr_high | vmx_msr_low;
+   if ((msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC) &&
+   (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW))
+   set_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_EPT)
+   set_cpu_cap(c, X86_FEATURE_EPT);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VPID)
+   set_cpu_cap(c, X86_FEATURE_VPID);
+   }
+}
+
 static void init_centaur(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_X86_32
@@ -128,6 +160,19 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+
+   if (c->cpuid_level > 9) {
+   unsigned int eax = cpuid_eax(10);
+
+   /*
+* Check for version and the number of counters
+* Version(eax[7:0]) can't be 0;
+* Counters(eax[15:8]) should be greater than 1;
+*/
+   if ((eax & 0xff) && (((eax >> 8) & 0xff) > 1))
+   set_cpu_cap(c, X86_FEATURE_ARCH_PERFMON);
+   }
+
switch (c->x86) {
 #ifdef CONFIG_X86_32
case 5:
@@ -199,6 +244,9 @@ static void init_centaur(struct cpuinfo_x86 *c)
 #ifdef CONFIG_X86_64
set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
 #endif
+
+   if (cpu_has(c, X86_FEATURE_VMX))
+   centaur_detect_vmx_virtcap(c);
 }
 
 #ifdef CONFIG_X86_32
-- 
1.9.1



Re: [PATCH] x86/Centaur: show more HW features in /proc/cpuinfo

2018-04-18 Thread David Wang


> -Original Mail-
> Sender: Thomas Gleixner [mailto:t...@linutronix.de]
> Time: 2018/4/17 18:19
> Receiver: David Wang <davidw...@zhaoxin.com>
> CC: mi...@redhat.com; h...@zytor.com; mi...@kernel.org;
> gre...@linuxfoundation.org; x...@kernel.org; linux-
> ker...@vger.kernel.org; brucech...@via-alliance.com;
> cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> Subject: Re: [PATCH] x86/Centaur: show more HW features in /proc/cpuinfo
> 
> On Sun, 8 Apr 2018, David Wang wrote:
> 
> > We add this patch to show correct HW features(arch_perfmon,
> > tpr_shadow, vnmi, flexpriority, ept and vpid) when user execute "cat
> /proc/cpuinfo".
> 
> See the other mail vs. the changelog.
>

 
OK. Thanks.

> >
> > Signed-off-by: David Wang <davidw...@zhaoxin.com>
> > ---
> >  arch/x86/kernel/cpu/centaur.c | 49
> > +++
> >  1 file changed, 49 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/centaur.c
> > b/arch/x86/kernel/cpu/centaur.c index e5ec0f1..969fb8f 100644
> > --- a/arch/x86/kernel/cpu/centaur.c
> > +++ b/arch/x86/kernel/cpu/centaur.c
> > @@ -112,6 +112,44 @@ static void early_init_centaur(struct cpuinfo_x86
> *c)
> > }
> >  }
> >
> > +static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 *c) {
> > +#define X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW   0x0020
> > +#define X86_VMX_FEATURE_PROC_CTLS_VNMI 0x0040
> > +#define X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS 0x8000
> > +#define X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC   0x0001
> > +#define X86_VMX_FEATURE_PROC_CTLS2_EPT 0x0002
> > +#define X86_VMX_FEATURE_PROC_CTLS2_VPID0x0020
> 
> Please move the defines outside the function. This is horrible to read,

OK.

> 
> > +
> > +   u32 vmx_msr_low, vmx_msr_high, msr_ctl, msr_ctl2;
> > +
> > +   clear_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
> > +   clear_cpu_cap(c, X86_FEATURE_VNMI);
> > +   clear_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
> > +   clear_cpu_cap(c, X86_FEATURE_EPT);
> > +   clear_cpu_cap(c, X86_FEATURE_VPID);
> 
> Why are you clearing the capabilities? They are cleared at boot time.
> 

OK. It's really useless. 

> > +   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, vmx_msr_low,
> vmx_msr_high);
> > +   msr_ctl = vmx_msr_high | vmx_msr_low;
> > +
> > +   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW)
> > +   set_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
> > +   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_VNMI)
> > +   set_cpu_cap(c, X86_FEATURE_VNMI);
> > +   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS) {
> > +   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2,
> > + vmx_msr_low, vmx_msr_high);
> > +   msr_ctl2 = vmx_msr_high | vmx_msr_low;
> > +   if ((msr_ctl2 &
> X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC) &&
> > +   (msr_ctl &
> X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW))
> > +   set_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
> > +   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_EPT)
> > +   set_cpu_cap(c, X86_FEATURE_EPT);
> > +   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VPID)
> > +   set_cpu_cap(c, X86_FEATURE_VPID);
> > +   }
> > +}
> > +
> >  static void init_centaur(struct cpuinfo_x86 *c)  {  #ifdef
> > CONFIG_X86_32 @@ -128,6 +166,14 @@ static void init_centaur(struct
> > cpuinfo_x86 *c)
> > clear_cpu_cap(c, 0*32+31);
> >  #endif
> > early_init_centaur(c);
> > +
> > +   if (c->cpuid_level > 9) {
> > +   unsigned eax = cpuid_eax(10);
> 
> Missing newline between variable declaration and code. checkpatch.pl
> should have told you that.
> 

OK. 

> > +   /* Check for version and the number of counters */
> > +   if ((eax & 0xff) && (((eax >> 8) & 0xff) > 1))
> 
> Magic constants and a comment which does not explain how the check
> works.
> 

OK. I will explain more detail in the comments.

> > +   set_cpu_cap(c, X86_FEATURE_ARCH_PERFMON);
> 
> Thanks,
> 
>   tglx

Thanks,

---
David





Re: [PATCH] x86/Centaur: show more HW features in /proc/cpuinfo

2018-04-18 Thread David Wang


> -Original Mail-
> Sender: Thomas Gleixner [mailto:t...@linutronix.de]
> Time: 2018/4/17 18:19
> Receiver: David Wang 
> CC: mi...@redhat.com; h...@zytor.com; mi...@kernel.org;
> gre...@linuxfoundation.org; x...@kernel.org; linux-
> ker...@vger.kernel.org; brucech...@via-alliance.com;
> cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> Subject: Re: [PATCH] x86/Centaur: show more HW features in /proc/cpuinfo
> 
> On Sun, 8 Apr 2018, David Wang wrote:
> 
> > We add this patch to show correct HW features(arch_perfmon,
> > tpr_shadow, vnmi, flexpriority, ept and vpid) when user execute "cat
> /proc/cpuinfo".
> 
> See the other mail vs. the changelog.
>

 
OK. Thanks.

> >
> > Signed-off-by: David Wang 
> > ---
> >  arch/x86/kernel/cpu/centaur.c | 49
> > +++
> >  1 file changed, 49 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/centaur.c
> > b/arch/x86/kernel/cpu/centaur.c index e5ec0f1..969fb8f 100644
> > --- a/arch/x86/kernel/cpu/centaur.c
> > +++ b/arch/x86/kernel/cpu/centaur.c
> > @@ -112,6 +112,44 @@ static void early_init_centaur(struct cpuinfo_x86
> *c)
> > }
> >  }
> >
> > +static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 *c) {
> > +#define X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW   0x0020
> > +#define X86_VMX_FEATURE_PROC_CTLS_VNMI 0x0040
> > +#define X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS 0x8000
> > +#define X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC   0x0001
> > +#define X86_VMX_FEATURE_PROC_CTLS2_EPT 0x0002
> > +#define X86_VMX_FEATURE_PROC_CTLS2_VPID0x0020
> 
> Please move the defines outside the function. This is horrible to read,

OK.

> 
> > +
> > +   u32 vmx_msr_low, vmx_msr_high, msr_ctl, msr_ctl2;
> > +
> > +   clear_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
> > +   clear_cpu_cap(c, X86_FEATURE_VNMI);
> > +   clear_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
> > +   clear_cpu_cap(c, X86_FEATURE_EPT);
> > +   clear_cpu_cap(c, X86_FEATURE_VPID);
> 
> Why are you clearing the capabilities? They are cleared at boot time.
> 

OK. It's really useless. 

> > +   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, vmx_msr_low,
> vmx_msr_high);
> > +   msr_ctl = vmx_msr_high | vmx_msr_low;
> > +
> > +   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW)
> > +   set_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
> > +   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_VNMI)
> > +   set_cpu_cap(c, X86_FEATURE_VNMI);
> > +   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS) {
> > +   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2,
> > + vmx_msr_low, vmx_msr_high);
> > +   msr_ctl2 = vmx_msr_high | vmx_msr_low;
> > +   if ((msr_ctl2 &
> X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC) &&
> > +   (msr_ctl &
> X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW))
> > +   set_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
> > +   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_EPT)
> > +   set_cpu_cap(c, X86_FEATURE_EPT);
> > +   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VPID)
> > +   set_cpu_cap(c, X86_FEATURE_VPID);
> > +   }
> > +}
> > +
> >  static void init_centaur(struct cpuinfo_x86 *c)  {  #ifdef
> > CONFIG_X86_32 @@ -128,6 +166,14 @@ static void init_centaur(struct
> > cpuinfo_x86 *c)
> > clear_cpu_cap(c, 0*32+31);
> >  #endif
> > early_init_centaur(c);
> > +
> > +   if (c->cpuid_level > 9) {
> > +   unsigned eax = cpuid_eax(10);
> 
> Missing newline between variable declaration and code. checkpatch.pl
> should have told you that.
> 

OK. 

> > +   /* Check for version and the number of counters */
> > +   if ((eax & 0xff) && (((eax >> 8) & 0xff) > 1))
> 
> Magic constants and a comment which does not explain how the check
> works.
> 

OK. I will explain more detail in the comments.

> > +   set_cpu_cap(c, X86_FEATURE_ARCH_PERFMON);
> 
> Thanks,
> 
>   tglx

Thanks,

---
David





Re: [PATCH] x86/centaur: report correct CPU/cache topology

2018-04-18 Thread David Wang


> -Original Mail-
> Sender: Thomas Gleixner [mailto:t...@linutronix.de]
> Time : 2018/4/17 18:16
> Receiver: David Wang <davidw...@zhaoxin.com>
> CC: mi...@redhat.com; h...@zytor.com; mi...@kernel.org;
> x...@kernel.org; linux-kernel@vger.kernel.org; brucechang@via-
> alliance.com; cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> Subject: Re: [PATCH] x86/centaur: report correct CPU/cache topology
> 
> On Wed, 4 Apr 2018, David Wang wrote:
> 
> > This patch is used to support multi-core Centaur CPU. After using this
> > patch, we can get correct CPU topology and correct cache topology.
> 
> David. This changelog is pretty useless. First of all, please do not use
'This
> patch ..'. We all know already that this is a patch.
> Documentation/process/submitting-patches.rst has a good explanation
> about writing changelogs.
> 
> The changelog should explain why it does something. Let me give you an
> example:
> 
>   Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
>   but the functionality is unused so far. The Centaur init code also
misses
>   to initialize x86_cpuinfo::max_cores so the CPU topology cannot be
>   desribed correctly,
> 
>   Initialize x86_cpuinfo::max_cores and invoke init_intel_cacheinfo() to
>   make CPU and cache topology information available and correct.
> 
> See? I'm neither using 'this patch' nor 'We/I' as I'm not impersonatimg
the
> code. It's all factual instead.
> > Signed-off-by: David Wang <davidw...@zhaoxin.com>
> > ---
> >  arch/x86/kernel/cpu/centaur.c | 20 
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/centaur.c
> > b/arch/x86/kernel/cpu/centaur.c index e5ec0f1..713e4db 100644
> > --- a/arch/x86/kernel/cpu/centaur.c
> > +++ b/arch/x86/kernel/cpu/centaur.c
> > @@ -112,6 +112,19 @@ static void early_init_centaur(struct cpuinfo_x86
> *c)
> > }
> >  }
> >
> > +static int centaur_num_cpu_cores(struct cpuinfo_x86 *c) {
> > +   unsigned int eax, ebx, ecx, edx;
> > +
> > +   if (c->cpuid_level < 4)
> > +   return 1;
> > +   cpuid_count(4, 0, , , , );
> > +   if (eax & 0x1f)
> > +   return (eax >> 26) + 1;
> > +   else
> > +   return 1;
> 
> This is a bad copy of intel_num_cpu_cores(). See for the subtle
difference.
> Please rename the intel function and move it to common.c
> 
> >  static void init_centaur(struct cpuinfo_x86 *c)  {  #ifdef
> > CONFIG_X86_32 @@ -128,6 +141,13 @@ static void init_centaur(struct
> > cpuinfo_x86 *c)
> > clear_cpu_cap(c, 0*32+31);
> >  #endif
> > early_init_centaur(c);
> > +
> > +   init_intel_cacheinfo(c);
> > +   c->x86_max_cores = centaur_num_cpu_cores(c); #ifdef
> CONFIG_X86_32
> > +   detect_ht(c);
> > +#endif
> 
> Can you please create a stub inline of detect_ht() for the !32bit case and
get
> rid of these #ifdefs in the code. That wants to be a separate patch which
also
> cleans up the existing call sites.
> 
> Thanks,
> 
>   tglx

I will send patch v2 to solve all problems you listed.
Thanks,
---
David





Re: [PATCH] x86/centaur: report correct CPU/cache topology

2018-04-18 Thread David Wang


> -Original Mail-
> Sender: Thomas Gleixner [mailto:t...@linutronix.de]
> Time : 2018/4/17 18:16
> Receiver: David Wang 
> CC: mi...@redhat.com; h...@zytor.com; mi...@kernel.org;
> x...@kernel.org; linux-kernel@vger.kernel.org; brucechang@via-
> alliance.com; cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> Subject: Re: [PATCH] x86/centaur: report correct CPU/cache topology
> 
> On Wed, 4 Apr 2018, David Wang wrote:
> 
> > This patch is used to support multi-core Centaur CPU. After using this
> > patch, we can get correct CPU topology and correct cache topology.
> 
> David. This changelog is pretty useless. First of all, please do not use
'This
> patch ..'. We all know already that this is a patch.
> Documentation/process/submitting-patches.rst has a good explanation
> about writing changelogs.
> 
> The changelog should explain why it does something. Let me give you an
> example:
> 
>   Centaur CPUs enumerate the cache topology in the same way as Intel CPUs,
>   but the functionality is unused so far. The Centaur init code also
misses
>   to initialize x86_cpuinfo::max_cores so the CPU topology cannot be
>   desribed correctly,
> 
>   Initialize x86_cpuinfo::max_cores and invoke init_intel_cacheinfo() to
>   make CPU and cache topology information available and correct.
> 
> See? I'm neither using 'this patch' nor 'We/I' as I'm not impersonatimg
the
> code. It's all factual instead.
> > Signed-off-by: David Wang 
> > ---
> >  arch/x86/kernel/cpu/centaur.c | 20 
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/centaur.c
> > b/arch/x86/kernel/cpu/centaur.c index e5ec0f1..713e4db 100644
> > --- a/arch/x86/kernel/cpu/centaur.c
> > +++ b/arch/x86/kernel/cpu/centaur.c
> > @@ -112,6 +112,19 @@ static void early_init_centaur(struct cpuinfo_x86
> *c)
> > }
> >  }
> >
> > +static int centaur_num_cpu_cores(struct cpuinfo_x86 *c) {
> > +   unsigned int eax, ebx, ecx, edx;
> > +
> > +   if (c->cpuid_level < 4)
> > +   return 1;
> > +   cpuid_count(4, 0, , , , );
> > +   if (eax & 0x1f)
> > +   return (eax >> 26) + 1;
> > +   else
> > +   return 1;
> 
> This is a bad copy of intel_num_cpu_cores(). See for the subtle
difference.
> Please rename the intel function and move it to common.c
> 
> >  static void init_centaur(struct cpuinfo_x86 *c)  {  #ifdef
> > CONFIG_X86_32 @@ -128,6 +141,13 @@ static void init_centaur(struct
> > cpuinfo_x86 *c)
> > clear_cpu_cap(c, 0*32+31);
> >  #endif
> > early_init_centaur(c);
> > +
> > +   init_intel_cacheinfo(c);
> > +   c->x86_max_cores = centaur_num_cpu_cores(c); #ifdef
> CONFIG_X86_32
> > +   detect_ht(c);
> > +#endif
> 
> Can you please create a stub inline of detect_ht() for the !32bit case and
get
> rid of these #ifdefs in the code. That wants to be a separate patch which
also
> cleans up the existing call sites.
> 
> Thanks,
> 
>   tglx

I will send patch v2 to solve all problems you listed.
Thanks,
---
David





Re: [PATCH v2 1/2] x86/mce: new Centaur CPUs support MCE broadcasting

2018-04-17 Thread David Wang


> -邮件原件-
> 发件人: Borislav Petkov [mailto:b...@alien8.de]
> 发送时间: 2018年4月16日 21:28
> 收件人: David Wang <davidw...@zhaoxin.com>
> 抄送: tony.l...@intel.com; t...@linutronix.de; mi...@redhat.com;
> h...@zytor.com; x...@kernel.org; linux-e...@vger.kernel.org; linux-
> ker...@vger.kernel.org; brucech...@via-alliance.com;
> cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> 主题: Re: [PATCH v2 1/2] x86/mce: new Centaur CPUs support MCE
> broadcasting
> 
> On Mon, Apr 02, 2018 at 11:33:51AM +0800, David Wang wrote:
> > This patch is used to tell the kernel that newer Centaur CPU support
> 
> Avoid writing "This patch" in the commit message of a patch. It is
> tautologically useless.

> 
> > MCE broadcasting.
> >
> > Signed-off-by: David Wang <davidw...@zhaoxin.com>
> > ---
> >  arch/x86/kernel/cpu/mcheck/mce.c | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> > b/arch/x86/kernel/cpu/mcheck/mce.c
> > index 7065846..c3db7ce 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> > @@ -1688,6 +1688,17 @@ static int __mcheck_cpu_apply_quirks(struct
> > cpuinfo_x86 *c)
> 
> This code doesn't belong in the "apply_quirks" function but in
> __mcheck_cpu_init_vendor(). Just add a X86_VENDOR_CENTAUR case
> there.
> 
> I know, I know, there's a similar Intel piece which does the same thing but 
> all
> that quirks code should go to the vendor-specific init functions and the 
> quirks
> function be deleted. One day when I get bored...
> 
> > if (c->x86 == 6 && c->x86_model == 45)
> > quirk_no_way_out = quirk_sandybridge_ifu;
> > }
> > +
> > +   if (c->x86_vendor == X86_VENDOR_CENTAUR) {
> > +   /*
> > +* All newer Centaur CPUs support MCE broadcasting. Enable
> > +* synchronization with a one second timeout.
> > +*/
> > +   if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf &&
> > +c->x86_mask >=0xe)) &&
> 
> arch/x86/kernel/cpu/mcheck/mce.c: In function
> ‘__mcheck_cpu_apply_quirks’:
> arch/x86/kernel/cpu/mcheck/mce.c:1688:64: error: ‘struct cpuinfo_x86’ has
> no member named ‘x86_mask’; did you mean ‘x86_model’?
>if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf && c->x86_mask
> >=0xe)) &&
> ^~~~
> x86_model
> 
> and no, it needs to be x86_stepping.
> 
> Also,
> 
> ERROR: spaces required around that '>=' (ctx:WxV)
> #40: FILE: arch/x86/kernel/cpu/mcheck/mce.c:1697:
> +   if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf
> + && c->x86_mask >=0xe)) &&
>   
> ^
> 
> Please integrate scripts/checkpatch.pl into your patch creation workflow.
> Some of the warnings/errors *actually* make sense.
> 
> Thx.
> 
> --
> Regards/Gruss,
> Boris.
> 
> Good mailing practices for 400: avoid top-posting and trim the reply.
I will send patch v3 to solve all questions you listed.
Thx.

---
David





Re: [PATCH v2 1/2] x86/mce: new Centaur CPUs support MCE broadcasting

2018-04-17 Thread David Wang


> -邮件原件-
> 发件人: Borislav Petkov [mailto:b...@alien8.de]
> 发送时间: 2018年4月16日 21:28
> 收件人: David Wang 
> 抄送: tony.l...@intel.com; t...@linutronix.de; mi...@redhat.com;
> h...@zytor.com; x...@kernel.org; linux-e...@vger.kernel.org; linux-
> ker...@vger.kernel.org; brucech...@via-alliance.com;
> cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> 主题: Re: [PATCH v2 1/2] x86/mce: new Centaur CPUs support MCE
> broadcasting
> 
> On Mon, Apr 02, 2018 at 11:33:51AM +0800, David Wang wrote:
> > This patch is used to tell the kernel that newer Centaur CPU support
> 
> Avoid writing "This patch" in the commit message of a patch. It is
> tautologically useless.

> 
> > MCE broadcasting.
> >
> > Signed-off-by: David Wang 
> > ---
> >  arch/x86/kernel/cpu/mcheck/mce.c | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> > b/arch/x86/kernel/cpu/mcheck/mce.c
> > index 7065846..c3db7ce 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> > @@ -1688,6 +1688,17 @@ static int __mcheck_cpu_apply_quirks(struct
> > cpuinfo_x86 *c)
> 
> This code doesn't belong in the "apply_quirks" function but in
> __mcheck_cpu_init_vendor(). Just add a X86_VENDOR_CENTAUR case
> there.
> 
> I know, I know, there's a similar Intel piece which does the same thing but 
> all
> that quirks code should go to the vendor-specific init functions and the 
> quirks
> function be deleted. One day when I get bored...
> 
> > if (c->x86 == 6 && c->x86_model == 45)
> > quirk_no_way_out = quirk_sandybridge_ifu;
> > }
> > +
> > +   if (c->x86_vendor == X86_VENDOR_CENTAUR) {
> > +   /*
> > +* All newer Centaur CPUs support MCE broadcasting. Enable
> > +* synchronization with a one second timeout.
> > +*/
> > +   if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf &&
> > +c->x86_mask >=0xe)) &&
> 
> arch/x86/kernel/cpu/mcheck/mce.c: In function
> ‘__mcheck_cpu_apply_quirks’:
> arch/x86/kernel/cpu/mcheck/mce.c:1688:64: error: ‘struct cpuinfo_x86’ has
> no member named ‘x86_mask’; did you mean ‘x86_model’?
>if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf && c->x86_mask
> >=0xe)) &&
> ^~~~
> x86_model
> 
> and no, it needs to be x86_stepping.
> 
> Also,
> 
> ERROR: spaces required around that '>=' (ctx:WxV)
> #40: FILE: arch/x86/kernel/cpu/mcheck/mce.c:1697:
> +   if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf
> + && c->x86_mask >=0xe)) &&
>   
> ^
> 
> Please integrate scripts/checkpatch.pl into your patch creation workflow.
> Some of the warnings/errors *actually* make sense.
> 
> Thx.
> 
> --
> Regards/Gruss,
> Boris.
> 
> Good mailing practices for 400: avoid top-posting and trim the reply.
I will send patch v3 to solve all questions you listed.
Thx.

---
David





Re: [PATCH] x86/dma-mapping: override via_no_dac for new VIA PCI bridges

2018-04-17 Thread David Wang


> -邮件原件-
> 发件人: Christoph Hellwig [mailto:h...@infradead.org]
> 发送时间: 2018年4月16日 20:34
> 收件人: David Wang <davidw...@zhaoxin.com>
> 抄送: t...@linutronix.de; mi...@redhat.com; h...@zytor.com;
> gre...@linuxfoundation.org; x...@kernel.org; linux-
> ker...@vger.kernel.org; brucech...@via-alliance.com;
> cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> 主题: Re: [PATCH] x86/dma-mapping: override via_no_dac for new VIA PCI
> bridges
> 
> On Mon, Apr 16, 2018 at 05:26:56PM +0800, David Wang wrote:
> > PCI bridges integrated in new VIA chipset/SoC have no DAC issue.
> > Enable DAC for the platforms with these chipset/SoC can improve DMA
> > performance about 20% when DRAM size > 4GB.
> >
> 
> So we get an exception to an exception?  Is there any way to figure out
the
> PCI IDs actually affected?
Yes.

Do you mean we should list the PCI IDs of the PCI bridges which have no DAC
issue?
There are lots of PCI bridges(PCIE root ports) in our new chipsets/SoCs. And
no DMA issues found. 
So, we only want to recognize the chipset/SoC by reading VID/DID of Bus 0,
Device 17, function 0.

Thx.
---
David





Re: [PATCH] x86/dma-mapping: override via_no_dac for new VIA PCI bridges

2018-04-17 Thread David Wang


> -邮件原件-
> 发件人: Christoph Hellwig [mailto:h...@infradead.org]
> 发送时间: 2018年4月16日 20:34
> 收件人: David Wang 
> 抄送: t...@linutronix.de; mi...@redhat.com; h...@zytor.com;
> gre...@linuxfoundation.org; x...@kernel.org; linux-
> ker...@vger.kernel.org; brucech...@via-alliance.com;
> cooper...@zhaoxin.com; qiyuanw...@zhaoxin.com;
> benjamin...@viatech.com; luke...@viacpu.com; tim...@zhaoxin.com
> 主题: Re: [PATCH] x86/dma-mapping: override via_no_dac for new VIA PCI
> bridges
> 
> On Mon, Apr 16, 2018 at 05:26:56PM +0800, David Wang wrote:
> > PCI bridges integrated in new VIA chipset/SoC have no DAC issue.
> > Enable DAC for the platforms with these chipset/SoC can improve DMA
> > performance about 20% when DRAM size > 4GB.
> >
> 
> So we get an exception to an exception?  Is there any way to figure out
the
> PCI IDs actually affected?
Yes.

Do you mean we should list the PCI IDs of the PCI bridges which have no DAC
issue?
There are lots of PCI bridges(PCIE root ports) in our new chipsets/SoCs. And
no DMA issues found. 
So, we only want to recognize the chipset/SoC by reading VID/DID of Bus 0,
Device 17, function 0.

Thx.
---
David





[PATCH] ALSA: hda - New VIA controller suppor no-snoop path

2018-04-16 Thread David Wang
This patch is used to tell kernel that new VIA HDAC controller also
support no-snoop path.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 sound/pci/hda/hda_intel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 96143df..439e8e9 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1640,7 +1640,7 @@ static void azx_check_snoop_available(struct azx *chip)
 */
u8 val;
pci_read_config_byte(chip->pci, 0x42, );
-   if (!(val & 0x80) && chip->pci->revision == 0x30)
+   if (!(val & 0x80) && (chip->pci->revision == 0x30 || 
chip->pci->revision == 0x20))
snoop = false;
}
 
-- 
1.9.1



[PATCH] ALSA: hda - New VIA controller suppor no-snoop path

2018-04-16 Thread David Wang
This patch is used to tell kernel that new VIA HDAC controller also
support no-snoop path.

Signed-off-by: David Wang 
---
 sound/pci/hda/hda_intel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 96143df..439e8e9 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1640,7 +1640,7 @@ static void azx_check_snoop_available(struct azx *chip)
 */
u8 val;
pci_read_config_byte(chip->pci, 0x42, );
-   if (!(val & 0x80) && chip->pci->revision == 0x30)
+   if (!(val & 0x80) && (chip->pci->revision == 0x30 || 
chip->pci->revision == 0x20))
snoop = false;
}
 
-- 
1.9.1



[PATCH] x86/dma-mapping: override via_no_dac for new VIA PCI bridges

2018-04-16 Thread David Wang
PCI bridges integrated in new VIA chipset/SoC have no DAC issue.
Enable DAC for the platforms with these chipset/SoC can improve DMA performance 
about
20% when DRAM size > 4GB.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 arch/x86/kernel/pci-dma.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index cb9c1fa..6e37b0e 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -47,6 +47,10 @@
 
 extern struct iommu_table_entry __iommu_table[], __iommu_table_end[];
 
+#ifdef CONFIG_PCI
+static int override_via_dac __read_mostly;
+#endif
+
 /* Dummy device used for NULL arguments (normally ISA). */
 struct device x86_dma_fallback_dev = {
.init_name = "fallback device",
@@ -279,6 +283,9 @@ static int __init pci_iommu_init(void)
 
 static void via_no_dac(struct pci_dev *dev)
 {
+   if (override_via_dac)
+   return;
+
if (forbid_dac == 0) {
dev_info(>dev, "disabling DAC on VIA PCI bridge\n");
forbid_dac = 1;
@@ -286,4 +293,19 @@ static void via_no_dac(struct pci_dev *dev)
 }
 DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
PCI_CLASS_BRIDGE_PCI, 8, via_no_dac);
+
+static void via_can_dac(struct pci_dev *dev)
+{
+   /*
+* New VIA bridges have no issues for DAC.
+* Disable the "via_no_dac" fixup code for these new VIA bridges.
+*/
+   override_via_dac = 1;
+}
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_VIA, 0x345B,
+   PCI_CLASS_BRIDGE_ISA, 8, via_can_dac);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_VIA, 0x1001,
+   PCI_CLASS_BRIDGE_ISA, 8, via_can_dac);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_VIA, 0x300A,
+   PCI_CLASS_BRIDGE_ISA, 8, via_can_dac);
 #endif
-- 
1.9.1



[PATCH] x86/dma-mapping: override via_no_dac for new VIA PCI bridges

2018-04-16 Thread David Wang
PCI bridges integrated in new VIA chipset/SoC have no DAC issue.
Enable DAC for the platforms with these chipset/SoC can improve DMA performance 
about
20% when DRAM size > 4GB.

Signed-off-by: David Wang 
---
 arch/x86/kernel/pci-dma.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index cb9c1fa..6e37b0e 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -47,6 +47,10 @@
 
 extern struct iommu_table_entry __iommu_table[], __iommu_table_end[];
 
+#ifdef CONFIG_PCI
+static int override_via_dac __read_mostly;
+#endif
+
 /* Dummy device used for NULL arguments (normally ISA). */
 struct device x86_dma_fallback_dev = {
.init_name = "fallback device",
@@ -279,6 +283,9 @@ static int __init pci_iommu_init(void)
 
 static void via_no_dac(struct pci_dev *dev)
 {
+   if (override_via_dac)
+   return;
+
if (forbid_dac == 0) {
dev_info(>dev, "disabling DAC on VIA PCI bridge\n");
forbid_dac = 1;
@@ -286,4 +293,19 @@ static void via_no_dac(struct pci_dev *dev)
 }
 DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
PCI_CLASS_BRIDGE_PCI, 8, via_no_dac);
+
+static void via_can_dac(struct pci_dev *dev)
+{
+   /*
+* New VIA bridges have no issues for DAC.
+* Disable the "via_no_dac" fixup code for these new VIA bridges.
+*/
+   override_via_dac = 1;
+}
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_VIA, 0x345B,
+   PCI_CLASS_BRIDGE_ISA, 8, via_can_dac);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_VIA, 0x1001,
+   PCI_CLASS_BRIDGE_ISA, 8, via_can_dac);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_VIA, 0x300A,
+   PCI_CLASS_BRIDGE_ISA, 8, via_can_dac);
 #endif
-- 
1.9.1



[PATCH] hwrng: via-rng - support new Centaur CPU

2018-04-13 Thread David Wang
New Centaur CPU(Family > 6) supprt Random Number Generator, but can't
support MSR_VIA_RNG. Just like VIA Nano.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 drivers/char/hw_random/via-rng.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index d1f5bb5..d9448b1 100644
--- a/drivers/char/hw_random/via-rng.c
+++ b/drivers/char/hw_random/via-rng.c
@@ -135,7 +135,7 @@ static int via_rng_init(struct hwrng *rng)
 * is always enabled if CPUID rng_en is set.  There is no
 * RNG configuration like it used to be the case in this
 * register */
-   if ((c->x86 == 6) && (c->x86_model >= 0x0f)) {
+   if (((c->x86 == 6) && (c->x86_model >= 0x0f))  || (c->x86 > 6)){
if (!boot_cpu_has(X86_FEATURE_XSTORE_EN)) {
pr_err(PFX "can't enable hardware RNG "
"if XSTORE is not enabled\n");
-- 
1.9.1



[PATCH] hwrng: via-rng - support new Centaur CPU

2018-04-13 Thread David Wang
New Centaur CPU(Family > 6) supprt Random Number Generator, but can't
support MSR_VIA_RNG. Just like VIA Nano.

Signed-off-by: David Wang 
---
 drivers/char/hw_random/via-rng.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hw_random/via-rng.c b/drivers/char/hw_random/via-rng.c
index d1f5bb5..d9448b1 100644
--- a/drivers/char/hw_random/via-rng.c
+++ b/drivers/char/hw_random/via-rng.c
@@ -135,7 +135,7 @@ static int via_rng_init(struct hwrng *rng)
 * is always enabled if CPUID rng_en is set.  There is no
 * RNG configuration like it used to be the case in this
 * register */
-   if ((c->x86 == 6) && (c->x86_model >= 0x0f)) {
+   if (((c->x86 == 6) && (c->x86_model >= 0x0f))  || (c->x86 > 6)){
if (!boot_cpu_has(X86_FEATURE_XSTORE_EN)) {
pr_err(PFX "can't enable hardware RNG "
"if XSTORE is not enabled\n");
-- 
1.9.1



Re: [PATCH] x86/Centaur: show more HW features in /proc/cpuinfo

2018-04-08 Thread David Wang
> -邮件原件-
> 发件人: David Wang [mailto:davidw...@zhaoxin.com]
> 发送时间: 2018年4月8日 17:36
> 收件人: t...@linutronix.de; mi...@redhat.com; h...@zytor.com;
> mi...@kernel.org; gre...@linuxfoundation.org; x...@kernel.org;
> linux-kernel@vger.kernel.org
> 抄送: brucech...@via-alliance.com; cooper...@zhaoxin.com;
> qiyuanw...@zhaoxin.com; benjamin...@viatech.com; luke...@viacpu.com;
> tim...@zhaoxin.com; David Wang <davidw...@zhaoxin.com>
> 主题: [PATCH] x86/Centaur: show more HW features in /proc/cpuinfo
> 
> We add this patch to show correct HW features(arch_perfmon, tpr_shadow,
> vnmi, flexpriority, ept and vpid) when user execute "cat /proc/cpuinfo".
> 
> Signed-off-by: David Wang <davidw...@zhaoxin.com>
> ---
>  arch/x86/kernel/cpu/centaur.c | 49
> +++
>  1 file changed, 49 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
> index e5ec0f1..969fb8f 100644
> --- a/arch/x86/kernel/cpu/centaur.c
> +++ b/arch/x86/kernel/cpu/centaur.c
> @@ -112,6 +112,44 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
>   }
>  }
> 
> +static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 *c) {
> +#define X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW 0x0020
> +#define X86_VMX_FEATURE_PROC_CTLS_VNMI   0x0040
> +#define X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS   0x8000
> +#define X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC 0x0001
> +#define X86_VMX_FEATURE_PROC_CTLS2_EPT   0x0002
> +#define X86_VMX_FEATURE_PROC_CTLS2_VPID  0x0020
> +
> + u32 vmx_msr_low, vmx_msr_high, msr_ctl, msr_ctl2;
> +
> + clear_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
> + clear_cpu_cap(c, X86_FEATURE_VNMI);
> + clear_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
> + clear_cpu_cap(c, X86_FEATURE_EPT);
> + clear_cpu_cap(c, X86_FEATURE_VPID);
> +
> + rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, vmx_msr_low, vmx_msr_high);
> + msr_ctl = vmx_msr_high | vmx_msr_low;
> +
> + if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW)
> + set_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
> + if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_VNMI)
> + set_cpu_cap(c, X86_FEATURE_VNMI);
> + if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS) {
> + rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2,
> +   vmx_msr_low, vmx_msr_high);
> + msr_ctl2 = vmx_msr_high | vmx_msr_low;
> + if ((msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC) &&
> + (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW))
> + set_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
> + if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_EPT)
> + set_cpu_cap(c, X86_FEATURE_EPT);
> + if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VPID)
> + set_cpu_cap(c, X86_FEATURE_VPID);
> + }
> +}
> +
>  static void init_centaur(struct cpuinfo_x86 *c)  {  #ifdef CONFIG_X86_32
> @@ -128,6 +166,14 @@ static void init_centaur(struct cpuinfo_x86 *c)
>   clear_cpu_cap(c, 0*32+31);
>  #endif
>   early_init_centaur(c);
> +
> + if (c->cpuid_level > 9) {
> + unsigned eax = cpuid_eax(10);
> + /* Check for version and the number of counters */
> + if ((eax & 0xff) && (((eax >> 8) & 0xff) > 1))
> + set_cpu_cap(c, X86_FEATURE_ARCH_PERFMON);
> + }
> +
>   switch (c->x86) {
>  #ifdef CONFIG_X86_32
>   case 5:
> @@ -199,6 +245,9 @@ static void init_centaur(struct cpuinfo_x86 *c)
#ifdef
> CONFIG_X86_64
>   set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);  #endif
> +
> + if (cpu_has(c, X86_FEATURE_VMX))
> + centaur_detect_vmx_virtcap(c);
>  }
> 
>  #ifdef CONFIG_X86_32
> --
> 1.9.1

Sorry to send to wrong email address.
---
David





Re: [PATCH] x86/Centaur: show more HW features in /proc/cpuinfo

2018-04-08 Thread David Wang
> -邮件原件-
> 发件人: David Wang [mailto:davidw...@zhaoxin.com]
> 发送时间: 2018年4月8日 17:36
> 收件人: t...@linutronix.de; mi...@redhat.com; h...@zytor.com;
> mi...@kernel.org; gre...@linuxfoundation.org; x...@kernel.org;
> linux-kernel@vger.kernel.org
> 抄送: brucech...@via-alliance.com; cooper...@zhaoxin.com;
> qiyuanw...@zhaoxin.com; benjamin...@viatech.com; luke...@viacpu.com;
> tim...@zhaoxin.com; David Wang 
> 主题: [PATCH] x86/Centaur: show more HW features in /proc/cpuinfo
> 
> We add this patch to show correct HW features(arch_perfmon, tpr_shadow,
> vnmi, flexpriority, ept and vpid) when user execute "cat /proc/cpuinfo".
> 
> Signed-off-by: David Wang 
> ---
>  arch/x86/kernel/cpu/centaur.c | 49
> +++
>  1 file changed, 49 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
> index e5ec0f1..969fb8f 100644
> --- a/arch/x86/kernel/cpu/centaur.c
> +++ b/arch/x86/kernel/cpu/centaur.c
> @@ -112,6 +112,44 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
>   }
>  }
> 
> +static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 *c) {
> +#define X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW 0x0020
> +#define X86_VMX_FEATURE_PROC_CTLS_VNMI   0x0040
> +#define X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS   0x8000
> +#define X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC 0x0001
> +#define X86_VMX_FEATURE_PROC_CTLS2_EPT   0x0002
> +#define X86_VMX_FEATURE_PROC_CTLS2_VPID  0x0020
> +
> + u32 vmx_msr_low, vmx_msr_high, msr_ctl, msr_ctl2;
> +
> + clear_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
> + clear_cpu_cap(c, X86_FEATURE_VNMI);
> + clear_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
> + clear_cpu_cap(c, X86_FEATURE_EPT);
> + clear_cpu_cap(c, X86_FEATURE_VPID);
> +
> + rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, vmx_msr_low, vmx_msr_high);
> + msr_ctl = vmx_msr_high | vmx_msr_low;
> +
> + if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW)
> + set_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
> + if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_VNMI)
> + set_cpu_cap(c, X86_FEATURE_VNMI);
> + if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS) {
> + rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2,
> +   vmx_msr_low, vmx_msr_high);
> + msr_ctl2 = vmx_msr_high | vmx_msr_low;
> + if ((msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC) &&
> + (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW))
> + set_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
> + if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_EPT)
> + set_cpu_cap(c, X86_FEATURE_EPT);
> + if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VPID)
> + set_cpu_cap(c, X86_FEATURE_VPID);
> + }
> +}
> +
>  static void init_centaur(struct cpuinfo_x86 *c)  {  #ifdef CONFIG_X86_32
> @@ -128,6 +166,14 @@ static void init_centaur(struct cpuinfo_x86 *c)
>   clear_cpu_cap(c, 0*32+31);
>  #endif
>   early_init_centaur(c);
> +
> + if (c->cpuid_level > 9) {
> + unsigned eax = cpuid_eax(10);
> + /* Check for version and the number of counters */
> + if ((eax & 0xff) && (((eax >> 8) & 0xff) > 1))
> + set_cpu_cap(c, X86_FEATURE_ARCH_PERFMON);
> + }
> +
>   switch (c->x86) {
>  #ifdef CONFIG_X86_32
>   case 5:
> @@ -199,6 +245,9 @@ static void init_centaur(struct cpuinfo_x86 *c)
#ifdef
> CONFIG_X86_64
>   set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);  #endif
> +
> + if (cpu_has(c, X86_FEATURE_VMX))
> + centaur_detect_vmx_virtcap(c);
>  }
> 
>  #ifdef CONFIG_X86_32
> --
> 1.9.1

Sorry to send to wrong email address.
---
David





[PATCH] x86/Centaur: show more HW features in /proc/cpuinfo

2018-04-08 Thread David Wang
We add this patch to show correct HW features(arch_perfmon, tpr_shadow,
vnmi, flexpriority, ept and vpid) when user execute "cat /proc/cpuinfo".

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 arch/x86/kernel/cpu/centaur.c | 49 +++
 1 file changed, 49 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index e5ec0f1..969fb8f 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -112,6 +112,44 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
}
 }
 
+static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 *c)
+{
+#define X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW   0x0020
+#define X86_VMX_FEATURE_PROC_CTLS_VNMI 0x0040
+#define X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS 0x8000
+#define X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC   0x0001
+#define X86_VMX_FEATURE_PROC_CTLS2_EPT 0x0002
+#define X86_VMX_FEATURE_PROC_CTLS2_VPID0x0020
+
+   u32 vmx_msr_low, vmx_msr_high, msr_ctl, msr_ctl2;
+
+   clear_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
+   clear_cpu_cap(c, X86_FEATURE_VNMI);
+   clear_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
+   clear_cpu_cap(c, X86_FEATURE_EPT);
+   clear_cpu_cap(c, X86_FEATURE_VPID);
+
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, vmx_msr_low, vmx_msr_high);
+   msr_ctl = vmx_msr_high | vmx_msr_low;
+
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW)
+   set_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_VNMI)
+   set_cpu_cap(c, X86_FEATURE_VNMI);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS) {
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2,
+ vmx_msr_low, vmx_msr_high);
+   msr_ctl2 = vmx_msr_high | vmx_msr_low;
+   if ((msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC) &&
+   (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW))
+   set_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_EPT)
+   set_cpu_cap(c, X86_FEATURE_EPT);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VPID)
+   set_cpu_cap(c, X86_FEATURE_VPID);
+   }
+}
+
 static void init_centaur(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_X86_32
@@ -128,6 +166,14 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+
+   if (c->cpuid_level > 9) {
+   unsigned eax = cpuid_eax(10);
+   /* Check for version and the number of counters */
+   if ((eax & 0xff) && (((eax >> 8) & 0xff) > 1))
+   set_cpu_cap(c, X86_FEATURE_ARCH_PERFMON);
+   }
+
switch (c->x86) {
 #ifdef CONFIG_X86_32
case 5:
@@ -199,6 +245,9 @@ static void init_centaur(struct cpuinfo_x86 *c)
 #ifdef CONFIG_X86_64
set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
 #endif
+
+   if (cpu_has(c, X86_FEATURE_VMX))
+   centaur_detect_vmx_virtcap(c);
 }
 
 #ifdef CONFIG_X86_32
-- 
1.9.1



[PATCH] x86/Centaur: show more HW features in /proc/cpuinfo

2018-04-08 Thread David Wang
We add this patch to show correct HW features(arch_perfmon, tpr_shadow,
vnmi, flexpriority, ept and vpid) when user execute "cat /proc/cpuinfo".

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/centaur.c | 49 +++
 1 file changed, 49 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index e5ec0f1..969fb8f 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -112,6 +112,44 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
}
 }
 
+static void centaur_detect_vmx_virtcap(struct cpuinfo_x86 *c)
+{
+#define X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW   0x0020
+#define X86_VMX_FEATURE_PROC_CTLS_VNMI 0x0040
+#define X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS 0x8000
+#define X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC   0x0001
+#define X86_VMX_FEATURE_PROC_CTLS2_EPT 0x0002
+#define X86_VMX_FEATURE_PROC_CTLS2_VPID0x0020
+
+   u32 vmx_msr_low, vmx_msr_high, msr_ctl, msr_ctl2;
+
+   clear_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
+   clear_cpu_cap(c, X86_FEATURE_VNMI);
+   clear_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
+   clear_cpu_cap(c, X86_FEATURE_EPT);
+   clear_cpu_cap(c, X86_FEATURE_VPID);
+
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS, vmx_msr_low, vmx_msr_high);
+   msr_ctl = vmx_msr_high | vmx_msr_low;
+
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW)
+   set_cpu_cap(c, X86_FEATURE_TPR_SHADOW);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_VNMI)
+   set_cpu_cap(c, X86_FEATURE_VNMI);
+   if (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_2ND_CTLS) {
+   rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2,
+ vmx_msr_low, vmx_msr_high);
+   msr_ctl2 = vmx_msr_high | vmx_msr_low;
+   if ((msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VIRT_APIC) &&
+   (msr_ctl & X86_VMX_FEATURE_PROC_CTLS_TPR_SHADOW))
+   set_cpu_cap(c, X86_FEATURE_FLEXPRIORITY);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_EPT)
+   set_cpu_cap(c, X86_FEATURE_EPT);
+   if (msr_ctl2 & X86_VMX_FEATURE_PROC_CTLS2_VPID)
+   set_cpu_cap(c, X86_FEATURE_VPID);
+   }
+}
+
 static void init_centaur(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_X86_32
@@ -128,6 +166,14 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+
+   if (c->cpuid_level > 9) {
+   unsigned eax = cpuid_eax(10);
+   /* Check for version and the number of counters */
+   if ((eax & 0xff) && (((eax >> 8) & 0xff) > 1))
+   set_cpu_cap(c, X86_FEATURE_ARCH_PERFMON);
+   }
+
switch (c->x86) {
 #ifdef CONFIG_X86_32
case 5:
@@ -199,6 +245,9 @@ static void init_centaur(struct cpuinfo_x86 *c)
 #ifdef CONFIG_X86_64
set_cpu_cap(c, X86_FEATURE_LFENCE_RDTSC);
 #endif
+
+   if (cpu_has(c, X86_FEATURE_VMX))
+   centaur_detect_vmx_virtcap(c);
 }
 
 #ifdef CONFIG_X86_32
-- 
1.9.1



答复: 答复: [PATCH 1/2] x86/mce: new centaur CPUs support MCE broadcasting

2018-04-07 Thread David Wang
> -邮件原件-
> 发件人: Borislav Petkov [mailto:b...@alien8.de]
> 发送时间: 2018年4月4日 19:18
> 收件人: David Wang <davidw...@zhaoxin.com>
> 抄送: tony.l...@intel.com; t...@linutronix.de; mi...@redhat.com;
> h...@zytor.com; x...@kernel.org; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Bruce Chang (VAS)
> <brucech...@via-alliance.com>; Cooper Yan(BJ-RD)
> <cooper...@zhaoxin.com>; Qiyuan Wang(BJ-RD)
> <qiyuanw...@zhaoxin.com>; Benjamin Pan <benjamin...@viatech.com>;
> Luke Lin <luke...@viacpu.com>; Tim Guo(BJ-RD) <tim...@zhaoxin.com>
> 主题: Re: 答复: [PATCH 1/2] x86/mce: new centaur CPUs support MCE
> broadcasting
> 
> On Wed, Apr 04, 2018 at 02:34:52AM +, David Wang wrote:
> > Those are new processors and main usage of CentaurHauls CPUs in recent
> > years is for limited and/or embedded instead of distribution markets.
> > So there is no plan or resource to create such document for public
> > access. Is public spec mandatory for code check-in? We can provide
> > platforms for verification instead.
> 
> Nah, not needed. As long as the code paths don't break anything else and as
> long as we can CC you to fix bugs people report, we're good. :-)
> 
> Btw, please do not top-post on a public ML.

I got it.
Thanks.

---
David

> 
> Thx.
> 
> --
> Regards/Gruss,
> Boris.
> 
> Good mailing practices for 400: avoid top-posting and trim the reply.



答复: 答复: [PATCH 1/2] x86/mce: new centaur CPUs support MCE broadcasting

2018-04-07 Thread David Wang
> -邮件原件-
> 发件人: Borislav Petkov [mailto:b...@alien8.de]
> 发送时间: 2018年4月4日 19:18
> 收件人: David Wang 
> 抄送: tony.l...@intel.com; t...@linutronix.de; mi...@redhat.com;
> h...@zytor.com; x...@kernel.org; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Bruce Chang (VAS)
> ; Cooper Yan(BJ-RD)
> ; Qiyuan Wang(BJ-RD)
> ; Benjamin Pan ;
> Luke Lin ; Tim Guo(BJ-RD) 
> 主题: Re: 答复: [PATCH 1/2] x86/mce: new centaur CPUs support MCE
> broadcasting
> 
> On Wed, Apr 04, 2018 at 02:34:52AM +, David Wang wrote:
> > Those are new processors and main usage of CentaurHauls CPUs in recent
> > years is for limited and/or embedded instead of distribution markets.
> > So there is no plan or resource to create such document for public
> > access. Is public spec mandatory for code check-in? We can provide
> > platforms for verification instead.
> 
> Nah, not needed. As long as the code paths don't break anything else and as
> long as we can CC you to fix bugs people report, we're good. :-)
> 
> Btw, please do not top-post on a public ML.

I got it.
Thanks.

---
David

> 
> Thx.
> 
> --
> Regards/Gruss,
> Boris.
> 
> Good mailing practices for 400: avoid top-posting and trim the reply.



[PATCH] x86/centaur: report correct CPU/cache topology

2018-04-04 Thread David Wang
This patch is used to support multi-core Centaur CPU. After using this
patch, we can get correct CPU topology and correct cache topology.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 arch/x86/kernel/cpu/centaur.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index e5ec0f1..713e4db 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -112,6 +112,19 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
}
 }
 
+static int centaur_num_cpu_cores(struct cpuinfo_x86 *c)
+{
+   unsigned int eax, ebx, ecx, edx;
+
+   if (c->cpuid_level < 4)
+   return 1;
+   cpuid_count(4, 0, , , , );
+   if (eax & 0x1f)
+   return (eax >> 26) + 1;
+   else
+   return 1;
+}
+
 static void init_centaur(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_X86_32
@@ -128,6 +141,13 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+
+   init_intel_cacheinfo(c);
+   c->x86_max_cores = centaur_num_cpu_cores(c);
+#ifdef CONFIG_X86_32
+   detect_ht(c);
+#endif
+
switch (c->x86) {
 #ifdef CONFIG_X86_32
case 5:
-- 
1.9.1



[PATCH] x86/centaur: report correct CPU/cache topology

2018-04-04 Thread David Wang
This patch is used to support multi-core Centaur CPU. After using this
patch, we can get correct CPU topology and correct cache topology.

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/centaur.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/x86/kernel/cpu/centaur.c b/arch/x86/kernel/cpu/centaur.c
index e5ec0f1..713e4db 100644
--- a/arch/x86/kernel/cpu/centaur.c
+++ b/arch/x86/kernel/cpu/centaur.c
@@ -112,6 +112,19 @@ static void early_init_centaur(struct cpuinfo_x86 *c)
}
 }
 
+static int centaur_num_cpu_cores(struct cpuinfo_x86 *c)
+{
+   unsigned int eax, ebx, ecx, edx;
+
+   if (c->cpuid_level < 4)
+   return 1;
+   cpuid_count(4, 0, , , , );
+   if (eax & 0x1f)
+   return (eax >> 26) + 1;
+   else
+   return 1;
+}
+
 static void init_centaur(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_X86_32
@@ -128,6 +141,13 @@ static void init_centaur(struct cpuinfo_x86 *c)
clear_cpu_cap(c, 0*32+31);
 #endif
early_init_centaur(c);
+
+   init_intel_cacheinfo(c);
+   c->x86_max_cores = centaur_num_cpu_cores(c);
+#ifdef CONFIG_X86_32
+   detect_ht(c);
+#endif
+
switch (c->x86) {
 #ifdef CONFIG_X86_32
case 5:
-- 
1.9.1



[PATCH v2 2/2] x86/mce: add CMCI support for centaur CPUs

2018-04-01 Thread David Wang
This patch is used to tell the kernel that newer Centaur CPU support CMCI.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 arch/x86/kernel/cpu/mcheck/mce.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index c3db7ce..361d95e 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1751,6 +1751,7 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
 {
switch (c->x86_vendor) {
case X86_VENDOR_INTEL:
+   case X86_VENDOR_CENTAUR:
mce_intel_feature_init(c);
mce_adjust_timer = cmci_intel_adjust_timer;
break;
-- 
1.9.1



[PATCH v2 0/2] MCA support on Centaur CPU

2018-04-01 Thread David Wang
This patch set is to provide MCA support on new Centaur CPU.

The first patch is used to tell the kernel that newer Centaur CPU
support MCE broadcasting.

The second patch is used to tell the kernel that newer Centaur
CPU support CMCI.

Changes from v1 to v2:
* Capatilize 'Centaur' in the comments

David Wang (2):
  x86/mce: new Centaur CPUs support MCE broadcasting
  x86/mce: add CMCI support for centaur CPUs

 arch/x86/kernel/cpu/mcheck/mce.c | 12 
 1 file changed, 12 insertions(+)

-- 
1.9.1



[PATCH v2 1/2] x86/mce: new Centaur CPUs support MCE broadcasting

2018-04-01 Thread David Wang
This patch is used to tell the kernel that newer Centaur CPU support
MCE broadcasting.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 arch/x86/kernel/cpu/mcheck/mce.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 7065846..c3db7ce 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1688,6 +1688,17 @@ static int __mcheck_cpu_apply_quirks(struct cpuinfo_x86 
*c)
if (c->x86 == 6 && c->x86_model == 45)
quirk_no_way_out = quirk_sandybridge_ifu;
}
+
+   if (c->x86_vendor == X86_VENDOR_CENTAUR) {
+   /*
+* All newer Centaur CPUs support MCE broadcasting. Enable
+* synchronization with a one second timeout.
+*/
+   if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf && 
c->x86_mask >=0xe)) &&
+   cfg->monarch_timeout < 0)
+   cfg->monarch_timeout = USEC_PER_SEC;
+   }
+
if (cfg->monarch_timeout < 0)
cfg->monarch_timeout = 0;
if (cfg->bootlog != 0)
-- 
1.9.1



[PATCH v2 2/2] x86/mce: add CMCI support for centaur CPUs

2018-04-01 Thread David Wang
This patch is used to tell the kernel that newer Centaur CPU support CMCI.

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index c3db7ce..361d95e 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1751,6 +1751,7 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
 {
switch (c->x86_vendor) {
case X86_VENDOR_INTEL:
+   case X86_VENDOR_CENTAUR:
mce_intel_feature_init(c);
mce_adjust_timer = cmci_intel_adjust_timer;
break;
-- 
1.9.1



[PATCH v2 0/2] MCA support on Centaur CPU

2018-04-01 Thread David Wang
This patch set is to provide MCA support on new Centaur CPU.

The first patch is used to tell the kernel that newer Centaur CPU
support MCE broadcasting.

The second patch is used to tell the kernel that newer Centaur
CPU support CMCI.

Changes from v1 to v2:
* Capatilize 'Centaur' in the comments

David Wang (2):
  x86/mce: new Centaur CPUs support MCE broadcasting
  x86/mce: add CMCI support for centaur CPUs

 arch/x86/kernel/cpu/mcheck/mce.c | 12 
 1 file changed, 12 insertions(+)

-- 
1.9.1



[PATCH v2 1/2] x86/mce: new Centaur CPUs support MCE broadcasting

2018-04-01 Thread David Wang
This patch is used to tell the kernel that newer Centaur CPU support
MCE broadcasting.

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 7065846..c3db7ce 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1688,6 +1688,17 @@ static int __mcheck_cpu_apply_quirks(struct cpuinfo_x86 
*c)
if (c->x86 == 6 && c->x86_model == 45)
quirk_no_way_out = quirk_sandybridge_ifu;
}
+
+   if (c->x86_vendor == X86_VENDOR_CENTAUR) {
+   /*
+* All newer Centaur CPUs support MCE broadcasting. Enable
+* synchronization with a one second timeout.
+*/
+   if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf && 
c->x86_mask >=0xe)) &&
+   cfg->monarch_timeout < 0)
+   cfg->monarch_timeout = USEC_PER_SEC;
+   }
+
if (cfg->monarch_timeout < 0)
cfg->monarch_timeout = 0;
if (cfg->bootlog != 0)
-- 
1.9.1



[PATCH 0/2] MCA support on Centaur CPU

2018-03-30 Thread David Wang
This patch set is to provide MCA support on new Centaur CPU. 

The first patch is used to tell the kernel that newer Centaur CPU support 
MCE broadcasting.

The second patch is used to tell the kernel that newer Centaur CPU support 
CMCI. 

David Wang (2):
  x86/mce: new centaur CPUs support MCE broadcasting
  x86/mce: add CMCI support for centaur CPUs

 arch/x86/kernel/cpu/mcheck/mce.c | 12 
 1 file changed, 12 insertions(+)

-- 
1.9.1



[PATCH 2/2] x86/mce: add CMCI support for centaur CPUs

2018-03-30 Thread David Wang
This patch is used to tell the kernel that centaur CPUs support CMCI
mechanism which is compatible with INTEL CMCI.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 arch/x86/kernel/cpu/mcheck/mce.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 82b25e1..62aa85c 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1751,6 +1751,7 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
 {
switch (c->x86_vendor) {
case X86_VENDOR_INTEL:
+   case X86_VENDOR_CENTAUR:
mce_intel_feature_init(c);
mce_adjust_timer = cmci_intel_adjust_timer;
break;
-- 
1.9.1



[PATCH 1/2] x86/mce: new centaur CPUs support MCE broadcasting

2018-03-30 Thread David Wang
This patch is used to tell the kernel that newer Centaur CPU support MCE
broadcasting.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 arch/x86/kernel/cpu/mcheck/mce.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 7065846..82b25e1 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1688,6 +1688,17 @@ static int __mcheck_cpu_apply_quirks(struct cpuinfo_x86 
*c)
if (c->x86 == 6 && c->x86_model == 45)
quirk_no_way_out = quirk_sandybridge_ifu;
}
+
+   if (c->x86_vendor == X86_VENDOR_CENTAUR) {
+   /*
+* All newer centaur CPUs support MCE broadcasting. Enable
+* synchronization with a one second timeout.
+*/
+   if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf && 
c->x86_mask >=0xe)) &&
+   cfg->monarch_timeout < 0)
+   cfg->monarch_timeout = USEC_PER_SEC;
+   }
+
if (cfg->monarch_timeout < 0)
cfg->monarch_timeout = 0;
if (cfg->bootlog != 0)
-- 
1.9.1



[PATCH 0/2] MCA support on Centaur CPU

2018-03-30 Thread David Wang
This patch set is to provide MCA support on new Centaur CPU. 

The first patch is used to tell the kernel that newer Centaur CPU support 
MCE broadcasting.

The second patch is used to tell the kernel that newer Centaur CPU support 
CMCI. 

David Wang (2):
  x86/mce: new centaur CPUs support MCE broadcasting
  x86/mce: add CMCI support for centaur CPUs

 arch/x86/kernel/cpu/mcheck/mce.c | 12 
 1 file changed, 12 insertions(+)

-- 
1.9.1



[PATCH 2/2] x86/mce: add CMCI support for centaur CPUs

2018-03-30 Thread David Wang
This patch is used to tell the kernel that centaur CPUs support CMCI
mechanism which is compatible with INTEL CMCI.

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 82b25e1..62aa85c 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1751,6 +1751,7 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
 {
switch (c->x86_vendor) {
case X86_VENDOR_INTEL:
+   case X86_VENDOR_CENTAUR:
mce_intel_feature_init(c);
mce_adjust_timer = cmci_intel_adjust_timer;
break;
-- 
1.9.1



[PATCH 1/2] x86/mce: new centaur CPUs support MCE broadcasting

2018-03-30 Thread David Wang
This patch is used to tell the kernel that newer Centaur CPU support MCE
broadcasting.

Signed-off-by: David Wang 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 7065846..82b25e1 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1688,6 +1688,17 @@ static int __mcheck_cpu_apply_quirks(struct cpuinfo_x86 
*c)
if (c->x86 == 6 && c->x86_model == 45)
quirk_no_way_out = quirk_sandybridge_ifu;
}
+
+   if (c->x86_vendor == X86_VENDOR_CENTAUR) {
+   /*
+* All newer centaur CPUs support MCE broadcasting. Enable
+* synchronization with a one second timeout.
+*/
+   if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf && 
c->x86_mask >=0xe)) &&
+   cfg->monarch_timeout < 0)
+   cfg->monarch_timeout = USEC_PER_SEC;
+   }
+
if (cfg->monarch_timeout < 0)
cfg->monarch_timeout = 0;
if (cfg->bootlog != 0)
-- 
1.9.1



[PATCH v2] Optimize C3 entry on Centaur CPUs

2018-03-29 Thread David Wang
For new Centaur CPUs the ucode will take care of the preservation of
cache coherence between CPU cores in C-states and the other CPU cores
regardless of how deep the C-states are, so it is not necessary to
flush the caches in software before entering C3.

Signed-off-by: David Wang <davidw...@zhaoxin.com>

Changes from v1 to v2:
* 1, Add some Family/Model/Stepping contrains to let this patch only apply
* to new centaur CPUs.   
* 2, The arbiter disable/enable operations maybe needed for old VIA/Centaur
* platform. So, delete "flags->bm_control=0" in patch v1.

---
 arch/x86/kernel/acpi/cstate.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
index dde437f..d92a7f3 100644
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -51,6 +51,16 @@ void acpi_processor_power_init_bm_check(struct 
acpi_processor_flags *flags,
if (c->x86_vendor == X86_VENDOR_INTEL &&
(c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
flags->bm_control = 0;
+
+   /*
+* For all recent Centaur CPUs, the ucode will make sure that each core 
can keep
+* cache coherence with each other while entering C3 type state.
+* So, set bm_check to 1 to indicate that the kernel need not execute a 
cache 
+* flush operation (WBINVD) when entering C3 type state.
+*/
+   if (c->x86_vendor == X86_VENDOR_CENTAUR &&
+   (c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0x0f && 
c->x86_mask>=0x0e)))
+   flags->bm_check = 1;
 }
 EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
 
-- 
1.9.1



[PATCH v2] Optimize C3 entry on Centaur CPUs

2018-03-29 Thread David Wang
For new Centaur CPUs the ucode will take care of the preservation of
cache coherence between CPU cores in C-states and the other CPU cores
regardless of how deep the C-states are, so it is not necessary to
flush the caches in software before entering C3.

Signed-off-by: David Wang 

Changes from v1 to v2:
* 1, Add some Family/Model/Stepping contrains to let this patch only apply
* to new centaur CPUs.   
* 2, The arbiter disable/enable operations maybe needed for old VIA/Centaur
* platform. So, delete "flags->bm_control=0" in patch v1.

---
 arch/x86/kernel/acpi/cstate.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
index dde437f..d92a7f3 100644
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -51,6 +51,16 @@ void acpi_processor_power_init_bm_check(struct 
acpi_processor_flags *flags,
if (c->x86_vendor == X86_VENDOR_INTEL &&
(c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
flags->bm_control = 0;
+
+   /*
+* For all recent Centaur CPUs, the ucode will make sure that each core 
can keep
+* cache coherence with each other while entering C3 type state.
+* So, set bm_check to 1 to indicate that the kernel need not execute a 
cache 
+* flush operation (WBINVD) when entering C3 type state.
+*/
+   if (c->x86_vendor == X86_VENDOR_CENTAUR &&
+   (c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0x0f && 
c->x86_mask>=0x0e)))
+   flags->bm_check = 1;
 }
 EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
 
-- 
1.9.1



[PATCH v3] hwmon, via-cputem: support new centaur CPUs

2018-03-29 Thread David Wang
New centaur CPUs(Familiy == 7) also support this cpu temperature sensor.

Change from v2 to v3:
*replace "goto" with "if...else.." according to suggestion from Guenter
 
Change from v1 to v2:
*fixed the wrong if condition in patch v1.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 drivers/hwmon/via-cputemp.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/hwmon/via-cputemp.c b/drivers/hwmon/via-cputemp.c
index 07a0cb0..0e81f28 100644
--- a/drivers/hwmon/via-cputemp.c
+++ b/drivers/hwmon/via-cputemp.c
@@ -136,20 +136,24 @@ static int via_cputemp_probe(struct platform_device *pdev)
data->id = pdev->id;
data->name = "via_cputemp";
 
-   switch (c->x86_model) {
-   case 0xA:
-   /* C7 A */
-   case 0xD:
-   /* C7 D */
-   data->msr_temp = 0x1169;
-   data->msr_vid = 0x198;
-   break;
-   case 0xF:
-   /* Nano */
+   if (c->x86 == 7) {
data->msr_temp = 0x1423;
-   break;
-   default:
-   return -ENODEV;
+   } else {
+   switch (c->x86_model) {
+   case 0xA:
+   /* C7 A */
+   case 0xD:
+   /* C7 D */
+   data->msr_temp = 0x1169;
+   data->msr_vid = 0x198;
+   break;
+   case 0xF:
+   /* Nano */
+   data->msr_temp = 0x1423;
+   break;
+   default:
+   return -ENODEV;
+   }
}
 
/* test if we can access the TEMPERATURE MSR */
@@ -283,6 +287,7 @@ static int via_cputemp_down_prep(unsigned int cpu)
{ X86_VENDOR_CENTAUR, 6, 0xa, }, /* C7 A */
{ X86_VENDOR_CENTAUR, 6, 0xd, }, /* C7 D */
{ X86_VENDOR_CENTAUR, 6, 0xf, }, /* Nano */
+   { X86_VENDOR_CENTAUR, 7, X86_MODEL_ANY, },
{}
 };
 MODULE_DEVICE_TABLE(x86cpu, cputemp_ids);
-- 
1.9.1



[PATCH v3] hwmon, via-cputem: support new centaur CPUs

2018-03-29 Thread David Wang
New centaur CPUs(Familiy == 7) also support this cpu temperature sensor.

Change from v2 to v3:
*replace "goto" with "if...else.." according to suggestion from Guenter
 
Change from v1 to v2:
*fixed the wrong if condition in patch v1.

Signed-off-by: David Wang 
---
 drivers/hwmon/via-cputemp.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/hwmon/via-cputemp.c b/drivers/hwmon/via-cputemp.c
index 07a0cb0..0e81f28 100644
--- a/drivers/hwmon/via-cputemp.c
+++ b/drivers/hwmon/via-cputemp.c
@@ -136,20 +136,24 @@ static int via_cputemp_probe(struct platform_device *pdev)
data->id = pdev->id;
data->name = "via_cputemp";
 
-   switch (c->x86_model) {
-   case 0xA:
-   /* C7 A */
-   case 0xD:
-   /* C7 D */
-   data->msr_temp = 0x1169;
-   data->msr_vid = 0x198;
-   break;
-   case 0xF:
-   /* Nano */
+   if (c->x86 == 7) {
data->msr_temp = 0x1423;
-   break;
-   default:
-   return -ENODEV;
+   } else {
+   switch (c->x86_model) {
+   case 0xA:
+   /* C7 A */
+   case 0xD:
+   /* C7 D */
+   data->msr_temp = 0x1169;
+   data->msr_vid = 0x198;
+   break;
+   case 0xF:
+   /* Nano */
+   data->msr_temp = 0x1423;
+   break;
+   default:
+   return -ENODEV;
+   }
}
 
/* test if we can access the TEMPERATURE MSR */
@@ -283,6 +287,7 @@ static int via_cputemp_down_prep(unsigned int cpu)
{ X86_VENDOR_CENTAUR, 6, 0xa, }, /* C7 A */
{ X86_VENDOR_CENTAUR, 6, 0xd, }, /* C7 D */
{ X86_VENDOR_CENTAUR, 6, 0xf, }, /* Nano */
+   { X86_VENDOR_CENTAUR, 7, X86_MODEL_ANY, },
{}
 };
 MODULE_DEVICE_TABLE(x86cpu, cputemp_ids);
-- 
1.9.1



[PATCH v1] hwmon, via-cputem: support new centaur CPUs

2018-03-29 Thread David Wang
Newer centaur CPUs(Family == 7) also support this cpu temperature sensor.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 drivers/hwmon/via-cputemp.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/hwmon/via-cputemp.c b/drivers/hwmon/via-cputemp.c
index 07a0cb0..2f5bd50 100644
--- a/drivers/hwmon/via-cputemp.c
+++ b/drivers/hwmon/via-cputemp.c
@@ -136,6 +136,11 @@ static int via_cputemp_probe(struct platform_device *pdev)
data->id = pdev->id;
data->name = "via_cputemp";
 
+   if (c->x86 == 7) {
+   data->msr_temp = 0x1423;
+   goto test_access;
+   }
+
switch (c->x86_model) {
case 0xA:
/* C7 A */
@@ -152,6 +157,7 @@ static int via_cputemp_probe(struct platform_device *pdev)
return -ENODEV;
}
 
+test_access:
/* test if we can access the TEMPERATURE MSR */
err = rdmsr_safe_on_cpu(data->id, data->msr_temp, , );
if (err) {
@@ -283,6 +289,7 @@ static int via_cputemp_down_prep(unsigned int cpu)
{ X86_VENDOR_CENTAUR, 6, 0xa, }, /* C7 A */
{ X86_VENDOR_CENTAUR, 6, 0xd, }, /* C7 D */
{ X86_VENDOR_CENTAUR, 6, 0xf, }, /* Nano */
+   { X86_VENDOR_CENTAUR, 7, X86_MODEL_ANY, },
{}
 };
 MODULE_DEVICE_TABLE(x86cpu, cputemp_ids);
-- 
1.9.1



[PATCH v1] hwmon, via-cputem: support new centaur CPUs

2018-03-29 Thread David Wang
Newer centaur CPUs(Family == 7) also support this cpu temperature sensor.

Signed-off-by: David Wang 
---
 drivers/hwmon/via-cputemp.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/hwmon/via-cputemp.c b/drivers/hwmon/via-cputemp.c
index 07a0cb0..2f5bd50 100644
--- a/drivers/hwmon/via-cputemp.c
+++ b/drivers/hwmon/via-cputemp.c
@@ -136,6 +136,11 @@ static int via_cputemp_probe(struct platform_device *pdev)
data->id = pdev->id;
data->name = "via_cputemp";
 
+   if (c->x86 == 7) {
+   data->msr_temp = 0x1423;
+   goto test_access;
+   }
+
switch (c->x86_model) {
case 0xA:
/* C7 A */
@@ -152,6 +157,7 @@ static int via_cputemp_probe(struct platform_device *pdev)
return -ENODEV;
}
 
+test_access:
/* test if we can access the TEMPERATURE MSR */
err = rdmsr_safe_on_cpu(data->id, data->msr_temp, , );
if (err) {
@@ -283,6 +289,7 @@ static int via_cputemp_down_prep(unsigned int cpu)
{ X86_VENDOR_CENTAUR, 6, 0xa, }, /* C7 A */
{ X86_VENDOR_CENTAUR, 6, 0xd, }, /* C7 D */
{ X86_VENDOR_CENTAUR, 6, 0xf, }, /* Nano */
+   { X86_VENDOR_CENTAUR, 7, X86_MODEL_ANY, },
{}
 };
 MODULE_DEVICE_TABLE(x86cpu, cputemp_ids);
-- 
1.9.1



[PATCH] hwmon, via-cputemp: support new centaur CPUs

2018-03-29 Thread David Wang
Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 drivers/hwmon/via-cputemp.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/hwmon/via-cputemp.c b/drivers/hwmon/via-cputemp.c
index 07a0cb0..aa0d040 100644
--- a/drivers/hwmon/via-cputemp.c
+++ b/drivers/hwmon/via-cputemp.c
@@ -136,6 +136,11 @@ static int via_cputemp_probe(struct platform_device *pdev)
data->id = pdev->id;
data->name = "via_cputemp";
 
+   if (c->x86_model == 7) {
+   data->msr_temp = 0x1423;
+   goto test_access;
+   }
+
switch (c->x86_model) {
case 0xA:
/* C7 A */
@@ -152,6 +157,7 @@ static int via_cputemp_probe(struct platform_device *pdev)
return -ENODEV;
}
 
+test_access:
/* test if we can access the TEMPERATURE MSR */
err = rdmsr_safe_on_cpu(data->id, data->msr_temp, , );
if (err) {
@@ -283,6 +289,7 @@ static int via_cputemp_down_prep(unsigned int cpu)
{ X86_VENDOR_CENTAUR, 6, 0xa, }, /* C7 A */
{ X86_VENDOR_CENTAUR, 6, 0xd, }, /* C7 D */
{ X86_VENDOR_CENTAUR, 6, 0xf, }, /* Nano */
+   { X86_VENDOR_CENTAUR, 7, X86_MODEL_ANY, },
{}
 };
 MODULE_DEVICE_TABLE(x86cpu, cputemp_ids);
-- 
1.9.1



[PATCH] hwmon, via-cputemp: support new centaur CPUs

2018-03-29 Thread David Wang
Signed-off-by: David Wang 
---
 drivers/hwmon/via-cputemp.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/hwmon/via-cputemp.c b/drivers/hwmon/via-cputemp.c
index 07a0cb0..aa0d040 100644
--- a/drivers/hwmon/via-cputemp.c
+++ b/drivers/hwmon/via-cputemp.c
@@ -136,6 +136,11 @@ static int via_cputemp_probe(struct platform_device *pdev)
data->id = pdev->id;
data->name = "via_cputemp";
 
+   if (c->x86_model == 7) {
+   data->msr_temp = 0x1423;
+   goto test_access;
+   }
+
switch (c->x86_model) {
case 0xA:
/* C7 A */
@@ -152,6 +157,7 @@ static int via_cputemp_probe(struct platform_device *pdev)
return -ENODEV;
}
 
+test_access:
/* test if we can access the TEMPERATURE MSR */
err = rdmsr_safe_on_cpu(data->id, data->msr_temp, , );
if (err) {
@@ -283,6 +289,7 @@ static int via_cputemp_down_prep(unsigned int cpu)
{ X86_VENDOR_CENTAUR, 6, 0xa, }, /* C7 A */
{ X86_VENDOR_CENTAUR, 6, 0xd, }, /* C7 D */
{ X86_VENDOR_CENTAUR, 6, 0xf, }, /* Nano */
+   { X86_VENDOR_CENTAUR, 7, X86_MODEL_ANY, },
{}
 };
 MODULE_DEVICE_TABLE(x86cpu, cputemp_ids);
-- 
1.9.1



[PATCH] Delete some unusefull operations for centaur CPU/platform

2018-03-01 Thread David Wang
For Centaur CPU, the ucode will make sure that each CPU core can keep cache
coherency with each other when the CPU core entering to any C state. So the
cache flush operations when enter C3 is not necessary and will cause large
C3 enter/exit latency.
And the bus master disable operation when CPU core entering C3 state is not
needed too. Because the chipset will automatically do this operation.

Signed-off-by: David Wang <davidw...@zhaoxin.com>
---
 arch/x86/kernel/acpi/cstate.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
index dde437f..1cd357b 100644
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -51,6 +51,18 @@ void acpi_processor_power_init_bm_check(struct 
acpi_processor_flags *flags,
if (c->x86_vendor == X86_VENDOR_INTEL &&
(c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
flags->bm_control = 0;
+
+if (c->x86_vendor == X86_VENDOR_CENTAUR) {
+   /*
+* on all centaur CPUs, sw need not execute cache flush 
operation
+* when entering C3 type State.
+*
+* On all Centaur platforms, sw need not execute ARB_DISABLE 
while
+* entering C3 type state.
+*/
+   flags->bm_check = 1;
+   flags->bm_control = 0;
+   }
 }
 EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
 
-- 
1.9.1



[PATCH] Delete some unusefull operations for centaur CPU/platform

2018-03-01 Thread David Wang
For Centaur CPU, the ucode will make sure that each CPU core can keep cache
coherency with each other when the CPU core entering to any C state. So the
cache flush operations when enter C3 is not necessary and will cause large
C3 enter/exit latency.
And the bus master disable operation when CPU core entering C3 state is not
needed too. Because the chipset will automatically do this operation.

Signed-off-by: David Wang 
---
 arch/x86/kernel/acpi/cstate.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
index dde437f..1cd357b 100644
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -51,6 +51,18 @@ void acpi_processor_power_init_bm_check(struct 
acpi_processor_flags *flags,
if (c->x86_vendor == X86_VENDOR_INTEL &&
(c->x86 > 0xf || (c->x86 == 6 && c->x86_model >= 0x0f)))
flags->bm_control = 0;
+
+if (c->x86_vendor == X86_VENDOR_CENTAUR) {
+   /*
+* on all centaur CPUs, sw need not execute cache flush 
operation
+* when entering C3 type State.
+*
+* On all Centaur platforms, sw need not execute ARB_DISABLE 
while
+* entering C3 type state.
+*/
+   flags->bm_check = 1;
+   flags->bm_control = 0;
+   }
 }
 EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
 
-- 
1.9.1