[PATCH v3 00/14] Add support for Hygon Dhyana Family 18h processor

[PATCH v3 00/14] Add support for Hygon Dhyana Family 18h processor

[Pu Wen]

As a new x86 CPU vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
is a joint venture between AMD and Haiguang Information Technology Co.,
Ltd., aims at providing high performance x86 processors for China
server market.

The first generation Hygon processor(Dhyana) originates from AMD
technology and shares most of the architecture with AMD's family 17h,
but with different CPU vendor ID("HygonGenuine") and family series
number 18h (Hygon negotiated with AMD to make sure that only Hygon
will use family 18h).

To enable support of Xen to Hygon Dhyana CPU, add a new vendor type
(X86_VENDOR_HYGON, with value of 5), and share most of the code with
AMD family 17h.

The MSRs and CPUIDs which are used by this patch series are all defined
in this PPR[1].

This patch series have been applied and tested successfully on Hygon
Dhyana processor, also been tested on AMD EPYC (family 17h) processor.
It works fine and makes no harm to the existing code.

Reference:
[1] https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf


v2->v3:
  - Rebased on 4.13-unstable and tested against it.
  - Simplify code of hygon.c by re-using early_init_amd().
  - Return false in the function probe_cpuid_faulting().
  - Adjust code for calculating phys_proc_id for Hygon.
  - Abstract common function _vpmu_init() and add hygon_vpmu_init().
  - Refine some comments and descriptions.
  - Add Acked-by from Jan Beulich for x86/cpu/mtrr, x86/cpu/mce,
    x86/spec_ctrl, x86/apic, x86/acpi, x86/iommu, x86/pv, x86/domain,
    x86/domctl and x86/cpuid.

v1->v2:
  - Rebased on 4.12.0-rc3 and tested against it.
  - Move opt_cpuid_mask_l7s0_(eax/ebx) to common.c.
  - Insert Hygon cases after AMD ones instead of above.
  - Remove (rd/wr)msr_hygon_safe and use (rd/wr)msr_safe instead.
  - Remove wrmsr_hygon and use wrmsrl instead.
  - Remove the unnecessary change to xstate.
  - Refine some codes and comments.
  - Add Acked-by from Jan Beulich for x86/traps.
  - Add Acked-by from Wei Liu for tools/libxc.


Pu Wen (14):
  x86/cpu: Create Hygon Dhyana architecture support file
  x86/cpu/mtrr: Add Hygon Dhyana support to get TOP_MEM2
  x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU
  x86/cpu/mce: Add Hygon Dhyana support to the MCA infrastructure
  x86/spec_ctrl: Add Hygon Dhyana to the respective mitigation machinery
  x86/apic: Add Hygon Dhyana support
  x86/acpi: Add Hygon Dhyana support
  x86/iommu: Add Hygon Dhyana support
  x86/pv: Add Hygon Dhyana support to emulate MSRs access
  x86/domain: Add Hygon Dhyana support
  x86/domctl: Add Hygon Dhyana support
  x86/traps: Add Hygon Dhyana support
  x86/cpuid: Add Hygon Dhyana support
  tools/libxc: Add Hygon Dhyana support

 tools/libxc/xc_cpuid_x86.c             | 16 ++++--
 xen/arch/x86/acpi/cpu_idle.c           |  3 +-
 xen/arch/x86/acpi/cpufreq/cpufreq.c    |  8 +--
 xen/arch/x86/acpi/cpufreq/powernow.c   |  3 +-
 xen/arch/x86/apic.c                    |  5 ++
 xen/arch/x86/cpu/Makefile              |  1 +
 xen/arch/x86/cpu/amd.c                 |  7 +--
 xen/arch/x86/cpu/common.c              | 12 ++++-
 xen/arch/x86/cpu/cpu.h                 |  4 ++
 xen/arch/x86/cpu/hygon.c               | 95 ++++++++++++++++++++++++++++++++++
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c |  5 +-
 xen/arch/x86/cpu/mcheck/mce.c          |  6 ++-
 xen/arch/x86/cpu/mcheck/mce_amd.c      |  5 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c    |  3 +-
 xen/arch/x86/cpu/mcheck/vmce.c         |  2 +
 xen/arch/x86/cpu/mtrr/generic.c        |  5 +-
 xen/arch/x86/cpu/vpmu.c                |  5 ++
 xen/arch/x86/cpu/vpmu_amd.c            | 57 ++++++++++++++------
 xen/arch/x86/cpuid.c                   | 10 ++--
 xen/arch/x86/dom0_build.c              |  3 +-
 xen/arch/x86/domain.c                  |  9 ++--
 xen/arch/x86/domctl.c                  | 13 +++--
 xen/arch/x86/pv/emul-priv-op.c         | 19 ++++---
 xen/arch/x86/spec_ctrl.c               |  6 ++-
 xen/arch/x86/traps.c                   |  3 ++
 xen/include/asm-x86/iommu.h            |  1 +
 xen/include/asm-x86/vpmu.h             |  1 +
 xen/include/asm-x86/x86-vendors.h      |  3 +-
 28 files changed, 250 insertions(+), 60 deletions(-)
 create mode 100644 xen/arch/x86/cpu/hygon.c

-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 01/14] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

Add x86 architecture support for a new processor: Hygon Dhyana Family
18h. To make Hygon initialization flow more clear, carve out code from
amd.c into a separate file hygon.c, and remove unnecessary code for
Hygon Dhyana.

To identify Hygon Dhyana CPU, add a new vendor type X86_VENDOR_HYGON
for system recognition.

Hygon can fully use the function early_init_amd(), so make this common
function non-static and direct call it from Hygon code.

As opt_cpuid_mask_l7s0_eax and opt_cpuid_mask_l7s0_ebx are used by both
AMD and Hygon, so move them to common.c.

Hygon Dhyana has no CPUID faulting, so directly return false in the
function probe_cpuid_faulting().

Add a separate hygon_get_topology(), which calculate phys_proc_id from
AcpiId[6](see reference [1]).

Reference:
[1] https://git.kernel.org/tip/e0ceeae708cebf22c990c3d703a4ca187dc837f5

Signed-off-by: Pu Wen <puwen@hygon.cn>
---
 xen/arch/x86/cpu/Makefile         |  1 +
 xen/arch/x86/cpu/amd.c            |  7 +--
 xen/arch/x86/cpu/common.c         |  9 ++++
 xen/arch/x86/cpu/cpu.h            |  4 ++
 xen/arch/x86/cpu/hygon.c          | 95 +++++++++++++++++++++++++++++++++++++++
 xen/include/asm-x86/x86-vendors.h |  3 +-
 6 files changed, 112 insertions(+), 7 deletions(-)
 create mode 100644 xen/arch/x86/cpu/hygon.c

diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
index 34a01ca..466acc8 100644
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -4,6 +4,7 @@ subdir-y += mtrr
 obj-y += amd.o
 obj-y += centaur.o
 obj-y += common.o
+obj-y += hygon.o
 obj-y += intel.o
 obj-y += intel_cacheinfo.o
 obj-y += mwait-idle.o
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index c790416..812d54d 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -32,11 +32,6 @@
 static char __initdata opt_famrev[14];
 string_param("cpuid_mask_cpu", opt_famrev);
 
-static unsigned int __initdata opt_cpuid_mask_l7s0_eax = ~0u;
-integer_param("cpuid_mask_l7s0_eax", opt_cpuid_mask_l7s0_eax);
-static unsigned int __initdata opt_cpuid_mask_l7s0_ebx = ~0u;
-integer_param("cpuid_mask_l7s0_ebx", opt_cpuid_mask_l7s0_ebx);
-
 static unsigned int __initdata opt_cpuid_mask_thermal_ecx = ~0u;
 integer_param("cpuid_mask_thermal_ecx", opt_cpuid_mask_thermal_ecx);
 
