[PATCH v4 00/15] Add support for Hygon Dhyana Family 18h processor

[PATCH v4 00/15] 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


v3->v4:
  - Revert opt_cpuid_mask_l7s0_(eax/ebx) to amd.c.
  - Create a separate patch to fix common cpuid faulting probing issue
    for AMD and Hygon.
  - Rename _vpmu_init() to common_init() and move the default case into it.
  - Coding style refine.

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 (15):
  x86/cpu: Create Hygon Dhyana architecture support file
  x86/cpu: Fix common cpuid faulting probing for AMD and Hygon
  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                 |  2 +-
 xen/arch/x86/cpu/common.c              |  9 +++-
 xen/arch/x86/cpu/cpu.h                 |  3 ++
 xen/arch/x86/cpu/hygon.c               | 92 ++++++++++++++++++++++++++++++++++
 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            | 60 +++++++++++++++-------
 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, 244 insertions(+), 57 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 v4 01/15] 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.

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            |  2 +-
 xen/arch/x86/cpu/common.c         |  1 +
 xen/arch/x86/cpu/cpu.h            |  3 ++
 xen/arch/x86/cpu/hygon.c          | 92 +++++++++++++++++++++++++++++++++++++++
 xen/include/asm-x86/x86-vendors.h |  3 +-
 6 files changed, 100 insertions(+), 2 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..061ebdc 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -526,7 +526,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..db1ebf1 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -710,6 +710,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..6c52a56 100644
--- a/xen/arch/x86/cpu/cpu.h
+++ b/xen/arch/x86/cpu/cpu.h
@@ -17,7 +17,10 @@ extern unsigned int opt_cpuid_mask_ext_ecx, opt_cpuid_mask_ext_edx;
 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..7ccbd84
--- /dev/null
+++ b/xen/arch/x86/cpu/hygon.c
@@ -0,0 +1,92 @@
+#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)
+{
+	unsigned int 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 init_hygon(struct cpuinfo_x86 *c)
+{
+	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))
+	{
+		rdmsrl(MSR_K7_HWCR, value);
+		value |= (1 << 27); /* Enable read-only APERF/MPERF bit */
+		wrmsrl(MSR_K7_HWCR, value);
+	}
+}
+
+static const struct cpu_dev hygon_cpu_dev = {
+	.c_vendor	= "Hygon",
+	.c_ident 	= { "HygonGenuine" },
+	.c_early_init	= early_init_amd,
+	.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 v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Pu Wen]

There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.

Signed-off-by: Pu Wen <puwen@hygon.cn>
---
 xen/arch/x86/cpu/common.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index db1ebf1..a08d48f 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -116,6 +116,11 @@ bool __init probe_cpuid_faulting(void)
 	uint64_t val;
 	int rc;
 
+	if ((boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ||
+	     boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
+	    !cpu_has_hypervisor)
+		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;
-- 
2.7.4


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

[PATCH v4 03/15] 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 v4 04/15] 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 AMD 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 | 60 +++++++++++++++++++++++++++++++--------------
 xen/include/asm-x86/vpmu.h  |  1 +
 3 files changed, 48 insertions(+), 18 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..47911e5 100644
--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -538,28 +538,12 @@ int svm_vpmu_initialise(struct vcpu *v)
     return 0;
 }
 
-int __init amd_vpmu_init(void)
+static int common_init(void)
 {
     unsigned int i;
 
-    switch ( current_cpu_data.x86 )
+    if (!num_counters)
     {
-    case 0x15:
-        num_counters = F15H_NUM_COUNTERS;
-        counters = AMD_F15H_COUNTERS;
-        ctrls = AMD_F15H_CTRLS;
-        k7_counters_mirrored = 1;
-        break;
-    case 0x10:
-    case 0x12:
-    case 0x14:
-    case 0x16:
-        num_counters = F10H_NUM_COUNTERS;
-        counters = AMD_F10H_COUNTERS;
-        ctrls = AMD_F10H_CTRLS;
-        k7_counters_mirrored = 0;
-        break;
-    default:
         printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
                current_cpu_data.x86);
         return -EINVAL;
@@ -586,3 +570,43 @@ int __init amd_vpmu_init(void)
     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;
+        k7_counters_mirrored = 1;
+        break;
+    case 0x10:
+    case 0x12:
+    case 0x14:
+    case 0x16:
+        num_counters = F10H_NUM_COUNTERS;
+        counters = AMD_F10H_COUNTERS;
+        ctrls = AMD_F10H_CTRLS;
+        k7_counters_mirrored = 0;
+        break;
+    }
+
+    return common_init();
+}
+
+int __init hygon_vpmu_init(void)
+{
+    switch ( current_cpu_data.x86 )
+    {
+    case 0x18:
+        num_counters = F15H_NUM_COUNTERS;
+        counters = AMD_F15H_COUNTERS;
+        ctrls = AMD_F15H_CTRLS;
+        k7_counters_mirrored = 1;
+        break;
+    }
+
+    return common_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 v4 05/15] 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 a08d48f..0246670 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -350,7 +350,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 v4 06/15] 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 v4 07/15] 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 v4 08/15] 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 v4 09/15] 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 v4 10/15] 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 v4 11/15] 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 v4 12/15] 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 v4 13/15] 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 v4 14/15] 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 v4 15/15] 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 v4 04/15] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Jan Beulich]