@@ -526,7 +521,7 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
                                                           : c->cpu_core_id);
 }
 
-static void early_init_amd(struct cpuinfo_x86 *c)
+void early_init_amd(struct cpuinfo_x86 *c)
 {
 	if (c == &boot_cpu_data)
 		amd_init_levelling();
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 53bb0a9..9fb75dd 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -36,6 +36,11 @@ integer_param("cpuid_mask_ext_ecx", opt_cpuid_mask_ext_ecx);
 unsigned int opt_cpuid_mask_ext_edx = ~0u;
 integer_param("cpuid_mask_ext_edx", opt_cpuid_mask_ext_edx);
 
+unsigned int  opt_cpuid_mask_l7s0_eax = ~0u;
+integer_param("cpuid_mask_l7s0_eax", opt_cpuid_mask_l7s0_eax);
+unsigned int  opt_cpuid_mask_l7s0_ebx = ~0u;
+integer_param("cpuid_mask_l7s0_ebx", opt_cpuid_mask_l7s0_ebx);
+
 unsigned int __initdata expected_levelling_cap;
 unsigned int __read_mostly levelling_caps;
 
@@ -116,6 +121,9 @@ bool __init probe_cpuid_faulting(void)
 	uint64_t val;
 	int rc;
 
+	if(boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+		return false;
+
 	if ((rc = rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val)) == 0)
 		raw_msr_policy.plaform_info.cpuid_faulting =
 			val & MSR_PLATFORM_INFO_CPUID_FAULTING;
@@ -710,6 +718,7 @@ void __init early_cpu_init(void)
 	amd_init_cpu();
 	centaur_init_cpu();
 	shanghai_init_cpu();
+	hygon_init_cpu();
 	early_cpu_detect();
 }
 
diff --git a/xen/arch/x86/cpu/cpu.h b/xen/arch/x86/cpu/cpu.h
index 2fcb931..971077a 100644
--- a/xen/arch/x86/cpu/cpu.h
+++ b/xen/arch/x86/cpu/cpu.h
@@ -13,11 +13,15 @@ extern bool_t opt_arat;
 extern unsigned int opt_cpuid_mask_ecx, opt_cpuid_mask_edx;
 extern unsigned int opt_cpuid_mask_xsave_eax;
 extern unsigned int opt_cpuid_mask_ext_ecx, opt_cpuid_mask_ext_edx;
+extern unsigned int opt_cpuid_mask_l7s0_eax, opt_cpuid_mask_l7s0_ebx;
 
 extern int get_model_name(struct cpuinfo_x86 *c);
 extern void display_cacheinfo(struct cpuinfo_x86 *c);
 
+void early_init_amd(struct cpuinfo_x86 *c);
+
 int intel_cpu_init(void);
 int amd_init_cpu(void);
 int centaur_init_cpu(void);
 int shanghai_init_cpu(void);
+int hygon_init_cpu(void);
diff --git a/xen/arch/x86/cpu/hygon.c b/xen/arch/x86/cpu/hygon.c
new file mode 100644
index 0000000..bbe13c5
--- /dev/null
+++ b/xen/arch/x86/cpu/hygon.c
@@ -0,0 +1,95 @@
+#include <xen/init.h>
+#include <asm/processor.h>
+#include <asm/hvm/support.h>
+#include <asm/spec_ctrl.h>
+
+#include "cpu.h"
+
+#define APICID_SOCKET_ID_BIT 6
+
+static void hygon_get_topology(struct cpuinfo_x86 *c)
+{
+	u32 ebx;
+
+	if (c->x86_max_cores <= 1)
+		return;
+
+	/* Socket ID is ApicId[6] for Hygon processors. */
+	c->phys_proc_id >>= APICID_SOCKET_ID_BIT;
+
+	ebx = cpuid_ebx(0x8000001e);
+	c->x86_num_siblings = ((ebx >> 8) & 0x3) + 1;
+	c->x86_max_cores /= c->x86_num_siblings;
+	c->cpu_core_id = ebx & 0xff;
+
+	if (opt_cpu_info)
+	        printk("CPU %d(%d) -> Processor %d, Core %d\n",
+	                smp_processor_id(), c->x86_max_cores,
+	                        c->phys_proc_id, c->cpu_core_id);
+}
+
+static void early_init_hygon(struct cpuinfo_x86 *c)
+{
+	early_init_amd(c);
+}
+
+static void init_hygon(struct cpuinfo_x86 *c)
+{
+	u32 l, h;
+	unsigned long long value;
+
+	/* Attempt to set LFENCE to be Dispatch Serialising. */
+	if (rdmsr_safe(MSR_AMD64_DE_CFG, value))
+		/* Unable to read.  Assume the safer default. */
+		__clear_bit(X86_FEATURE_LFENCE_DISPATCH, c->x86_capability);
+	if (value & AMD64_DE_CFG_LFENCE_SERIALISE)
+		/* Dispatch Serialising. */
+		__set_bit(X86_FEATURE_LFENCE_DISPATCH, c->x86_capability);
+
+	/*
+	 * If the user has explicitly chosen to disable Memory Disambiguation
+	 * to mitigiate Speculative Store Bypass, poke the appropriate MSR.
+	 */
+ 	if (opt_ssbd && !rdmsr_safe(MSR_AMD64_LS_CFG, value)) {
+		value |= 1ull << 10;
+		wrmsr_safe(MSR_AMD64_LS_CFG, value);
+	}
+
+	display_cacheinfo(c);
+
+	if (cpu_has(c, X86_FEATURE_ITSC)) {
+		__set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
+		__set_bit(X86_FEATURE_NONSTOP_TSC, c->x86_capability);
+		__set_bit(X86_FEATURE_TSC_RELIABLE, c->x86_capability);
+	}
+
+	c->x86_max_cores = (cpuid_ecx(0x80000008) & 0xff) + 1;
+
+	hygon_get_topology(c);
+
+	/* Hygon CPUs do not support SYSENTER outside of legacy mode. */
+	__clear_bit(X86_FEATURE_SEP, c->x86_capability);
+
+	/* Hygon processors have APIC timer running in deep C states. */
+	if (opt_arat)
+		__set_bit(X86_FEATURE_ARAT, c->x86_capability);
+
+	if (cpu_has(c, X86_FEATURE_EFRO)) {
+		rdmsr(MSR_K7_HWCR, l, h);
+		l |= (1 << 27); /* Enable read-only APERF/MPERF bit */
+		wrmsr(MSR_K7_HWCR, l, h);
+	}
+}
+
+static const struct cpu_dev hygon_cpu_dev = {
+	.c_vendor	= "Hygon",
+	.c_ident 	= { "HygonGenuine" },
+	.c_early_init	= early_init_hygon,
+	.c_init		= init_hygon,
+};
+
+int __init hygon_init_cpu(void)
+{
+	cpu_devs[X86_VENDOR_HYGON] = &hygon_cpu_dev;
+	return 0;
+}
diff --git a/xen/include/asm-x86/x86-vendors.h b/xen/include/asm-x86/x86-vendors.h
index 38a81c3..fa1cbb4 100644
--- a/xen/include/asm-x86/x86-vendors.h
+++ b/xen/include/asm-x86/x86-vendors.h
@@ -9,6 +9,7 @@
 #define X86_VENDOR_AMD 2
 #define X86_VENDOR_CENTAUR 3
 #define X86_VENDOR_SHANGHAI 4
-#define X86_VENDOR_NUM 5
+#define X86_VENDOR_HYGON 5
+#define X86_VENDOR_NUM 6
 
 #endif	/* __XEN_X86_VENDORS_H__ */
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 02/14] x86/cpu/mtrr: Add Hygon Dhyana support to get TOP_MEM2

[Pu Wen]

The Hygon Dhyana CPU supports the MSR way to get TOP_MEM2. So add Hygon
Dhyana support to print the value of TOP_MEM2.

Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/cpu/mtrr/generic.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/cpu/mtrr/generic.c b/xen/arch/x86/cpu/mtrr/generic.c
index 8f9cf1b..94ee7d6 100644
--- a/xen/arch/x86/cpu/mtrr/generic.c
+++ b/xen/arch/x86/cpu/mtrr/generic.c
@@ -217,8 +217,9 @@ static void __init print_mtrr_state(const char *level)
 			printk("%s  %u disabled\n", level, i);
 	}
 
-	if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD
-	    && boot_cpu_data.x86 >= 0xf) {
+	if ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
+	     boot_cpu_data.x86 >= 0xf) ||
+	     boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
 		uint64_t syscfg, tom2;
 
 		rdmsrl(MSR_K8_SYSCFG, syscfg);
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 03/14] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Pu Wen]

As Hygon Dhyana CPU share similar PMU architecture with AMD family
17h one, so add Hygon Dhyana support in vpmu_arch_initialise() and
vpmu_init() by sharing AMD code path.

Split the common part in amd_vpmu_init() to a static function
_vpmu_init(), making AMD and Hygon to call the shared function to
initialize vPMU.

As current vPMU still not support Zen(family 17h), add 0x17 support
to amd_vpmu_init().

Also create a function hygon_vpmu_init() for Hygon vPMU initialization.

Both of AMD 17h and Hygon 18h have the same performance event select
and counter MSRs as AMD 15h has, so reuse the 15h definitions for them.

Signed-off-by: Pu Wen <puwen@hygon.cn>
---
 xen/arch/x86/cpu/vpmu.c     |  5 ++++
 xen/arch/x86/cpu/vpmu_amd.c | 57 ++++++++++++++++++++++++++++++++-------------
 xen/include/asm-x86/vpmu.h  |  1 +
 3 files changed, 47 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 8f6daf1..93a27d8 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -456,6 +456,7 @@ static int vpmu_arch_initialise(struct vcpu *v)
     switch ( vendor )
     {
     case X86_VENDOR_AMD:
+    case X86_VENDOR_HYGON:
         ret = svm_vpmu_initialise(v);
         break;
 
@@ -876,6 +877,10 @@ static int __init vpmu_init(void)
         if ( amd_vpmu_init() )
            vpmu_mode = XENPMU_MODE_OFF;
         break;
+    case X86_VENDOR_HYGON:
+        if ( hygon_vpmu_init() )
+           vpmu_mode = XENPMU_MODE_OFF;
+        break;
     case X86_VENDOR_INTEL:
         if ( core2_vpmu_init() )
            vpmu_mode = XENPMU_MODE_OFF;
diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
index 5efc39b..3fc955f 100644
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -538,13 +538,37 @@ int svm_vpmu_initialise(struct vcpu *v)
     return 0;
 }
 
-int __init amd_vpmu_init(void)
+static int _vpmu_init(void)
 {
     unsigned int i;
 
+    if ( sizeof(struct xen_pmu_data) +
+         2 * sizeof(uint64_t) * num_counters > PAGE_SIZE )
+    {
+        printk(XENLOG_WARNING
+               "VPMU: Register bank does not fit into VPMU shared page\n");
+        counters = ctrls = NULL;
+        num_counters = 0;
+        return -ENOSPC;
+    }
+
+    for ( i = 0; i < num_counters; i++ )
+    {
+        rdmsrl(ctrls[i], ctrl_rsvd[i]);
+        ctrl_rsvd[i] &= CTRL_RSVD_MASK;
+    }
+
+    regs_sz = 2 * sizeof(uint64_t) * num_counters;
+
+    return 0;
+}
+
+int __init amd_vpmu_init(void)
+{
     switch ( current_cpu_data.x86 )
     {
     case 0x15:
+    case 0x17:
         num_counters = F15H_NUM_COUNTERS;
         counters = AMD_F15H_COUNTERS;
         ctrls = AMD_F15H_CTRLS;
@@ -565,24 +589,25 @@ int __init amd_vpmu_init(void)
         return -EINVAL;
     }
 
-    if ( sizeof(struct xen_pmu_data) +
-         2 * sizeof(uint64_t) * num_counters > PAGE_SIZE )
-    {
-        printk(XENLOG_WARNING
-               "VPMU: Register bank does not fit into VPMU shared page\n");
-        counters = ctrls = NULL;
-        num_counters = 0;
-        return -ENOSPC;
-    }
+    return _vpmu_init();
+}
 
-    for ( i = 0; i < num_counters; i++ )
+int __init hygon_vpmu_init(void)
+{
+    switch ( current_cpu_data.x86 )
     {
-        rdmsrl(ctrls[i], ctrl_rsvd[i]);
-        ctrl_rsvd[i] &= CTRL_RSVD_MASK;
+    case 0x18:
+        num_counters = F15H_NUM_COUNTERS;
+        counters = AMD_F15H_COUNTERS;
+        ctrls = AMD_F15H_CTRLS;
+        k7_counters_mirrored = 1;
+        break;
+    default:
+        printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
+               current_cpu_data.x86);
+        return -EINVAL;
     }
 
-    regs_sz = 2 * sizeof(uint64_t) * num_counters;
-
-    return 0;
+    return _vpmu_init();
 }
 
diff --git a/xen/include/asm-x86/vpmu.h b/xen/include/asm-x86/vpmu.h
index 1287b9f..55f85ba 100644
--- a/xen/include/asm-x86/vpmu.h
+++ b/xen/include/asm-x86/vpmu.h
@@ -52,6 +52,7 @@ struct arch_vpmu_ops {
 int core2_vpmu_init(void);
 int vmx_vpmu_initialise(struct vcpu *);
 int amd_vpmu_init(void);
+int hygon_vpmu_init(void);
 int svm_vpmu_initialise(struct vcpu *);
 
 struct vpmu_struct {
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 04/14] x86/cpu/mce: Add Hygon Dhyana support to the MCA infrastructure

[Pu Wen]

The machine check architecture for Hygon Dhyana CPU is similar to the
AMD family 17h one. Add vendor checking for Hygon Dhyana to share the
code path of AMD family 17h.

Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/cpu/common.c              | 3 ++-
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c | 5 +++--
 xen/arch/x86/cpu/mcheck/mce.c          | 6 ++++--
 xen/arch/x86/cpu/mcheck/mce_amd.c      | 5 ++++-
 xen/arch/x86/cpu/mcheck/non-fatal.c    | 3 ++-
 xen/arch/x86/cpu/mcheck/vmce.c         | 2 ++
 6 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 9fb75dd..3f70415 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -353,7 +353,8 @@ static void __init early_cpu_detect(void)
 			hap_paddr_bits = PADDR_BITS;
 	}
 