>>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
> @@ -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;

While I realize they're missing right now, I would have appreciated
if you had taken the opportunity to add the missing blank lines
between case blocks here.

> --- a/xen/arch/x86/cpu/vpmu_amd.c
> +++ b/xen/arch/x86/cpu/vpmu_amd.c
> @@ -538,28 +538,12 @@ int svm_vpmu_initialise(struct vcpu *v)
>      return 0;
>  }
>  
> -int __init amd_vpmu_init(void)
> +static int common_init(void)

__init

>  {
>      unsigned int i;
>  
> -    switch ( current_cpu_data.x86 )
> +    if (!num_counters)

Style (missing blanks).

> @@ -586,3 +570,43 @@ int __init amd_vpmu_init(void)
>      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;
> +        k7_counters_mirrored = 1;
> +        break;
> +    case 0x10:

Same as above.

I won't insist on the first item getting addressed, but the other
three should be. They're all mechanical, so could be done while
committing, and with them in place
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan



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

Re: [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Jan Beulich]

>>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.

I think it would have been nice if you had mentioned the real
reason why you want to bypass the MSR accesses. This way it
sounds as if the change was only cosmetic, and hence could be
left out.

> Signed-off-by: Pu Wen <puwen@hygon.cn>

Acked-by: Jan Beulich <jbeulich@suse.com>

Andrew, I'd like to ask for explicit clarification that you don't object
to this adjustment. But if you do, please clarify why.

Thanks, Jan

> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -116,6 +116,11 @@ bool __init probe_cpuid_faulting(void)
>  	uint64_t val;
>  	int rc;
>  
> +	if ((boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ||
> +	     boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
> +	    !cpu_has_hypervisor)
> +		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;
> -- 
> 2.7.4





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

Re: [PATCH v4 04/15] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Pu Wen]

On 2019/4/1 16:36, Jan Beulich wrote:
> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>> @@ -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;
> 
> While I realize they're missing right now, I would have appreciated
> if you had taken the opportunity to add the missing blank lines
> between case blocks here.

Okay, will add the missing blank lines in next version patch series.

>> --- a/xen/arch/x86/cpu/vpmu_amd.c
>> +++ b/xen/arch/x86/cpu/vpmu_amd.c
>> @@ -538,28 +538,12 @@ int svm_vpmu_initialise(struct vcpu *v)
>>       return 0;
>>   }
>>   
>> -int __init amd_vpmu_init(void)
>> +static int common_init(void)
> 
> __init

Okay, will add it in front of int.

>>   {
>>       unsigned int i;
>>   
>> -    switch ( current_cpu_data.x86 )
>> +    if (!num_counters)
> 
> Style (missing blanks).

Will add the missing blanks.

>> +    case 0x17:
>> +        num_counters = F15H_NUM_COUNTERS;
>> +        counters = AMD_F15H_COUNTERS;
>> +        ctrls = AMD_F15H_CTRLS;
>> +        k7_counters_mirrored = 1;
>> +        break;
>> +    case 0x10:
> 
> Same as above.

Will add a blank line on top of "case 0x10".

> I won't insist on the first item getting addressed, but the other
> three should be. They're all mechanical, so could be done while
> committing, and with them in place
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thanks.

-- 
Regards,
Pu Wen


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

Re: [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Pu Wen]

On 2019/4/1 16:41, Jan Beulich wrote:
> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
>> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
> 
> I think it would have been nice if you had mentioned the real
> reason why you want to bypass the MSR accesses. This way it
> sounds as if the change was only cosmetic, and hence could be
> left out.

Okay, how about the new description:
There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
this MSR will stop the Xen initialization process or produce GPF(0).
So directly return false in the function probe_cpuid_faulting() if
!cpu_has_hypervisor.

-- 
Regards,
Pu Wen

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

Re: [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Jan Beulich]

>>> On 02.04.19 at 08:46, <puwen@hygon.cn> wrote:
> On 2019/4/1 16:41, Jan Beulich wrote:
>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
>>> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
>> 
>> I think it would have been nice if you had mentioned the real
>> reason why you want to bypass the MSR accesses. This way it
>> sounds as if the change was only cosmetic, and hence could be
>> left out.
> 
> Okay, how about the new description:
> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
> this MSR will stop the Xen initialization process

"... for some early Hygon steppings"(?). I'm unaware of AMD CPUs
having this issue - are you telling us otherwise?

Jan

> or produce GPF(0).
> So directly return false in the function probe_cpuid_faulting() if
> !cpu_has_hypervisor.
> 
> -- 
> Regards,
> Pu Wen





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

Re: [PATCH v4 04/15] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Jan Beulich]