-	if (c->x86_vendor != X86_VENDOR_AMD)
+	if (c->x86_vendor != X86_VENDOR_AMD &&
+	    c->x86_vendor != X86_VENDOR_HYGON)
 		park_offline_cpus = opt_mce;
 
 	initialize_cpu_data(0);
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 222f539..589dac5 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -203,10 +203,11 @@ static void mce_amd_work_fn(void *data)
 
 void __init amd_nonfatal_mcheck_init(struct cpuinfo_x86 *c)
 {
-	if (c->x86_vendor != X86_VENDOR_AMD)
+	if (c->x86_vendor != X86_VENDOR_AMD &&
+	    c->x86_vendor != X86_VENDOR_HYGON)
 		return;
 
-	/* Assume we are on K8 or newer AMD CPU here */
+	/* Assume we are on K8 or newer AMD or Hygon CPU here */
 
 	/* The threshold bitfields in MSR_IA32_MC4_MISC has
 	 * been introduced along with the SVME feature bit. */
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 30cdb06..0798dea 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -778,6 +778,7 @@ void mcheck_init(struct cpuinfo_x86 *c, bool bsp)
     switch ( c->x86_vendor )
     {
     case X86_VENDOR_AMD:
+    case X86_VENDOR_HYGON:
         inited = amd_mcheck_init(c);
         break;
 
@@ -1172,10 +1173,11 @@ static bool x86_mc_msrinject_verify(struct xen_mc_msrinject *mci)
 
             /* MSRs that the HV will take care of */
             case MSR_K8_HWCR:
-                if ( c->x86_vendor == X86_VENDOR_AMD )
+                if ( c->x86_vendor == X86_VENDOR_AMD ||
+                     c->x86_vendor == X86_VENDOR_HYGON )
                     reason = "HV will operate HWCR";
                 else
-                    reason = "only supported on AMD";
+                    reason = "only supported on AMD or Hygon";
                 break;
 
             default:
diff --git a/xen/arch/x86/cpu/mcheck/mce_amd.c b/xen/arch/x86/cpu/mcheck/mce_amd.c
index ed29fcc..8ed2b17 100644
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c
@@ -286,7 +286,10 @@ enum mcheck_type
 amd_mcheck_init(struct cpuinfo_x86 *ci)
 {
     uint32_t i;
-    enum mcequirk_amd_flags quirkflag = mcequirk_lookup_amd_quirkdata(ci);
+    enum mcequirk_amd_flags quirkflag = 0;
+
+    if (ci->x86_vendor != X86_VENDOR_HYGON)
+        quirkflag = mcequirk_lookup_amd_quirkdata(ci);
 
     /* Assume that machine check support is available.
      * The minimum provided support is at least the K8. */
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c
index d12e8f2..77be418 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -101,7 +101,8 @@ static int __init init_nonfatal_mce_checker(void)
 	 */
 	switch (c->x86_vendor) {
 	case X86_VENDOR_AMD:
-		/* Assume we are on K8 or newer AMD CPU here */
+	case X86_VENDOR_HYGON:
+		/* Assume we are on K8 or newer AMD or Hygon CPU here */
 		amd_nonfatal_mcheck_init(c);
 		break;
 
diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index f15835e..4f5de07 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -154,6 +154,7 @@ static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
             break;
 
         case X86_VENDOR_AMD:
+        case X86_VENDOR_HYGON:
             ret = vmce_amd_rdmsr(v, msr, val);
             break;
 
@@ -284,6 +285,7 @@ static int bank_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
             break;
 
         case X86_VENDOR_AMD:
+        case X86_VENDOR_HYGON:
             ret = vmce_amd_wrmsr(v, msr, val);
             break;
 
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 05/14] x86/spec_ctrl: Add Hygon Dhyana to the respective mitigation machinery

[Pu Wen]

The Hygon Dhyana CPU has the same speculative execution as AMD family
17h, so share AMD Retpoline and PTI mitigation code with Hygon Dhyana.

Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/spec_ctrl.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index 1171c02..1cd7903 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -306,7 +306,8 @@ static bool __init retpoline_safe(uint64_t caps)
 {
     unsigned int ucode_rev = this_cpu(ucode_cpu_info).cpu_sig.rev;
 
-    if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+    if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+         boot_cpu_data.x86_vendor == X86_VENDOR_HYGON )
         return true;
 
     if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
@@ -632,7 +633,8 @@ int8_t __read_mostly opt_xpti_domu = -1;
 
 static __init void xpti_init_default(uint64_t caps)
 {
-    if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+    if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+         boot_cpu_data.x86_vendor == X86_VENDOR_HYGON )
         caps = ARCH_CAPS_RDCL_NO;
 
     if ( caps & ARCH_CAPS_RDCL_NO )
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 06/14] x86/apic: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to use modern APIC.

Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/apic.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 2a24326..004d685 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -92,6 +92,11 @@ static int modern_apic(void)
     if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
         boot_cpu_data.x86 >= 0xf)
         return 1;
+
+    /* Hygon systems use modern APIC */
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+        return 1;
+
     lvr = apic_read(APIC_LVR);
     version = GET_APIC_VERSION(lvr);
     return version >= 0x14;
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 07/14] x86/acpi: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to the acpi cpufreq and cpuidle subsystems by
using the code path of AMD.

Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/acpi/cpu_idle.c         | 3 ++-
 xen/arch/x86/acpi/cpufreq/cpufreq.c  | 8 +++++---
 xen/arch/x86/acpi/cpufreq/powernow.c | 3 ++-
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 654de24..02e4873 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -796,7 +796,8 @@ void acpi_dead_idle(void)
             __mwait(cx->address, 0);
         }
     }
-    else if ( current_cpu_data.x86_vendor == X86_VENDOR_AMD &&
+    else if ( (current_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+               current_cpu_data.x86_vendor == X86_VENDOR_HYGON) &&
               cx->entry_method == ACPI_CSTATE_EM_SYSIO )
     {
         /* Intel prefers not to use SYSIO */
diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c b/xen/arch/x86/acpi/cpufreq/cpufreq.c
index 844ab85..14c18bd 100644
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -649,7 +649,8 @@ static int __init cpufreq_driver_init(void)
         (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL))
         ret = cpufreq_register_driver(&acpi_cpufreq_driver);
     else if ((cpufreq_controller == FREQCTL_xen) &&
-        (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
+        (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+         boot_cpu_data.x86_vendor == X86_VENDOR_HYGON))
         ret = powernow_register_driver();
 
     return ret;
@@ -660,9 +661,10 @@ int cpufreq_cpu_init(unsigned int cpuid)
 {
     int ret;
 
-    /* Currently we only handle Intel and AMD processor */
+    /* Currently we only handle Intel, AMD and Hygon processor */
     if ( (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ) ||
-         (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) )
+         (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) ||
+         (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ) )
         ret = cpufreq_add_cpu(cpuid);
     else
         ret = -EFAULT;
diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c b/xen/arch/x86/acpi/cpufreq/powernow.c
index 025b37d..f245908 100644
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -360,7 +360,8 @@ unsigned int __init powernow_register_driver()
 
     for_each_online_cpu(i) {
         struct cpuinfo_x86 *c = &cpu_data[i];
-        if (c->x86_vendor != X86_VENDOR_AMD)
+        if (c->x86_vendor != X86_VENDOR_AMD &&
+            c->x86_vendor != X86_VENDOR_HYGON)
             ret = -ENODEV;
         else
         {
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 08/14] x86/iommu: Add Hygon Dhyana support

[Pu Wen]

The IOMMU architecture for the Hygon Dhyana CPU is similar to the AMD
family 17h one. So add Hygon Dhyana support to it by sharing the code
path of AMD.

Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/include/asm-x86/iommu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h
index 8dc3924..699a8f7 100644
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -74,6 +74,7 @@ static inline int iommu_hardware_setup(void)
     case X86_VENDOR_INTEL:
         return intel_vtd_setup();
     case X86_VENDOR_AMD:
+    case X86_VENDOR_HYGON:
         return amd_iov_detect();
     }
 
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 09/14] x86/pv: Add Hygon Dhyana support to emulate MSRs access

[Pu Wen]

The Hygon Dhyana CPU supports lots of MSRs(such as perf event select and
counter MSRs, hardware configuration MSR, MMIO configuration base address
MSR, MPERF/APERF MSRs) as AMD CPU does, so add Hygon Dhyana support to the
PV emulation infrastructure by using the code path of AMD.

Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/pv/emul-priv-op.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 3746e2a..c92f9dc 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -924,7 +924,9 @@ static int read_msr(unsigned int reg, uint64_t *val,
             /* fall through */
     case MSR_AMD_FAM15H_EVNTSEL0 ... MSR_AMD_FAM15H_PERFCTR5:
     case MSR_K7_EVNTSEL0 ... MSR_K7_PERFCTR3:
-            if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
+            if ( vpmu_msr ||
+                (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) ||
+                (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) )
             {
                 if ( vpmu_do_rdmsr(reg, val) )
                     break;
@@ -1006,7 +1008,8 @@ static int write_msr(unsigned int reg, uint64_t val,
     case MSR_K8_PSTATE6:
     case MSR_K8_PSTATE7:
     case MSR_K8_HWCR:
-        if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+        if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+             boot_cpu_data.x86_vendor != X86_VENDOR_HYGON )
             break;
         if ( likely(!is_cpufreq_controller(currd)) ||
              wrmsr_safe(reg, val) == 0 )
@@ -1027,8 +1030,9 @@ static int write_msr(unsigned int reg, uint64_t val,
         break;
 
     case MSR_FAM10H_MMIO_CONF_BASE:
-        if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
-             boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17 )
+        if ( (boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
+              boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17) &&
+              boot_cpu_data.x86_vendor != X86_VENDOR_HYGON )
             break;
         if ( !is_hardware_domain(currd) || !is_pinned_vcpu(curr) )
             return X86EMUL_OKAY;
@@ -1067,7 +1071,8 @@ static int write_msr(unsigned int reg, uint64_t val,
     case MSR_IA32_MPERF:
     case MSR_IA32_APERF:
         if ( (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) &&
-             (boot_cpu_data.x86_vendor != X86_VENDOR_AMD) )
+             (boot_cpu_data.x86_vendor != X86_VENDOR_AMD) &&
+             (boot_cpu_data.x86_vendor != X86_VENDOR_HYGON) )
             break;
         if ( likely(!is_cpufreq_controller(currd)) ||
              wrmsr_safe(reg, val) == 0 )
@@ -1100,7 +1105,9 @@ static int write_msr(unsigned int reg, uint64_t val,
             vpmu_msr = true;
     case MSR_AMD_FAM15H_EVNTSEL0 ... MSR_AMD_FAM15H_PERFCTR5:
     case MSR_K7_EVNTSEL0 ... MSR_K7_PERFCTR3:
-            if ( vpmu_msr || (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) )
+            if ( vpmu_msr ||
+                (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) ||
+                (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) )
             {
                 if ( (vpmu_mode & XENPMU_MODE_ALL) &&
                      !is_hardware_domain(currd) )
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 10/14] x86/domain: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to handle HyperTransport range.

Also loading a nul selector does not clear bases and limits on Hygon
CPUs, so add Hygon Dhyana support to the function preload_segment.

Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/dom0_build.c | 3 ++-
 xen/arch/x86/domain.c     | 9 +++++----
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 6ebe367..6178d79 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -542,7 +542,8 @@ int __init dom0_setup_permissions(struct domain *d)
                             paddr_to_pfn(MSI_ADDR_BASE_LO +
                                          MSI_ADDR_DEST_ID_MASK));
     /* HyperTransport range. */
-    if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+    if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+         boot_cpu_data.x86_vendor == X86_VENDOR_HYGON )
         rc |= iomem_deny_access(d, paddr_to_pfn(0xfdULL << 32),
                                 paddr_to_pfn((1ULL << 40) - 1));
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 8d579e2..eefe0fc 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1253,13 +1253,14 @@ arch_do_vcpu_op(
 }
 
 /*
- * Loading a nul selector does not clear bases and limits on AMD CPUs. Be on
- * the safe side and re-initialize both to flat segment values before loading
- * a nul selector.
+ * Loading a nul selector does not clear bases and limits on AMD or Hygon
+ * CPUs. Be on the safe side and re-initialize both to flat segment values
+ * before loading a nul selector.
  */
 #define preload_segment(seg, value) do {              \
     if ( !((value) & ~3) &&                           \
-         boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) \
+        (boot_cpu_data.x86_vendor == X86_VENDOR_AMD || \
+         boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) ) \
         asm volatile ( "movl %k0, %%" #seg            \
                        :: "r" (FLAT_USER_DS32) );     \
 } while ( false )
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 11/14] x86/domctl: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to update cpuid info for creating PV guest.

Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/domctl.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 9bf2d08..19b7bdd 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -176,6 +176,7 @@ static int update_domain_cpuid_info(struct domain *d,
                 break;
 
             case X86_VENDOR_AMD:
+            case X86_VENDOR_HYGON:
                 mask &= ((uint64_t)ecx << 32) | edx;
 
                 /*
@@ -220,7 +221,8 @@ static int update_domain_cpuid_info(struct domain *d,
             uint32_t eax = ctl->eax;
             uint32_t ebx = p->feat._7b0;
 
-            if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+            if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+                 boot_cpu_data.x86_vendor == X86_VENDOR_HYGON )
                 mask &= ((uint64_t)eax << 32) | ebx;
 
             d->arch.pv.cpuidmasks->_7ab0 = mask;
@@ -281,8 +283,12 @@ static int update_domain_cpuid_info(struct domain *d,
             if ( cpu_has_cmp_legacy )
                 ecx |= cpufeat_mask(X86_FEATURE_CMP_LEGACY);
 
-            /* If not emulating AMD, clear the duplicated features in e1d. */
-            if ( p->x86_vendor != X86_VENDOR_AMD )
+            /*
+             * If not emulating AMD or Hygon, clear the duplicated features
+             * in e1d.
+             */
+            if ( p->x86_vendor != X86_VENDOR_AMD &&
+                 p->x86_vendor != X86_VENDOR_HYGON )
                 edx &= ~CPUID_COMMON_1D_FEATURES;
 
             switch ( boot_cpu_data.x86_vendor )
@@ -292,6 +298,7 @@ static int update_domain_cpuid_info(struct domain *d,
                 break;
 
             case X86_VENDOR_AMD:
+            case X86_VENDOR_HYGON:
                 mask &= ((uint64_t)ecx << 32) | edx;
 
                 /*
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 12/14] x86/traps: Add Hygon Dhyana support

[Pu Wen]

The Hygon Dhyana processor has the methold to get the last exception
source IP from MSR0000_01DD. So add support for it if the boot param
ler is true.

Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/traps.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 05ddc39..97bf9e2 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1973,6 +1973,9 @@ static unsigned int calc_ler_msr(void)
             return MSR_IA32_LASTINTFROMIP;
         }
         break;
+
+    case X86_VENDOR_HYGON:
+        return MSR_IA32_LASTINTFROMIP;
     }
 
     return 0;
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 13/14] x86/cpuid: Add Hygon Dhyana support

[Pu Wen]

The Hygon Dhyana family 18h processor shares the same cpuid leaves as
the AMD family 17h one. So add Hygon Dhyana support to caculate the
cpuid policies as the AMD CPU does.

Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Jan Beulich <jbeulich@suse.com>
---
 xen/arch/x86/cpuid.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index ab0aab6..f760594 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -240,6 +240,7 @@ static void recalculate_misc(struct cpuid_policy *p)
         break;
 
     case X86_VENDOR_AMD:
+    case X86_VENDOR_HYGON:
         zero_leaves(p->basic.raw, 0x2, 0x3);
         memset(p->cache.raw, 0, sizeof(p->cache.raw));
         zero_leaves(p->basic.raw, 0x9, 0xa);
@@ -390,7 +391,8 @@ static void __init calculate_hvm_max_policy(void)
      * long mode (and init_amd() has cleared it out of host capabilities), but
      * HVM guests are able if running in protected mode.
      */
-    if ( (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
+    if ( (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+          boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) &&
          raw_cpuid_policy.basic.sep )
         __set_bit(X86_FEATURE_SEP, hvm_featureset);
 
@@ -465,7 +467,8 @@ void recalculate_cpuid_policy(struct domain *d)
     p->basic.max_leaf   = min(p->basic.max_leaf,   max->basic.max_leaf);
     p->feat.max_subleaf = min(p->feat.max_subleaf, max->feat.max_subleaf);
     p->extd.max_leaf    = 0x80000000 | min(p->extd.max_leaf & 0xffff,
-                                           (p->x86_vendor == X86_VENDOR_AMD
+                                          ((p->x86_vendor == X86_VENDOR_AMD ||
+                                            p->x86_vendor == X86_VENDOR_HYGON)
                                             ? CPUID_GUEST_NR_EXTD_AMD
                                             : CPUID_GUEST_NR_EXTD_INTEL) - 1);
 
@@ -507,7 +510,8 @@ void recalculate_cpuid_policy(struct domain *d)
     if ( is_pv_32bit_domain(d) )
     {
         __clear_bit(X86_FEATURE_LM, max_fs);
-        if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+        if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+             boot_cpu_data.x86_vendor != X86_VENDOR_HYGON )
             __clear_bit(X86_FEATURE_SYSCALL, max_fs);
     }
 
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 14/14] tools/libxc: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to caculate the cpuid policies for creating PV
or HVM guest by using the code path of AMD.

Signed-off-by: Pu Wen <puwen@hygon.cn>
Acked-by: Wei Liu <wei.liu2@citrix.com>
---
 tools/libxc/xc_cpuid_x86.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 098affe..d0cb9ae 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -234,6 +234,7 @@ struct cpuid_domain_info
         VENDOR_UNKNOWN,
         VENDOR_INTEL,
         VENDOR_AMD,
+        VENDOR_HYGON,
     } vendor;
 
     bool hvm;
@@ -304,6 +305,10 @@ static int get_cpuid_domain_info(xc_interface *xch, uint32_t domid,
               regs[2] == 0x444d4163U &&
               regs[3] == 0x69746e65U )
         info->vendor = VENDOR_AMD;
+    else if ( regs[1] == 0x6f677948U && /* "HygonGenuine" */
+              regs[2] == 0x656e6975U &&
+              regs[3] == 0x6e65476eU )
+        info->vendor = VENDOR_HYGON;
     else
         info->vendor = VENDOR_UNKNOWN;
 
@@ -568,7 +573,8 @@ static void xc_cpuid_hvm_policy(const struct cpuid_domain_info *info,
         break;
     }
 
-    if ( info->vendor == VENDOR_AMD )
+    if ( info->vendor == VENDOR_AMD ||
+         info->vendor == VENDOR_HYGON )
         amd_xc_cpuid_policy(info, input, regs);
     else
         intel_xc_cpuid_policy(info, input, regs);
@@ -630,7 +636,8 @@ static void xc_cpuid_pv_policy(const struct cpuid_domain_info *info,
 
     case 0x80000000:
     {
-        unsigned int max = info->vendor == VENDOR_AMD
+        unsigned int max = (info->vendor == VENDOR_AMD||
+                            info->vendor == VENDOR_HYGON)
             ? DEF_MAX_AMDEXT : DEF_MAX_INTELEXT;
 
         if ( regs[0] > max )
@@ -736,7 +743,8 @@ static void sanitise_featureset(struct cpuid_domain_info *info)
         if ( !info->pv64 )
         {
             clear_bit(X86_FEATURE_LM, info->featureset);
-            if ( info->vendor != VENDOR_AMD )
+            if ( info->vendor != VENDOR_AMD &&
+                 info->vendor != VENDOR_HYGON )
                 clear_bit(X86_FEATURE_SYSCALL, info->featureset);
         }
 
@@ -787,7 +795,7 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid,
     input[0] = 0x80000000;
     cpuid(input, regs);
 
-    if ( info.vendor == VENDOR_AMD )
+    if ( info.vendor == VENDOR_AMD || info.vendor == VENDOR_HYGON )
         ext_max = (regs[0] <= DEF_MAX_AMDEXT) ? regs[0] : DEF_MAX_AMDEXT;
     else
         ext_max = (regs[0] <= DEF_MAX_INTELEXT) ? regs[0] : DEF_MAX_INTELEXT;
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 01/14] x86/cpu: Create Hygon Dhyana architecture support file

[Jan Beulich]

>>> On 25.03.19 at 14:29, <puwen@hygon.cn> wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -32,11 +32,6 @@
>  static char __initdata opt_famrev[14];
>  string_param("cpuid_mask_cpu", opt_famrev);
>  
> -static unsigned int __initdata opt_cpuid_mask_l7s0_eax = ~0u;
> -integer_param("cpuid_mask_l7s0_eax", opt_cpuid_mask_l7s0_eax);
> -static unsigned int __initdata opt_cpuid_mask_l7s0_ebx = ~0u;
> -integer_param("cpuid_mask_l7s0_ebx", opt_cpuid_mask_l7s0_ebx);

This is no longer needed - all references are now local to amd.c.

> @@ -116,6 +121,9 @@ bool __init probe_cpuid_faulting(void)
>  	uint64_t val;
>  	int rc;
>  
> +	if(boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
> +		return false;
> +
>  	if ((rc = rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val)) == 0)

Isn't this similarly true for AMD, in which case adding both at the
same time in a separate patch would seem better? Yet then again -
did you look at the description of the commit moving the function
here (6e2fdc0f89 ["x86: Common cpuid faulting support"])? Hence
if anything this would need qualifying by !cpu_has_hypervisor.

Also the contextual if() tells you that there's a blank missing in the
one you add. However, there's a wider style question to raise:
This file is not a Linux clone, so generally I'd expect it to be
written in plain Xen style.

> +static void early_init_hygon(struct cpuinfo_x86 *c)
> +{
> +	early_init_amd(c);
> +}

Why the wrapper function? It can be introduced once you actually
need to do more than just the call.

> +static void init_hygon(struct cpuinfo_x86 *c)
> +{
> +	u32 l, h;

As mentioned before, please prefer uint32_t et al over u32 and
friends. While that's applicable to the entire series (and then
also to use basic types in preference to the fixed width ones,
where possible), in this particular case it would be even better if
you dropped the variables altogether, using ...

> +	unsigned long long value;
> +
> +	/* Attempt to set LFENCE to be Dispatch Serialising. */
> +	if (rdmsr_safe(MSR_AMD64_DE_CFG, value))
> +		/* Unable to read.  Assume the safer default. */
> +		__clear_bit(X86_FEATURE_LFENCE_DISPATCH, c->x86_capability);
> +	if (value & AMD64_DE_CFG_LFENCE_SERIALISE)
> +		/* Dispatch Serialising. */
> +		__set_bit(X86_FEATURE_LFENCE_DISPATCH, c->x86_capability);
> +
> +	/*
> +	 * If the user has explicitly chosen to disable Memory Disambiguation
> +	 * to mitigiate Speculative Store Bypass, poke the appropriate MSR.
> +	 */
> + 	if (opt_ssbd && !rdmsr_safe(MSR_AMD64_LS_CFG, value)) {
> +		value |= 1ull << 10;
> +		wrmsr_safe(MSR_AMD64_LS_CFG, value);
> +	}
> +
> +	display_cacheinfo(c);
> +
> +	if (cpu_has(c, X86_FEATURE_ITSC)) {
> +		__set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
> +		__set_bit(X86_FEATURE_NONSTOP_TSC, c->x86_capability);
> +		__set_bit(X86_FEATURE_TSC_RELIABLE, c->x86_capability);
> +	}
> +
> +	c->x86_max_cores = (cpuid_ecx(0x80000008) & 0xff) + 1;
> +
> +	hygon_get_topology(c);
> +
> +	/* Hygon CPUs do not support SYSENTER outside of legacy mode. */
> +	__clear_bit(X86_FEATURE_SEP, c->x86_capability);
> +
> +	/* Hygon processors have APIC timer running in deep C states. */
> +	if (opt_arat)
> +		__set_bit(X86_FEATURE_ARAT, c->x86_capability);
> +
> +	if (cpu_has(c, X86_FEATURE_EFRO)) {
> +		rdmsr(MSR_K7_HWCR, l, h);
> +		l |= (1 << 27); /* Enable read-only APERF/MPERF bit */
> +		wrmsr(MSR_K7_HWCR, l, h);
> +	}

... "value" and rdmsrl() / wrmsrl() here instead.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 03/14] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Jan Beulich]

>>> On 25.03.19 at 14:30, <puwen@hygon.cn> wrote:
> --- a/xen/arch/x86/cpu/vpmu_amd.c
> +++ b/xen/arch/x86/cpu/vpmu_amd.c
> @@ -538,13 +538,37 @@ int svm_vpmu_initialise(struct vcpu *v)
>      return 0;
>  }
>  
> -int __init amd_vpmu_init(void)
> +static int _vpmu_init(void)