>>> On 02.04.19 at 08:46, <puwen@hygon.cn> wrote:
> On 2019/4/1 16:36, Jan Beulich wrote:
>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>>> --- a/xen/arch/x86/cpu/vpmu_amd.c
>>> +++ b/xen/arch/x86/cpu/vpmu_amd.c
>>> @@ -538,28 +538,12 @@ int svm_vpmu_initialise(struct vcpu *v)
>>>       return 0;
>>>   }
>>>   
>>> -int __init amd_vpmu_init(void)
>>> +static int common_init(void)
>> 
>> __init
> 
> Okay, will add it in front of int.

Why in front of int? The old line of code here shows the canonical
ordering we use.

Jan



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

Re: [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Andrew Cooper]

On 01/04/2019 09:40, Jan Beulich wrote:
>>>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
>> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
> I think it would have been nice if you had mentioned the real
> reason why you want to bypass the MSR accesses. This way it
> sounds as if the change was only cosmetic, and hence could be
> left out.
>
>> Signed-off-by: Pu Wen <puwen@hygon.cn>
> Acked-by: Jan Beulich <jbeulich@suse.com>
>
> Andrew, I'd like to ask for explicit clarification that you don't object
> to this adjustment. But if you do, please clarify why.

We deliberately emulate MSR_INTEL_PLATFORM_INFO on all systems

This is to support pv-shim, so the L1 Xen can exert faulting control
over the L2 PV guest, so L2 doesn't see L1's HVM CPUID leaves and choke.

I suppose its fine to have a !cpu_has_hypervisor exclusion for non-Intel
systems, but I also don't see much value in it.

~Andrew

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

Re: [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Pu Wen]

On 2019/4/2 18:20, Jan Beulich wrote:
> On 02.04.19 at 08:46, <puwen@hygon.cn> wrote:
>> On 2019/4/1 16:41, Jan Beulich wrote:
>>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
>>>> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
>>>
>>> I think it would have been nice if you had mentioned the real
>>> reason why you want to bypass the MSR accesses. This way it
>>> sounds as if the change was only cosmetic, and hence could be
>>> left out.
>>
>> Okay, how about the new description:
>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
>> this MSR will stop the Xen initialization process
> 
> "... for some early Hygon steppings"(?). I'm unaware of AMD CPUs

Yes,for some early Hygon steppings.

> having this issue - are you telling us otherwise?

I tested with an AMD CPU(Family 17h, Model 1, Stepping 1) today, and
it also stopped when reading the MSR_INTEL_PLATFORM_INFO instead of
producing #GP(0).

-- 
Regards,
Pu Wen


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

Re: [PATCH v4 04/15] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Pu Wen]

On 2019/4/2 18:21, Jan Beulich wrote:
> On 02.04.19 at 08:46, <puwen@hygon.cn> wrote:
>> On 2019/4/1 16:36, Jan Beulich wrote:
>>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>>>> --- a/xen/arch/x86/cpu/vpmu_amd.c
>>>> +++ b/xen/arch/x86/cpu/vpmu_amd.c
>>>> @@ -538,28 +538,12 @@ int svm_vpmu_initialise(struct vcpu *v)
>>>>        return 0;
>>>>    }
>>>>    
>>>> -int __init amd_vpmu_init(void)
>>>> +static int common_init(void)
>>>
>>> __init
>>
>> Okay, will add it in front of int.
> 
> Why in front of int? The old line of code here shows the canonical
> ordering we use.

Sorry, after int. :)

By the way, how about the patch 01/15 of this series?
If it's fine, could you please offer Acked-by tag for it?

-- 
Regards,
Pu Wen

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

Re: [PATCH v4 01/15] x86/cpu: Create Hygon Dhyana architecture support file

[Andrew Cooper]

On 30/03/2019 10:42, Pu Wen wrote:
> +static const struct cpu_dev hygon_cpu_dev = {
> +	.c_vendor	= "Hygon",
> +	.c_ident 	= { "HygonGenuine" },
> +	.c_early_init	= early_init_amd,
> +	.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

This change will need rebasing over
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e72309ffbe7c4e507649c74749f130cda691131c
, which has dropped the .c_ident field for a more efficient lookup
mechanism.

Hopefully the adjustments are all obvious.  If not, I can draft a patch.

~Andrew

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

Re: [PATCH v4 01/15] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

On 2019/4/2 20:16, Andrew Cooper wrote:
> On 30/03/2019 10:42, Pu Wen wrote:
>> +static const struct cpu_dev hygon_cpu_dev = {
>> +	.c_vendor	= "Hygon",
>> +	.c_ident 	= { "HygonGenuine" },
>> +	.c_early_init	= early_init_amd,
>> +	.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
> 
> This change will need rebasing over
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e72309ffbe7c4e507649c74749f130cda691131c
> , which has dropped the .c_ident field for a more efficient lookup

Oh, this is already in the staging branch!

> mechanism.
> 
> Hopefully the adjustments are all obvious.  If not, I can draft a patch.

I'll try to rework this patch rebasing over the latest staging branch
for your review. Thanks.

-- 
Regards,
Pu Wen

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

Re: [PATCH v4 00/15] Add support for Hygon Dhyana Family 18h processor

[Andrew Cooper]

On 30/03/2019 10:40, Pu Wen wrote:
> 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

One thing I don't see in this series is anything about microcode
loading.  Presumably you'll follow the AMD patchloading mechanism, with
a blob you provide yourself?

~Andrew

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

Re: [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Jan Beulich]

>>> On 02.04.19 at 12:30, <andrew.cooper3@citrix.com> wrote:
> On 01/04/2019 09:40, Jan Beulich wrote:
>>>>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
>>> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
>> I think it would have been nice if you had mentioned the real
>> reason why you want to bypass the MSR accesses. This way it
>> sounds as if the change was only cosmetic, and hence could be
>> left out.
>>
>>> Signed-off-by: Pu Wen <puwen@hygon.cn>
>> Acked-by: Jan Beulich <jbeulich@suse.com>
>>
>> Andrew, I'd like to ask for explicit clarification that you don't object
>> to this adjustment. But if you do, please clarify why.
> 
> We deliberately emulate MSR_INTEL_PLATFORM_INFO on all systems
> 
> This is to support pv-shim, so the L1 Xen can exert faulting control
> over the L2 PV guest, so L2 doesn't see L1's HVM CPUID leaves and choke.
> 
> I suppose its fine to have a !cpu_has_hypervisor exclusion for non-Intel
> systems, but I also don't see much value in it.

But you've see Pu Wen's explanation (of their CPUs hanging on that
RDMSR is attempted)? In a later reply he even claims that this also
happens on some AMD CPUs.

Jan



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

Re: [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Jan Beulich]

>>> On 02.04.19 at 13:58, <puwen@hygon.cn> wrote:
> On 2019/4/2 18:20, Jan Beulich wrote:
>> On 02.04.19 at 08:46, <puwen@hygon.cn> wrote:
>>> On 2019/4/1 16:41, Jan Beulich wrote:
>>>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>>>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
>>>>> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
>>>>
>>>> I think it would have been nice if you had mentioned the real
>>>> reason why you want to bypass the MSR accesses. This way it
>>>> sounds as if the change was only cosmetic, and hence could be
>>>> left out.
>>>
>>> Okay, how about the new description:
>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
>>> this MSR will stop the Xen initialization process
>> 
>> "... for some early Hygon steppings"(?). I'm unaware of AMD CPUs
> 
> Yes,for some early Hygon steppings.
> 
>> having this issue - are you telling us otherwise?
> 
> I tested with an AMD CPU(Family 17h, Model 1, Stepping 1) today, and
> it also stopped when reading the MSR_INTEL_PLATFORM_INFO instead of
> producing #GP(0).

I've yet to try it out on my Rome system, but I have to admit I
find this hard to believe. Andrew - you've tried to boot Xen on a
Rome already. Iirc you said it crashed, but did it perhaps get to
(and past) this point?

Jan



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

Re: [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Andrew Cooper]

On 02/04/2019 16:46, Jan Beulich wrote:
>>>> On 02.04.19 at 13:58, <puwen@hygon.cn> wrote:
>> On 2019/4/2 18:20, Jan Beulich wrote:
>>> On 02.04.19 at 08:46, <puwen@hygon.cn> wrote:
>>>> On 2019/4/1 16:41, Jan Beulich wrote:
>>>>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>>>>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
>>>>>> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
>>>>> I think it would have been nice if you had mentioned the real
>>>>> reason why you want to bypass the MSR accesses. This way it
>>>>> sounds as if the change was only cosmetic, and hence could be
>>>>> left out.
>>>> Okay, how about the new description:
>>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
>>>> this MSR will stop the Xen initialization process
>>> "... for some early Hygon steppings"(?). I'm unaware of AMD CPUs
>> Yes,for some early Hygon steppings.
>>
>>> having this issue - are you telling us otherwise?
>> I tested with an AMD CPU(Family 17h, Model 1, Stepping 1) today, and
>> it also stopped when reading the MSR_INTEL_PLATFORM_INFO instead of
>> producing #GP(0).
> I've yet to try it out on my Rome system, but I have to admit I
> find this hard to believe. Andrew - you've tried to boot Xen on a
> Rome already. Iirc you said it crashed, but did it perhaps get to
> (and past) this point?

I've got Fam10, 15, 17 (both Naples and Rome) and haven't encountered
any problems.

Whatever is going on, it sounds like a microcode bug.

~Andrew

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

Re: [PATCH v4 04/15] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Jan Beulich]

>>> On 02.04.19 at 14:11, <puwen@hygon.cn> wrote:
> By the way, how about the patch 01/15 of this series?
> If it's fine, could you please offer Acked-by tag for it?

I've yet to look at v4 of it.

Jan



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

Re: [PATCH v4 00/15] Add support for Hygon Dhyana Family 18h processor

[Pu Wen]

On 2019/4/2 23:14, Andrew Cooper wrote:
> On 30/03/2019 10:40, Pu Wen wrote:
>> 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
> 
> One thing I don't see in this series is anything about microcode

Right now Hygon load microcode in BIOS.

> loading.  Presumably you'll follow the AMD patchloading mechanism, with
> a blob you provide yourself?

We are exploring the Hygon patchloading mechanism, which will employ 
most of the functions of AMD's. We also try to make the Hygon microcode 
blob be compatible with the AMD one.

When the Hygon patchloading mechanism is practicable and it's necessary 
to load the Hygon microcode outside of BIOS, we'll send the patchloading 
patches to Xen and Linux mailing lists.

Thx.

-- 
Regards,
Pu Wen

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

Re: [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Pu Wen]

On 2019/4/2 23:46, Jan Beulich wrote:
> On 02.04.19 at 13:58, <puwen@hygon.cn> wrote:
>> On 2019/4/2 18:20, Jan Beulich wrote:
>>> On 02.04.19 at 08:46, <puwen@hygon.cn> wrote:
>>>> On 2019/4/1 16:41, Jan Beulich wrote:
>>>>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>>>>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
>>>>>> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
>>>>>
>>>>> I think it would have been nice if you had mentioned the real
>>>>> reason why you want to bypass the MSR accesses. This way it
>>>>> sounds as if the change was only cosmetic, and hence could be
>>>>> left out.
>>>>
>>>> Okay, how about the new description:
>>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
>>>> this MSR will stop the Xen initialization process
>>>
>>> "... for some early Hygon steppings"(?). I'm unaware of AMD CPUs
>>
>> Yes,for some early Hygon steppings.
>>
>>> having this issue - are you telling us otherwise?
>>
>> I tested with an AMD CPU(Family 17h, Model 1, Stepping 1) today, and
>> it also stopped when reading the MSR_INTEL_PLATFORM_INFO instead of
>> producing #GP(0).
> 
> I've yet to try it out on my Rome system, but I have to admit I

We have Rome system too, I'll have a try on it as well.

> find this hard to believe. Andrew - you've tried to boot Xen on a
> Rome already. Iirc you said it crashed, but did it perhaps get to
> (and past) this point?

-- 
Regards,
Pu Wen

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

Re: [PATCH v4 00/15] Add support for Hygon Dhyana Family 18h processor

[Jan Beulich]

>>> On 02.04.19 at 18:00, <puwen@hygon.cn> wrote:
> On 2019/4/2 23:14, Andrew Cooper wrote:
>> On 30/03/2019 10:40, Pu Wen wrote:
>>> 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
>> 
>> One thing I don't see in this series is anything about microcode
> 
> Right now Hygon load microcode in BIOS.
> 
>> loading.  Presumably you'll follow the AMD patchloading mechanism, with
>> a blob you provide yourself?
> 
> We are exploring the Hygon patchloading mechanism, which will employ 
> most of the functions of AMD's. We also try to make the Hygon microcode 
> blob be compatible with the AMD one.
> 
> When the Hygon patchloading mechanism is practicable and it's necessary 
> to load the Hygon microcode outside of BIOS, we'll send the patchloading 
> patches to Xen and Linux mailing lists.

I suppose both Intel and AMD had this same intention of ucode loading
being a firmware job only, and we see where we are right now. As long
as updated firmware does not become available in a timely manner (or
perhaps not at all, because of a vendor considering a certain system
EOL), there's going to be a need to be able to load it from the OS.

Jan



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

Re: [PATCH v4 04/15] x86/cpu/vpmu: Add Hygon Dhyana and AMD Zen support for vPMU

[Pu Wen]

On 2019/4/2 23:50, Jan Beulich wrote:
>>>> On 02.04.19 at 14:11, <puwen@hygon.cn> wrote:
>> By the way, how about the patch 01/15 of this series?
>> If it's fine, could you please offer Acked-by tag for it?
> 
> I've yet to look at v4 of it.

Andrew said the change of patch 01/15 should rebase over
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e72309ffbe7c4e507649c74749f130cda691131c
.

So I think I'll rework the patch first.

Thx.

-- 
Regards,
Pu Wen

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

Re: [PATCH v4 02/15] x86/cpu: Fix common cpuid faulting probing for AMD and Hygon

[Andrew Cooper]

On 02/04/2019 17:14, Pu Wen wrote:
> On 2019/4/2 23:46, Jan Beulich wrote:
>> On 02.04.19 at 13:58, <puwen@hygon.cn> wrote:
>>> On 2019/4/2 18:20, Jan Beulich wrote:
>>>> On 02.04.19 at 08:46, <puwen@hygon.cn> wrote:
>>>>> On 2019/4/1 16:41, Jan Beulich wrote:
>>>>>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>>>>>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families.
>>>>>>> So directly
>>>>>>> return false in the function probe_cpuid_faulting() if
>>>>>>> !cpu_has_hypervisor.
>>>>>>
>>>>>> I think it would have been nice if you had mentioned the real
>>>>>> reason why you want to bypass the MSR accesses. This way it
>>>>>> sounds as if the change was only cosmetic, and hence could be
>>>>>> left out.
>>>>>
>>>>> Okay, how about the new description:
>>>>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. Read
>>>>> this MSR will stop the Xen initialization process
>>>>
>>>> "... for some early Hygon steppings"(?). I'm unaware of AMD CPUs
>>>
>>> Yes,for some early Hygon steppings.
>>>
>>>> having this issue - are you telling us otherwise?
>>>
>>> I tested with an AMD CPU(Family 17h, Model 1, Stepping 1) today, and
>>> it also stopped when reading the MSR_INTEL_PLATFORM_INFO instead of
>>> producing #GP(0).
>>
>> I've yet to try it out on my Rome system, but I have to admit I
>
> We have Rome system too, I'll have a try on it as well.

I've just spoken to a contact at AMD, and they've never encountered an
issue like this.

If it behaviour does manifest, then it is very concerning.

~Andrew

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

Re: [PATCH v4 01/15] x86/cpu: Create Hygon Dhyana architecture support file

[Jan Beulich]

>>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
> +static void init_hygon(struct cpuinfo_x86 *c)
> +{
> +	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);

This still isn't in line with the AMD code it was derived from. In
particular code and comment do not match up: You don't make any
attempt to actually _set_ the intended mode, you only record the
setting found in the feature flags.

> +	/*
> +	 * 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))
> + 	{

Since you've decided to inherit style from amd.c, the opening brace
belongs on the previous line (more instances further down).

> +		value |= 1ull << 10;
> +		wrmsr_safe(MSR_AMD64_LS_CFG, value);
> +	}
> +
> +	display_cacheinfo(c);

Above from here amd.c sets MFENCE_RDTSC as well. Why would
this not be needed for Hygon?

> +	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);
> +	}

There is a CPUID extended level check around this and ...

> +	c->x86_max_cores = (cpuid_ecx(0x80000008) & 0xff) + 1;

... also around this in the AMD original. Why did you drop this?
Please don't forget that we may run virtualized ourselves, and
that the respective leaves may have got hidden by the lower
level hypervisor.

Jan



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

Re: [PATCH v4 01/15] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

On 2019/4/3 16:43, Jan Beulich wrote:
> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>> +static void init_hygon(struct cpuinfo_x86 *c)
>> +{
>> +	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);
> 
> This still isn't in line with the AMD code it was derived from. In
> particular code and comment do not match up: You don't make any
> attempt to actually _set_ the intended mode, you only record the
> setting found in the feature flags.

The code is derived but not fully copied. I tested the conditionals and 
found that the other branches are not reached on Hygon platforms, so I 
removed them.

Our firmware will make sure that the bit AMD64_DE_CFG_LFENCE_SERIALISE 
will be set. So I just check here instead of setting. If you think 
retaining all the original conditionals is better, I'll do that. :)

>> +	/*
>> +	 * 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))
>> + 	{
> 
> Since you've decided to inherit style from amd.c, the opening brace
> belongs on the previous line (more instances further down).

I'm a little confused about which style to follow? In v3 series I 
followed the style of the derived code. But in other patch you told me 
to follow the Xen coding style, so in v4 series I changed the style to 
match the bracing section of CODING_STYLE.

Anyway I can still inherit the style from amd.c.

>> +		value |= 1ull << 10;
>> +		wrmsr_safe(MSR_AMD64_LS_CFG, value);
>> +	}
>> +
>> +	display_cacheinfo(c);
> 
> Above from here amd.c sets MFENCE_RDTSC as well. Why would
> this not be needed for Hygon?

Because Hygon has feature LFENCE_DISPATCH, so the feature MFENCE_RDTSC 
will not be set here.

But if you think the conditional should be retained here for some reason 
(even though the conditional may not be touched), I'll add it.

>> +	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);
>> +	}
> 
> There is a CPUID extended level check around this and ...
> 
>> +	c->x86_max_cores = (cpuid_ecx(0x80000008) & 0xff) + 1;
> 
> ... also around this in the AMD original. Why did you drop this?

The reason is somehow the same as the explanations above. Hygon CPU 
always has CPUID extended level, so I think there is no need to check it 
here.

Different from AMD, which has many old families without the CPUID 
extended level, Hygon CPU is derived from AMD family 17h and always has 
the extended features.

> Please don't forget that we may run virtualized ourselves, and
> that the respective leaves may have got hidden by the lower
> level hypervisor.

I think this is the most important reason. Previously I only considered 
to run Hygon Xen on bare hardware, which is the most important usage for 
a server processor. To match all the using cases I'll add the checking 
you mentioned above.

-- 
Regards,
Pu Wen

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

Re: [PATCH v4 01/15] x86/cpu: Create Hygon Dhyana architecture support file

[Jan Beulich]

>>> On 03.04.19 at 12:05, <puwen@hygon.cn> wrote:
> On 2019/4/3 16:43, Jan Beulich wrote:
>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>>> +static void init_hygon(struct cpuinfo_x86 *c)
>>> +{
>>> +	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);
>> 
>> This still isn't in line with the AMD code it was derived from. In
>> particular code and comment do not match up: You don't make any
>> attempt to actually _set_ the intended mode, you only record the
>> setting found in the feature flags.
> 
> The code is derived but not fully copied. I tested the conditionals and 
> found that the other branches are not reached on Hygon platforms, so I 
> removed them.
> 
> Our firmware will make sure that the bit AMD64_DE_CFG_LFENCE_SERIALISE 
> will be set. So I just check here instead of setting. If you think 
> retaining all the original conditionals is better, I'll do that. :)

I'm not convinced you need to retain everything, but you surely
shouldn't limit code to work just on your specific variant of
firmware.

>>> +	/*
>>> +	 * 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))
>>> + 	{
>> 
>> Since you've decided to inherit style from amd.c, the opening brace
>> belongs on the previous line (more instances further down).
> 
> I'm a little confused about which style to follow? In v3 series I 
> followed the style of the derived code. But in other patch you told me 
> to follow the Xen coding style, so in v4 series I changed the style to 
> match the bracing section of CODING_STYLE.

Well, taking just the brace placement part doesn't make this
the file Xen style. In my earlier response to that style
question I did suggest you switch to Xen style for the new
file. I'd still view this as the preferred option, but then all
aspects should be taken care of. But I won't insist, yet in that
case clean Linux style is the only other alternative.

>>> +		value |= 1ull << 10;
>>> +		wrmsr_safe(MSR_AMD64_LS_CFG, value);
>>> +	}
>>> +
>>> +	display_cacheinfo(c);
>> 
>> Above from here amd.c sets MFENCE_RDTSC as well. Why would
>> this not be needed for Hygon?
> 
> Because Hygon has feature LFENCE_DISPATCH, so the feature MFENCE_RDTSC 
> will not be set here.
> 
> But if you think the conditional should be retained here for some reason 
> (even though the conditional may not be touched), I'll add it.

See above - yes, I think it should be retained.

Jan



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

Re: [PATCH v4 00/15] Add support for Hygon Dhyana Family 18h processor

[Pu Wen]

On 2019/4/3 0:15, Jan Beulich wrote:
> On 02.04.19 at 18:00, <puwen@hygon.cn> wrote:
>> On 2019/4/2 23:14, Andrew Cooper wrote:
>>> On 30/03/2019 10:40, Pu Wen wrote:
>>>> 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.
>>> One thing I don't see in this series is anything about microcode
>>> loading.  Presumably you'll follow the AMD patchloading mechanism, with
>>> a blob you provide yourself?
>> When the Hygon patchloading mechanism is practicable and it's necessary
>> to load the Hygon microcode outside of BIOS, we'll send the patchloading
>> patches to Xen and Linux mailing lists.
> 
> I suppose both Intel and AMD had this same intention of ucode loading
> being a firmware job only, and we see where we are right now. As long
> as updated firmware does not become available in a timely manner (or
> perhaps not at all, because of a vendor considering a certain system
> EOL), there's going to be a need to be able to load it from the OS.

It's reasonable. But I'll not put the microcode loading patch in this
series, and will sent it individually later after sufficiently tested.
Or just add Hygon vendor checking to follow the AMD patchloading
mechanism right now and do the adjustment for Hygon if needed in the
future?

-- 
Regards,
Pu Wen

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

Re: [PATCH v4 01/15] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

On 2019/4/3 18:22, Jan Beulich wrote:
> On 03.04.19 at 12:05, <puwen@hygon.cn> wrote:
>> I'm a little confused about which style to follow? In v3 series I
>> followed the style of the derived code. But in other patch you told me
>> to follow the Xen coding style, so in v4 series I changed the style to
>> match the bracing section of CODING_STYLE.
> 
> Well, taking just the brace placement part doesn't make this
> the file Xen style. In my earlier response to that style
> question I did suggest you switch to Xen style for the new
> file. I'd still view this as the preferred option, but then all
> aspects should be taken care of. But I won't insist, yet in that
> case clean Linux style is the only other alternative.

Will inherit the style from amd.c in hygon.c.

>> But if you think the conditional should be retained here for some reason
>> (even though the conditional may not be touched), I'll add it.
> 
> See above - yes, I think it should be retained.

Okay, will retain the conditionals.

-- 
Regards,
Pu Wen

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

Re: [PATCH v4 00/15] Add support for Hygon Dhyana Family 18h processor

[Jan Beulich]

>>> On 03.04.19 at 17:21, <puwen@hygon.cn> wrote:
> On 2019/4/3 0:15, Jan Beulich wrote:
>> On 02.04.19 at 18:00, <puwen@hygon.cn> wrote:
>>> On 2019/4/2 23:14, Andrew Cooper wrote:
>>>> On 30/03/2019 10:40, Pu Wen wrote:
>>>>> 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.
>>>> One thing I don't see in this series is anything about microcode
>>>> loading.  Presumably you'll follow the AMD patchloading mechanism, with
>>>> a blob you provide yourself?
>>> When the Hygon patchloading mechanism is practicable and it's necessary
>>> to load the Hygon microcode outside of BIOS, we'll send the patchloading
>>> patches to Xen and Linux mailing lists.
>> 
>> I suppose both Intel and AMD had this same intention of ucode loading
>> being a firmware job only, and we see where we are right now. As long
>> as updated firmware does not become available in a timely manner (or
>> perhaps not at all, because of a vendor considering a certain system
>> EOL), there's going to be a need to be able to load it from the OS.
> 
> It's reasonable. But I'll not put the microcode loading patch in this
> series, and will sent it individually later after sufficiently tested.

Fine with me, but Andrew will speak for himself.

> Or just add Hygon vendor checking to follow the AMD patchloading
> mechanism right now and do the adjustment for Hygon if needed in the
> future?

I'd prefer not to see this "blindly" enabled. As you say, it should
be tested. If no other changes are needed, the patch will be
easy to created and process.

Jan



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