Despite it having been me (I think) to have suggested this as
a possible name, now that I see it in use I don't think it's a
good choice: We're in vPMU code anyway, so the vpmu_
prefix is pretty pointless. Simply init() would be too short and
generic for my taste, so how about common_init() or
shared_init()?

> @@ -565,24 +589,25 @@ int __init amd_vpmu_init(void)
>          return -EINVAL;
>      }
>  
> -    if ( sizeof(struct xen_pmu_data) +
> -         2 * sizeof(uint64_t) * num_counters > PAGE_SIZE )
> -    {
> -        printk(XENLOG_WARNING
> -               "VPMU: Register bank does not fit into VPMU shared page\n");
> -        counters = ctrls = NULL;
> -        num_counters = 0;
> -        return -ENOSPC;
> -    }
> +    return _vpmu_init();
> +}
>  
> -    for ( i = 0; i < num_counters; i++ )
> +int __init hygon_vpmu_init(void)
> +{
> +    switch ( current_cpu_data.x86 )
>      {
> -        rdmsrl(ctrls[i], ctrl_rsvd[i]);
> -        ctrl_rsvd[i] &= CTRL_RSVD_MASK;
> +    case 0x18:
> +        num_counters = F15H_NUM_COUNTERS;
> +        counters = AMD_F15H_COUNTERS;
> +        ctrls = AMD_F15H_CTRLS;
> +        k7_counters_mirrored = 1;
> +        break;
> +    default:
> +        printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
> +               current_cpu_data.x86);
> +        return -EINVAL;
>      }

While I'm not going to insist in cases where you add to existing
switch()-es which lack such blank lines, please add a blank line
between the case blocks here. Yet then again I wonder whether
the default case wouldn't better move into the shared function
as well, keying off of e.g. num_counters still being zero.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 01/14] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

On 2019/3/26 23:49, Jan Beulich wrote:
> On 25.03.19 at 14:29, <puwen@hygon.cn> wrote:
>> -static unsigned int __initdata opt_cpuid_mask_l7s0_eax = ~0u;
>> -integer_param("cpuid_mask_l7s0_eax", opt_cpuid_mask_l7s0_eax);
>> -static unsigned int __initdata opt_cpuid_mask_l7s0_ebx = ~0u;
>> -integer_param("cpuid_mask_l7s0_ebx", opt_cpuid_mask_l7s0_ebx);
> 
> This is no longer needed - all references are now local to amd.c.

Okay, will put them back to amd.c.

>> @@ -116,6 +121,9 @@ bool __init probe_cpuid_faulting(void)
>>   	uint64_t val;
>>   	int rc;
>>   
>> +	if(boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
>> +		return false;
>> +
>>   	if ((rc = rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val)) == 0)
> 
> Isn't this similarly true for AMD, in which case adding both at the

There is no MSR_INTEL_PLATFORM_INFO for AMD family 17h and Hygon family
18h. Reading this MSR will stall on Hygon system. I don't know if it
would successfully returned when reading it on AMD system.

> same time in a separate patch would seem better? Yet then again -

In a separate patch is fine.

> did you look at the description of the commit moving the function
> here (6e2fdc0f89 ["x86: Common cpuid faulting support"])? Hence
> if anything this would need qualifying by !cpu_has_hypervisor.

Then it would be like this:
	if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON &&
	    !cpu_has_hypervisor)
		return false;

> Also the contextual if() tells you that there's a blank missing in the
> one you add. However, there's a wider style question to raise:
> This file is not a Linux clone, so generally I'd expect it to be
> written in plain Xen style.

I'm sorry for the missing blank. Okay, will use the right style.

>> +static void early_init_hygon(struct cpuinfo_x86 *c)
>> +{
>> +	early_init_amd(c);
>> +}
> 
> Why the wrapper function? It can be introduced once you actually

To keep the functions uniform Hygon ones in hygon_cpu_dev.

> need to do more than just the call.

Okay, will remove the wrapper and directly call early_init_amd().

>> +static void init_hygon(struct cpuinfo_x86 *c)
>> +{
>> +	u32 l, h;
> 
> As mentioned before, please prefer uint32_t et al over u32 and
> friends. While that's applicable to the entire series (and then
> also to use basic types in preference to the fixed width ones,

Okay.

> where possible), in this particular case it would be even better if
> you dropped the variables altogether, using ...
>> +	unsigned long long value;
...
>> +	if (cpu_has(c, X86_FEATURE_EFRO)) {
>> +		rdmsr(MSR_K7_HWCR, l, h);
>> +		l |= (1 << 27); /* Enable read-only APERF/MPERF bit */
>> +		wrmsr(MSR_K7_HWCR, l, h);
>> +	}
> 
> ... "value" and rdmsrl() / wrmsrl() here instead.

Will use rdmsrl()/wrmsrl() instead.

-- 
Regards,
Pu Wen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 03/14] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Pu Wen]

On 2019/3/27 0:10, Jan Beulich wrote:
> On 25.03.19 at 14:30, <puwen@hygon.cn> wrote:
>> --- a/xen/arch/x86/cpu/vpmu_amd.c
>> +++ b/xen/arch/x86/cpu/vpmu_amd.c
>> @@ -538,13 +538,37 @@ int svm_vpmu_initialise(struct vcpu *v)
>>       return 0;
>>   }
>>   
>> -int __init amd_vpmu_init(void)
>> +static int _vpmu_init(void)
> 
> Despite it having been me (I think) to have suggested this as
> a possible name, now that I see it in use I don't think it's a
> good choice: We're in vPMU code anyway, so the vpmu_
> prefix is pretty pointless. Simply init() would be too short and
> generic for my taste, so how about common_init() or
> shared_init()?

I prefer common_init() here.

>> -    for ( i = 0; i < num_counters; i++ )
>> +int __init hygon_vpmu_init(void)
>> +{
>> +    switch ( current_cpu_data.x86 )
>>       {
>> -        rdmsrl(ctrls[i], ctrl_rsvd[i]);
>> -        ctrl_rsvd[i] &= CTRL_RSVD_MASK;
>> +    case 0x18:
>> +        num_counters = F15H_NUM_COUNTERS;
>> +        counters = AMD_F15H_COUNTERS;
>> +        ctrls = AMD_F15H_CTRLS;
>> +        k7_counters_mirrored = 1;
>> +        break;
>> +    default:
>> +        printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
>> +               current_cpu_data.x86);
>> +        return -EINVAL;
>>       }
> 
> While I'm not going to insist in cases where you add to existing
> switch()-es which lack such blank lines, please add a blank line
> between the case blocks here. Yet then again I wonder whether
> the default case wouldn't better move into the shared function
> as well, keying off of e.g. num_counters still being zero.

I think it's a good idea to move the default case into the shared
function, which would like:
static int common_init(void)
{
     unsigned int i;

     if (!num_counters) {
         printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
                current_cpu_data.x86);
         return -EINVAL;
     }
...

Then as there is only one case in hygon_vpmu_init(), how about remove
switch()-es in this function?

-- 
Regards,
Pu Wen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 01/14] x86/cpu: Create Hygon Dhyana architecture support file

[Jan Beulich]

>>> On 27.03.19 at 09:14, <puwen@hygon.cn> wrote:
> On 2019/3/26 23:49, Jan Beulich wrote:
>> On 25.03.19 at 14:29, <puwen@hygon.cn> wrote:
>>> @@ -116,6 +121,9 @@ bool __init probe_cpuid_faulting(void)
>>>   	uint64_t val;
>>>   	int rc;
>>>   
>>> +	if(boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
>>> +		return false;
>>> +
>>>   	if ((rc = rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val)) == 0)
>> 
>> Isn't this similarly true for AMD, in which case adding both at the
> 
> There is no MSR_INTEL_PLATFORM_INFO for AMD family 17h and Hygon family
> 18h. Reading this MSR will stall on Hygon system. I don't know if it
> would successfully returned when reading it on AMD system.

What do you mean by "stall"? Reading an unimplemented MSR
should produce #GP(0).

>> same time in a separate patch would seem better? Yet then again -
> 
> In a separate patch is fine.
> 
>> did you look at the description of the commit moving the function
>> here (6e2fdc0f89 ["x86: Common cpuid faulting support"])? Hence
>> if anything this would need qualifying by !cpu_has_hypervisor.
> 
> Then it would be like this:
> 	if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON &&
> 	    !cpu_has_hypervisor)
> 		return false;

Right, plus perhaps said AMD addition, unless Andrew objects to it
for some reason.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 03/14] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Jan Beulich]

>>> On 27.03.19 at 09:16, <puwen@hygon.cn> wrote:
> On 2019/3/27 0:10, Jan Beulich wrote:
>> On 25.03.19 at 14:30, <puwen@hygon.cn> wrote:
>>> -    for ( i = 0; i < num_counters; i++ )
>>> +int __init hygon_vpmu_init(void)
>>> +{
>>> +    switch ( current_cpu_data.x86 )
>>>       {
>>> -        rdmsrl(ctrls[i], ctrl_rsvd[i]);
>>> -        ctrl_rsvd[i] &= CTRL_RSVD_MASK;
>>> +    case 0x18:
>>> +        num_counters = F15H_NUM_COUNTERS;
>>> +        counters = AMD_F15H_COUNTERS;
>>> +        ctrls = AMD_F15H_CTRLS;
>>> +        k7_counters_mirrored = 1;
>>> +        break;
>>> +    default:
>>> +        printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
>>> +               current_cpu_data.x86);
>>> +        return -EINVAL;
>>>       }
>> 
>> While I'm not going to insist in cases where you add to existing
>> switch()-es which lack such blank lines, please add a blank line
>> between the case blocks here. Yet then again I wonder whether
>> the default case wouldn't better move into the shared function
>> as well, keying off of e.g. num_counters still being zero.
> 
> I think it's a good idea to move the default case into the shared
> function, which would like:
> static int common_init(void)
> {
>      unsigned int i;
> 
>      if (!num_counters) {
>          printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
>                 current_cpu_data.x86);
>          return -EINVAL;
>      }
> ...
> 
> Then as there is only one case in hygon_vpmu_init(), how about remove
> switch()-es in this function?

Well, personally I'd prefer to keep the switch(), as that what's
going to be needed once you introduce a second model, but I
won't insist.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 01/14] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

On 2019/3/27 16:31, Jan Beulich wrote:
> On 27.03.19 at 09:14, <puwen@hygon.cn> wrote:
>> On 2019/3/26 23:49, Jan Beulich wrote:
>>> On 25.03.19 at 14:29, <puwen@hygon.cn> wrote:
>>>> @@ -116,6 +121,9 @@ bool __init probe_cpuid_faulting(void)
>>>>    	uint64_t val;
>>>>    	int rc;
>>>>    
>>>> +	if(boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
>>>> +		return false;
>>>> +
>>>>    	if ((rc = rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val)) == 0)
>>>
>>> Isn't this similarly true for AMD, in which case adding both at the
>>
>> There is no MSR_INTEL_PLATFORM_INFO for AMD family 17h and Hygon family
>> 18h. Reading this MSR will stall on Hygon system. I don't know if it
>> would successfully returned when reading it on AMD system.
> 
> What do you mean by "stall"? Reading an unimplemented MSR
> should produce #GP(0).

On certain old Hygon system there is no #GP produced. And the Xen
initialization process is stopped.

Beyond that it will indeed produce:
"traps.c:1574: GPF (0000)"
and return false from the last if() conditional.

>>> same time in a separate patch would seem better? Yet then again -
>>
>> In a separate patch is fine.
>>
>>> did you look at the description of the commit moving the function
>>> here (6e2fdc0f89 ["x86: Common cpuid faulting support"])? Hence
>>> if anything this would need qualifying by !cpu_has_hypervisor.
>>
>> Then it would be like this:
>> 	if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON &&
>> 	    !cpu_has_hypervisor)
>> 		return false;
> 
> Right, plus perhaps said AMD addition, unless Andrew objects to it
> for some reason.

Then it would be like this:
	if ((boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ||
	     boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
	    !cpu_has_hypervisor)
		return false;

Andrew, any objections?

-- 
Regards,
Pu Wen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 03/14] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Pu Wen]

On 2019/3/27 16:38, Jan Beulich wrote:
> On 27.03.19 at 09:16, <puwen@hygon.cn> wrote:
>> On 2019/3/27 0:10, Jan Beulich wrote:
>>> On 25.03.19 at 14:30, <puwen@hygon.cn> wrote:
>>>> +    default:
>>>> +        printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
>>>> +               current_cpu_data.x86);
>>>> +        return -EINVAL;
>>>>        }
>>>
>>> While I'm not going to insist in cases where you add to existing
>>> switch()-es which lack such blank lines, please add a blank line
>>> between the case blocks here. Yet then again I wonder whether
>>> the default case wouldn't better move into the shared function
>>> as well, keying off of e.g. num_counters still being zero.
>>
>> Then as there is only one case in hygon_vpmu_init(), how about remove
>> switch()-es in this function?
> 
> Well, personally I'd prefer to keep the switch(), as that what's
> going to be needed once you introduce a second model, but I
> won't insist.

Keeping the switch() is also fine to me.

-- 
Regards,
Pu Wen



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel