[Xen-devel] [PATCH v3] SVM: Add union intstat_t for offset 68h in vmcb struct

[Pu Wen]

According to chapter "Appendix B Layout of VMCB" in the new version
(v3.32) AMD64 APM[1], bit 1 of the VMCB offset 68h is defined as
GUEST_INTERRUPT_MASK.

In current xen codes, it use whole u64 interrupt_shadow to setup
interrupt shadow, which will misuse other bit in VMCB offset 68h
as part of interrupt_shadow, causing svm_get_interrupt_shadow() to
mistake the guest having interrupts enabled as being in an interrupt
shadow.  This has been observed to cause SeaBIOS to hang on boot.

Add union intstat_t for VMCB offset 68h and fix codes to only use
bit 0 as intr_shadow according to the new APM description.

Reference:
[1] https://www.amd.com/system/files/TechDocs/24593.pdf

Signed-off-by: Pu Wen 
---
v2->v3:
  - Use bool for bit[0:1] and drop the resvd field.
  - Add description about breaking guest.

v1->v2:
  - Copy the whole int_stat in nsvm_vmcb_prepare4vmrun() and
nsvm_vmcb_prepare4vmexit().
  - Dump all 64 bits of int_stat in svm_vmcb_dump().

 xen/arch/x86/hvm/svm/nestedsvm.c   |  8 
 xen/arch/x86/hvm/svm/svm.c |  8 
 xen/arch/x86/hvm/svm/svmdebug.c|  4 ++--
 xen/include/asm-x86/hvm/svm/vmcb.h | 10 +-
 4 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index 3bd2a119d3..bbd06e342e 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -507,8 +507,8 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct 
cpu_user_regs *regs)
 n2vmcb->_vintr.fields.intr_masking = 1;
 }
 
-/* Shadow Mode */
-n2vmcb->interrupt_shadow = ns_vmcb->interrupt_shadow;
+/* Interrupt state */
+n2vmcb->int_stat = ns_vmcb->int_stat;
 
 /* Exit codes */
 n2vmcb->exitcode = ns_vmcb->exitcode;
@@ -1057,8 +1057,8 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct 
cpu_user_regs *regs)
 if (!(svm->ns_hostflags.fields.vintrmask))
 ns_vmcb->_vintr.fields.intr_masking = 0;
 
-/* Shadow mode */
-ns_vmcb->interrupt_shadow = n2vmcb->interrupt_shadow;
+/* Interrupt state */
+ns_vmcb->int_stat = n2vmcb->int_stat;
 
 /* Exit codes */
 ns_vmcb->exitcode = n2vmcb->exitcode;
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 32d8d847f2..888f504a94 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -116,7 +116,7 @@ void __update_guest_eip(struct cpu_user_regs *regs, 
unsigned int inst_len)
 regs->rip += inst_len;
 regs->eflags &= ~X86_EFLAGS_RF;
 
-curr->arch.hvm.svm.vmcb->interrupt_shadow = 0;
+curr->arch.hvm.svm.vmcb->int_stat.intr_shadow = 0;
 
 if ( regs->eflags & X86_EFLAGS_TF )
 hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
@@ -432,7 +432,7 @@ static unsigned int svm_get_interrupt_shadow(struct vcpu *v)
 struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
 unsigned int intr_shadow = 0;
 
-if ( vmcb->interrupt_shadow )
+if ( vmcb->int_stat.intr_shadow )
 intr_shadow |= HVM_INTR_SHADOW_MOV_SS | HVM_INTR_SHADOW_STI;
 
 if ( vmcb_get_general1_intercepts(vmcb) & GENERAL1_INTERCEPT_IRET )
@@ -446,7 +446,7 @@ static void svm_set_interrupt_shadow(struct vcpu *v, 
unsigned int intr_shadow)
 struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
 u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
 
-vmcb->interrupt_shadow =
+vmcb->int_stat.intr_shadow =
 !!(intr_shadow & (HVM_INTR_SHADOW_MOV_SS|HVM_INTR_SHADOW_STI));
 
 general1_intercepts &= ~GENERAL1_INTERCEPT_IRET;
@@ -2945,7 +2945,7 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
  * retired.
  */
 general1_intercepts &= ~GENERAL1_INTERCEPT_IRET;
-vmcb->interrupt_shadow = 1;
+vmcb->int_stat.intr_shadow = 1;
 
 vmcb_set_general1_intercepts(vmcb, general1_intercepts);
 break;
diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
index 366a003f21..5aa9d410ba 100644
--- a/xen/arch/x86/hvm/svm/svmdebug.c
+++ b/xen/arch/x86/hvm/svm/svmdebug.c
@@ -51,9 +51,9 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct 
*vmcb)
 printk("iopm_base_pa = %#"PRIx64" msrpm_base_pa = %#"PRIx64" tsc_offset = 
%#"PRIx64"\n",
vmcb_get_iopm_base_pa(vmcb), vmcb_get_msrpm_base_pa(vmcb),
vmcb_get_tsc_offset(vmcb));
-printk("tlb_control = %#x vintr = %#"PRIx64" interrupt_shadow = 
%#"PRIx64"\n",
+printk("tlb_control = %#x vintr = %#"PRIx64" int_stat = %#"PRIx64"\n",
vmcb->tlb_control, vmcb_get_vintr(vmcb).bytes,
-   vmcb->interrupt_shadow);
+   vmcb->int_stat.raw);
 printk("event_inj %016"PRIx64", valid? %d, ec? %d, type %u, vector %#x\n"

Re: [Xen-devel] [PATCH v2] SVM: Add union intstat_t for offset 68h in vmcb struct

[Pu Wen]

On 2020/3/25 18:30, Roger Pau Monné wrote:

On Tue, Mar 24, 2020 at 06:37:26PM +0800, Pu Wen wrote:

diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h 
b/xen/include/asm-x86/hvm/svm/vmcb.h
index b9e389d481..d8a3285752 100644
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -316,6 +316,17 @@ typedef union
  uint64_t raw;
  } intinfo_t;
  
+typedef union

+{
+struct
+{
+u64 intr_shadow:1;
+u64 guest_intr_mask:1;
+u64 resvd:  62;


Could you also use uint64_t for the fields, like you do below for
raw?


Ok, thanks. Maybe bool for intr_shadow and guest_intr_mask is better?

--
Regards,
Pu Wen

Re: [Xen-devel] [PATCH v2] SVM: Add union intstat_t for offset 68h in vmcb struct

[Pu Wen]

On 2020/3/24 19:55, Jan Beulich wrote:

--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -316,6 +316,17 @@ typedef union
  uint64_t raw;
  } intinfo_t;
  
+typedef union

+{
+struct
+{


Nit: The brace should be on the same line as "struct"; can be
taken care of while committing.


Ok, thanks.

--
Regards,
Pu Wen

Re: [Xen-devel] [PATCH v2] SVM: Add union intstat_t for offset 68h in vmcb struct

[Pu Wen]

On 2020/3/24 20:28, Andrew Cooper wrote:
> Hmm - this field doesn't appear to be part of AVIC, which makes me
> wonder what we're doing without it.
> 
> It appears to be a shadow copy of EFLAGS.IF which is only written on
> vmexit, and never consumed, but this is based on Appendix B which is the
> only reference I can find to the field at all.  Neither the
> VMRUN/#VMEXIT descriptions discuss it at all.
> 
> Given its position next to the (ambiguous) INTERRUPT_SHADOW, it just
> might actually distinguish the STI shadow from the MovSS shadow, but it
> could only do that by not behaving as described, and being asymmetric
> with EFLAGS.  I don't have time to investigate this right now.
> 
> We need the field described in Xen to set it appropriately for virtual
> vmexit, but I think that is the extent of what we need to do.

We encountered problem while running xen with new firmware which
implement the bit[1] of the VMCB offset 68h: the DomU stopped when
running seabios. We debugged the seabios code and found that the
seabios hung after call16_int10().

Then we debugged the xen code, and found the cause at this place in
svm_get_interrupt_shadow():
if ( vmcb->interrupt_shadow )
 intr_shadow |= HVM_INTR_SHADOW_MOV_SS | HVM_INTR_SHADOW_STI;
the conditional is true if bit[1] is 1 even though bit[0] is zero.
If just only use bit[0] in the conditional, the problem is solved, DomU
will run successfully.

-- 
Regards,
Pu Wen

[Xen-devel] [PATCH v2] SVM: Add union intstat_t for offset 68h in vmcb struct

[Pu Wen]

According to chapter "Appendix B Layout of VMCB" in the new version
(v3.32) AMD64 APM[1], bit 1 of the VMCB offset 68h is defined as
GUEST_INTERRUPT_MASK.

In current xen codes, it use whole u64 interrupt_shadow to setup
interrupt shadow, which will misuse other bit in VMCB offset 68h
as part of interrupt_shadow.

Add union intstat_t for VMCB offset 68h and fix codes to only use
bit 0 as intr_shadow according to the new APM description.

Reference:
[1] https://www.amd.com/system/files/TechDocs/24593.pdf

Signed-off-by: Pu Wen 
---
v1->v2:
  - Copy the whole int_stat in nsvm_vmcb_prepare4vmrun() and
nsvm_vmcb_prepare4vmexit().
  - Dump all 64 bits of int_stat in svm_vmcb_dump().

 xen/arch/x86/hvm/svm/nestedsvm.c   |  8 
 xen/arch/x86/hvm/svm/svm.c |  8 
 xen/arch/x86/hvm/svm/svmdebug.c|  4 ++--
 xen/include/asm-x86/hvm/svm/vmcb.h | 13 -
 4 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index 3bd2a119d3..bbd06e342e 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -507,8 +507,8 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct 
cpu_user_regs *regs)
 n2vmcb->_vintr.fields.intr_masking = 1;
 }
 
-/* Shadow Mode */
-n2vmcb->interrupt_shadow = ns_vmcb->interrupt_shadow;
+/* Interrupt state */
+n2vmcb->int_stat = ns_vmcb->int_stat;
 
 /* Exit codes */
 n2vmcb->exitcode = ns_vmcb->exitcode;
@@ -1057,8 +1057,8 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct 
cpu_user_regs *regs)
 if (!(svm->ns_hostflags.fields.vintrmask))
 ns_vmcb->_vintr.fields.intr_masking = 0;
 
-/* Shadow mode */
-ns_vmcb->interrupt_shadow = n2vmcb->interrupt_shadow;
+/* Interrupt state */
+ns_vmcb->int_stat = n2vmcb->int_stat;
 
 /* Exit codes */
 ns_vmcb->exitcode = n2vmcb->exitcode;
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 32d8d847f2..888f504a94 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -116,7 +116,7 @@ void __update_guest_eip(struct cpu_user_regs *regs, 
unsigned int inst_len)
 regs->rip += inst_len;
 regs->eflags &= ~X86_EFLAGS_RF;
 
-curr->arch.hvm.svm.vmcb->interrupt_shadow = 0;
+curr->arch.hvm.svm.vmcb->int_stat.intr_shadow = 0;
 
 if ( regs->eflags & X86_EFLAGS_TF )
 hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
@@ -432,7 +432,7 @@ static unsigned int svm_get_interrupt_shadow(struct vcpu *v)
 struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
 unsigned int intr_shadow = 0;
 
-if ( vmcb->interrupt_shadow )
+if ( vmcb->int_stat.intr_shadow )
 intr_shadow |= HVM_INTR_SHADOW_MOV_SS | HVM_INTR_SHADOW_STI;
 
 if ( vmcb_get_general1_intercepts(vmcb) & GENERAL1_INTERCEPT_IRET )
@@ -446,7 +446,7 @@ static void svm_set_interrupt_shadow(struct vcpu *v, 
unsigned int intr_shadow)
 struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
 u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
 
-vmcb->interrupt_shadow =
+vmcb->int_stat.intr_shadow =
 !!(intr_shadow & (HVM_INTR_SHADOW_MOV_SS|HVM_INTR_SHADOW_STI));
 
 general1_intercepts &= ~GENERAL1_INTERCEPT_IRET;
@@ -2945,7 +2945,7 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
  * retired.
  */
 general1_intercepts &= ~GENERAL1_INTERCEPT_IRET;
-vmcb->interrupt_shadow = 1;
+vmcb->int_stat.intr_shadow = 1;
 
 vmcb_set_general1_intercepts(vmcb, general1_intercepts);
 break;
diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
index 366a003f21..5aa9d410ba 100644
--- a/xen/arch/x86/hvm/svm/svmdebug.c
+++ b/xen/arch/x86/hvm/svm/svmdebug.c
@@ -51,9 +51,9 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct 
*vmcb)
 printk("iopm_base_pa = %#"PRIx64" msrpm_base_pa = %#"PRIx64" tsc_offset = 
%#"PRIx64"\n",
vmcb_get_iopm_base_pa(vmcb), vmcb_get_msrpm_base_pa(vmcb),
vmcb_get_tsc_offset(vmcb));
-printk("tlb_control = %#x vintr = %#"PRIx64" interrupt_shadow = 
%#"PRIx64"\n",
+printk("tlb_control = %#x vintr = %#"PRIx64" int_stat = %#"PRIx64"\n",
vmcb->tlb_control, vmcb_get_vintr(vmcb).bytes,
-   vmcb->interrupt_shadow);
+   vmcb->int_stat.raw);
 printk("event_inj %016"PRIx64", valid? %d, ec? %d, type %u, vector %#x\n",
vmcb->event_inj.raw, vmcb->event_inj.v,
vmcb->event_inj.ev, vmcb->event_inj.type,
diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h 
b/xen/include/asm-x86/hvm/svm/vmcb.h
index b9e389d481..d8a3285752 100644
--- a/xen/includ

[Xen-devel] [PATCH] x86/mce: Correct the machine check vendor for Hygon

[Pu Wen]

Currently the xl dmesg output on Hygon platforms will be
"(XEN) CPU0: AMD Fam18h machine check reporting enabled",
which is misleading as AMD does not have family 18h (Hygon
negotiated with AMD to confirm that only Hygon has family 18h).

To correct this, add Hygon machine check type and vendor string.

Signed-off-by: Pu Wen 
---
 xen/arch/x86/cpu/mcheck/mce.c | 4 +++-
 xen/arch/x86/cpu/mcheck/mce.h | 3 ++-
 xen/arch/x86/cpu/mcheck/mce_amd.c | 3 ++-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index e5bd4f542c..fe9667e0c3 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -610,7 +610,8 @@ int show_mca_info(int inited, struct cpuinfo_x86 *c)
 static const char *const type_str[] = {
 [mcheck_amd_famXX] = "AMD",
 [mcheck_amd_k8] = "AMD K8",
-[mcheck_intel] = "Intel"
+[mcheck_intel] = "Intel",
+[mcheck_hygon] = "Hygon"
 };
 
 snprintf(prefix, ARRAY_SIZE(prefix), "%sCPU%u: ",
@@ -625,6 +626,7 @@ int show_mca_info(int inited, struct cpuinfo_x86 *c)
 break;
 
 case mcheck_amd_famXX:
+case mcheck_hygon:
 printk("%s%s Fam%xh machine check reporting enabled\n",
prefix, type_str[inited], c->x86);
 break;
diff --git a/xen/arch/x86/cpu/mcheck/mce.h b/xen/arch/x86/cpu/mcheck/mce.h
index 7137c2f763..1953626919 100644
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -36,7 +36,8 @@ enum mcheck_type {
 mcheck_none,
 mcheck_amd_famXX,
 mcheck_amd_k8,
-mcheck_intel
+mcheck_intel,
+mcheck_hygon
 };
 
 extern uint8_t cmci_apic_vector;
diff --git a/xen/arch/x86/cpu/mcheck/mce_amd.c 
b/xen/arch/x86/cpu/mcheck/mce_amd.c
index 787ce961b6..279a8e6f12 100644
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c
@@ -339,5 +339,6 @@ amd_mcheck_init(struct cpuinfo_x86 *ci)
 mce_recoverable_register(mc_amd_recoverable_scan);
 mce_register_addrcheck(mc_amd_addrcheck);
 
-return mcheck_amd_famXX;
+return ci->x86_vendor == X86_VENDOR_HYGON ?
+mcheck_hygon : mcheck_amd_famXX;
 }
-- 
2.23.0

[Xen-devel] [PATCH] SVM: Add union intstat_t for offset 68h in vmcb struct

[Pu Wen]

According to chapter "Appendix B Layout of VMCB" in the new version
(v3.32) AMD64 APM[1], bit 1 of the VMCB offset 68h is defined as
GUEST_INTERRUPT_MASK.

In current xen codes, it use whole u64 interrupt_shadow to setup
interrupt shadow, which will misuse other bit in VMCB offset 68h
as part of interrupt_shadow.

Add union intstat_t for VMCB offset 68h and fix codes to only use
bit 0 as intr_shadow according to the new APM description.

Reference:
[1] https://www.amd.com/system/files/TechDocs/24593.pdf

Signed-off-by: Pu Wen 
---
 xen/arch/x86/hvm/svm/nestedsvm.c   |  4 ++--
 xen/arch/x86/hvm/svm/svm.c |  8 
 xen/arch/x86/hvm/svm/svmdebug.c|  4 ++--
 xen/include/asm-x86/hvm/svm/vmcb.h | 13 -
 4 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index 3bd2a119d3..595cbb1d81 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -508,7 +508,7 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct 
cpu_user_regs *regs)
 }
 
 /* Shadow Mode */
-n2vmcb->interrupt_shadow = ns_vmcb->interrupt_shadow;
+n2vmcb->int_stat.intr_shadow = ns_vmcb->int_stat.intr_shadow;
 
 /* Exit codes */
 n2vmcb->exitcode = ns_vmcb->exitcode;
@@ -1058,7 +1058,7 @@ nsvm_vmcb_prepare4vmexit(struct vcpu *v, struct 
cpu_user_regs *regs)
 ns_vmcb->_vintr.fields.intr_masking = 0;
 
 /* Shadow mode */
-ns_vmcb->interrupt_shadow = n2vmcb->interrupt_shadow;
+ns_vmcb->int_stat.intr_shadow = n2vmcb->int_stat.intr_shadow;
 
 /* Exit codes */
 ns_vmcb->exitcode = n2vmcb->exitcode;
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 32d8d847f2..888f504a94 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -116,7 +116,7 @@ void __update_guest_eip(struct cpu_user_regs *regs, 
unsigned int inst_len)
 regs->rip += inst_len;
 regs->eflags &= ~X86_EFLAGS_RF;
 
-curr->arch.hvm.svm.vmcb->interrupt_shadow = 0;
+curr->arch.hvm.svm.vmcb->int_stat.intr_shadow = 0;
 
 if ( regs->eflags & X86_EFLAGS_TF )
 hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
@@ -432,7 +432,7 @@ static unsigned int svm_get_interrupt_shadow(struct vcpu *v)
 struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
 unsigned int intr_shadow = 0;
 
-if ( vmcb->interrupt_shadow )
+if ( vmcb->int_stat.intr_shadow )
 intr_shadow |= HVM_INTR_SHADOW_MOV_SS | HVM_INTR_SHADOW_STI;
 
 if ( vmcb_get_general1_intercepts(vmcb) & GENERAL1_INTERCEPT_IRET )
@@ -446,7 +446,7 @@ static void svm_set_interrupt_shadow(struct vcpu *v, 
unsigned int intr_shadow)
 struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
 u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
 
-vmcb->interrupt_shadow =
+vmcb->int_stat.intr_shadow =
 !!(intr_shadow & (HVM_INTR_SHADOW_MOV_SS|HVM_INTR_SHADOW_STI));
 
 general1_intercepts &= ~GENERAL1_INTERCEPT_IRET;
@@ -2945,7 +2945,7 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
  * retired.
  */
 general1_intercepts &= ~GENERAL1_INTERCEPT_IRET;
-vmcb->interrupt_shadow = 1;
+vmcb->int_stat.intr_shadow = 1;
 
 vmcb_set_general1_intercepts(vmcb, general1_intercepts);
 break;
diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
index 366a003f21..5547baa497 100644
--- a/xen/arch/x86/hvm/svm/svmdebug.c
+++ b/xen/arch/x86/hvm/svm/svmdebug.c
@@ -51,9 +51,9 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct 
*vmcb)
 printk("iopm_base_pa = %#"PRIx64" msrpm_base_pa = %#"PRIx64" tsc_offset = 
%#"PRIx64"\n",
vmcb_get_iopm_base_pa(vmcb), vmcb_get_msrpm_base_pa(vmcb),
vmcb_get_tsc_offset(vmcb));
-printk("tlb_control = %#x vintr = %#"PRIx64" interrupt_shadow = 
%#"PRIx64"\n",
+printk("tlb_control = %#x vintr = %#"PRIx64" interrupt_shadow = %#x\n",
vmcb->tlb_control, vmcb_get_vintr(vmcb).bytes,
-   vmcb->interrupt_shadow);
+   vmcb->int_stat.intr_shadow);
 printk("event_inj %016"PRIx64", valid? %d, ec? %d, type %u, vector %#x\n",
vmcb->event_inj.raw, vmcb->event_inj.v,
vmcb->event_inj.ev, vmcb->event_inj.type,
diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h 
b/xen/include/asm-x86/hvm/svm/vmcb.h
index b9e389d481..d8a3285752 100644
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -316,6 +316,17 @@ typedef union
 uint64_t raw;
 } intinfo_t;
 
+typedef union
+{
+struct
+{
+u64 intr_shadow:1;
+u64 guest_intr_mask:1;
+u64 resvd:  62;
+};
+  

Re: [Xen-devel] [PATCH v5 00/15] Add support for Hygon Dhyana Family 18h processor

[Pu Wen]

On 2019/6/7 0:31, Andrew Cooper wrote:

I've rebased the patches over my CPUID work, and pushed the ones which
still apply cleanly to staging.  However, some don't apply cleanly any
more, so I left those alone.

Please could you check the current staging build (and in particular,
that I didn't accidentally break anything with the rebase), and rebase
the remainder of the series onto staging.


I rebased the patches x86/acpi and x86/pv over 0cd07414 "x86/cpu:
Renumber X86_VENDOR_* to form a bitmap", and sent them out with version
v6. I dropped the patch x86/iommu for Hygon because it's no needed any
more since the commit 1b3cc800 "x86/IOMMU: introduce init-ops structure"
removed the vendor check.

I still hold Jan's Acked-by tags however the code is changed. Are the
tags still valid?

Thx.

--
Regards,
Pu Wen

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

[Xen-devel] [PATCH v6] 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.

[Rebase over 0cd07414 "x86/cpu: Renumber X86_VENDOR_* to form a bitmap"]

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 xen/arch/x86/acpi/cpu_idle.c | 3 ++-
 xen/arch/x86/acpi/cpufreq/cpufreq.c  | 8 +---
 xen/arch/x86/acpi/cpufreq/powernow.c | 2 +-
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
index 8846722..5931928 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -802,7 +802,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 | 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 f4e13e1..7086d1a 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 | X86_VENDOR_HYGON)))
 ret = powernow_register_driver();
 
 return ret;
@@ -660,8 +661,9 @@ int cpufreq_cpu_init(unsigned int cpuid)
 {
 int ret;
 
-/* Currently we only handle Intel and AMD processor */
-if ( boot_cpu_data.x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD) )
+/* Currently we only handle Intel, AMD and Hygon processor */
+if ( boot_cpu_data.x86_vendor &
+ (X86_VENDOR_INTEL | X86_VENDOR_AMD | 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..72ab6a1 100644
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -360,7 +360,7 @@ 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 | 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

[Xen-devel] [PATCH v6] 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.

[Rebase over 0cd07414 "x86/cpu: Renumber X86_VENDOR_* to form a bitmap"]

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 xen/arch/x86/pv/emul-priv-op.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index b20d79c..2d5c82d 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -913,7 +913,8 @@ 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 | X86_VENDOR_HYGON)) )
 {
 if ( vpmu_do_rdmsr(reg, val) )
 break;
@@ -995,7 +996,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 | X86_VENDOR_HYGON)) )
 break;
 if ( likely(!is_cpufreq_controller(currd)) ||
  wrmsr_safe(reg, val) == 0 )
@@ -1044,7 +1046,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 | X86_VENDOR_AMD)) 
)
+if ( !(boot_cpu_data.x86_vendor &
+   (X86_VENDOR_INTEL | X86_VENDOR_AMD | X86_VENDOR_HYGON)) )
 break;
 if ( likely(!is_cpufreq_controller(currd)) ||
  wrmsr_safe(reg, val) == 0 )
@@ -1076,7 +1079,8 @@ 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 | 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

Re: [Xen-devel] [PATCH v5 00/15] Add support for Hygon Dhyana Family 18h processor

[Pu Wen]

On 2019/6/7 0:31, Andrew Cooper wrote:
> I've rebased the patches over my CPUID work, and pushed the ones which
> still apply cleanly to staging.  However, some don't apply cleanly any

Thanks a lot.

> more, so I left those alone.
> 
> Please could you check the current staging build (and in particular,
> that I didn't accidentally break anything with the rebase), and rebase

Yes, the current staging build is OK and works on Hygon platform.
I'll check the functionalities more carefully.

> the remainder of the series onto staging.

I'll do this later on.

--
Regards,
Pu Wen


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

Re: [Xen-devel] [PATCH v5 01/15] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

On 2019/4/17 23:04, Wei Liu wrote:

On Sat, Apr 13, 2019 at 12:14:14AM +0800, Pu Wen wrote:

On 2019/4/5 15:50, Jan Beulich wrote:

On 04.04.19 at 18:39,  wrote:

On 2019/4/4 22:07, Andrew Cooper wrote:

This needs the following hunk folding in
which can be done on commit to avoid sending yet another version.


Do you mean I need to send a individual patch for this file instead of
reworking the whole series?


I don't think that's necessary, unless other reasons arise for there
to be yet another round necessary. As Andrew says - this can easily
be done while committing.


Hi Jan and Andrew,

How about the patches till now? Are they acceptable to commit?


FYI we're trying to sort out issues with upstream CI system, so
committing these patches need to wait a bit. But don't worry, they will
eventually be committed (assuming all the acks and Rbs are in place).


Okay, thanks! But there's still no acks for this patch of the whole 
series, so I just worry about it. Could someone 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: [Xen-devel] [PATCH v5 01/15] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

On 2019/4/5 15:50, Jan Beulich wrote:

On 04.04.19 at 18:39,  wrote:

On 2019/4/4 22:07, Andrew Cooper wrote:

This needs the following hunk folding in
which can be done on commit to avoid sending yet another version.


Do you mean I need to send a individual patch for this file instead of
reworking the whole series?


I don't think that's necessary, unless other reasons arise for there
to be yet another round necessary. As Andrew says - this can easily
be done while committing.


Hi Jan and Andrew,

How about the patches till now? Are they acceptable to commit?

Thx.

--
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH 4/5] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

On 2019/4/5 17:38, Jan Beulich wrote:

On 04.04.19 at 22:26,  wrote:

+   else
+   /* Successfully enabled! */
+   __set_bit(X86_FEATURE_LFENCE_DISPATCH,
+ c->x86_capability);


Down the road we may want to make this another helper function
shared by AMD any Hygon code.


It sounds good.


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


Like the above, this lacks a model check. Is it really expected for
all future Hygon models to supports both in exactly the same


For current Hygon family 18h, all models will have the same meaning.


fashion? Even if there's just a small chance of this not being the
case, rather than fiddling with MSRs which have an entirely
different meaning in future models, I'd prefer if model checks
were added in cases like these.


In future for some other Hygon CPU families(such as maybe family 20h ?), 
the bits definition of this MSR may have different meaning. But I think 
it should be dealt with by then, since there would be some other 
features to be adjusted by the way for those families.



I do realize that in the former case there's effectively an "all
models except a few" logic already in the original AMD code,
which I would too question whether it's really desirable. After
all we've learned recently that MSRs indeed can go away


It's a good thing that MSRs can go away.


(albeit in that case it was a change to the MSR simply becoming
meaningless, rather than obtaining a new meaning). Based on
this I could accept just the SSBD logic to gain a model check.


--
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH v5 00/15] Add support for Hygon Dhyana Family 18h processor

[Pu Wen]

On 2019/4/4 22:08, Julien Grall wrote:

Hi,

I am not sure why I end up to be CCed on the cover letter when I am not CCed on
the rest of series.


The patch 01/15 of the series is CCed to you. :)

--
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH v5 15/15] tools/libxc: Add Hygon Dhyana support

[Pu Wen]

On 2019/4/5 0:38, Wei Liu wrote:

On Thu, Apr 04, 2019 at 09:48:13PM +0800, Pu Wen wrote:

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 


Acked-by: Wei Liu 


Thanks.

--
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH v5 01/15] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

On 2019/4/4 22:07, Andrew Cooper wrote:

On 04/04/2019 14:45, Pu Wen wrote:

index 774ceac..75fefcf 100644
--- a/xen/include/asm-x86/x86-vendors.h
+++ b/xen/include/asm-x86/x86-vendors.h
@@ -30,6 +30,11 @@
  #define X86_VENDOR_SHANGHAI_ECX 0x20206961U
  #define X86_VENDOR_SHANGHAI_EDX 0x68676e61U
  
-#define X86_VENDOR_NUM 5

+#define X86_VENDOR_HYGON 5
+#define X86_VENDOR_HYGON_EBX 0x6f677948 /* "HygonGenuine" */
+#define X86_VENDOR_HYGON_ECX 0x656e6975
+#define X86_VENDOR_HYGON_EDX 0x6e65476e
+
+#define X86_VENDOR_NUM 6
  
  #endif	/* __XEN_X86_VENDORS_H__ */

diff --git a/xen/lib/x86/cpuid.c b/xen/lib/x86/cpuid.c
index 311d19e..d0b3ff7 100644
--- a/xen/lib/x86/cpuid.c
+++ b/xen/lib/x86/cpuid.c
@@ -29,6 +29,12 @@ unsigned int x86_cpuid_lookup_vendor(uint32_t ebx, uint32_t 
ecx, uint32_t edx)
   edx == X86_VENDOR_SHANGHAI_EDX )
  return X86_VENDOR_SHANGHAI;
  break;
+
+case X86_VENDOR_HYGON_EBX:
+if ( ecx == X86_VENDOR_HYGON_ECX &&
+ edx == X86_VENDOR_HYGON_EDX )
+return X86_VENDOR_HYGON;
+break;
  }
  
  return X86_VENDOR_UNKNOWN;


This needs the following hunk folding in

diff --git a/tools/tests/cpu-policy/test-cpu-policy.c
b/tools/tests/cpu-policy/test-cpu-policy.c
index beced5e..88f5121 100644
--- a/tools/tests/cpu-policy/test-cpu-policy.c
+++ b/tools/tests/cpu-policy/test-cpu-policy.c
@@ -35,6 +35,7 @@ static void test_vendor_identification(void)
  { { "AuthenticAMD" }, X86_VENDOR_AMD },
  { { "CentaurHauls" }, X86_VENDOR_CENTAUR },
  { { "  Shanghai  " }, X86_VENDOR_SHANGHAI },
+    { { "HygonGenuine" }, X86_VENDOR_HYGON },
  
  { { "" }, X86_VENDOR_UNKNOWN },

  { { "    " }, X86_VENDOR_UNKNOWN },


I'm sorry for missing this file.


which can be done on commit to avoid sending yet another version.


Do you mean I need to send a individual patch for this file instead of 
reworking the whole series?


--
Regards,
Pu Wen

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

[Xen-devel] [PATCH v5 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


v4->v5:
  - Rebased over https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=0763cd26
to fit the new x86 vendor lookup mechanism.
  - Rework patch 15/15 to fit the new x86 vendor lookup mechanism.
  - Add Acked-by from Jan Beulich for patch 02/15 and 04/15.
  - Retain more conditionals from amd.c.
  - Refine coding style.

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 |  11 ++--
 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   | 114 +
 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|   8 +++
 xen/arch/x86/cpu/vpmu_amd.c|  61 --
 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  |   7 +-
 xen/lib/x86/cpuid.c|   6 ++
 29 files changed, 275 insertions(+), 57 deletions(-)
 create mode 100644 xen/arch

[Xen-devel] [PATCH v5 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 MSR_01DD. So add support for it if the boot param
ler is true.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 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

[Xen-devel] [PATCH v5 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
and vendor ID "HygonGenuine" for system recognition, and fit the new
x86 vendor lookup mechanism.

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 
---
 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  | 114 ++
 xen/include/asm-x86/x86-vendors.h |   7 ++-
 xen/lib/x86/cpuid.c   |   6 ++
 7 files changed, 132 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 7a73d62..6554d5d 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 b2249b5..74c9426 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -691,6 +691,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 edc88b1..c3ae2ee 100644
--- a/xen/arch/x86/cpu/cpu.h
+++ b/xen/arch/x86/cpu/cpu.h
@@ -16,7 +16,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 000..912849c
--- /dev/null
+++ b/xen/arch/x86/cpu/hygon.c
@@ -0,0 +1,114 @@
+#include 
+#include 
+#include 
+#include 
+
+#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(0x801e);
+   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.  This MSR almost
+* certainly isn't virtualised (and Xen at least will leak the real
+* value in but silently discard writes), as well as being per-core
+* rather than per-thread, so do a full safe read/write/readback cycle
+* in the worst case.
+*/
+   if (rdmsr_safe(MSR_AMD64_DE_CFG, value))
+   /* Unable to read.  Assume the safer default. */
+   __clear_bit(X86_FEATURE_LFENCE_DISPATCH,
+   c->x86_capability);
+   else if (value & AMD64_DE_CFG_LFENCE_SERIALISE)
+   /* Already dispatch serialising. */
+   __set_bit(X86_FEATURE_LFENCE_DISPATCH,
+ c->x86_capability);
+   else if (wrmsr_safe(MSR_AMD64_DE_CFG,
+   value | AMD64_DE_CFG_LFENCE_SERIALISE) ||
+rdmsr_safe(MSR_AMD64_DE_CFG, value) ||
+!(va

[Xen-devel] [PATCH v5 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 
---
 tools/libxc/xc_cpuid_x86.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 71e1ee7..e5afa55 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -556,7 +556,8 @@ static void xc_cpuid_hvm_policy(const struct 
cpuid_domain_info *info,
 break;
 }
 
-if ( info->vendor == X86_VENDOR_AMD )
+if ( info->vendor == X86_VENDOR_AMD ||
+ info->vendor == X86_VENDOR_HYGON )
 amd_xc_cpuid_policy(info, input, regs);
 else
 intel_xc_cpuid_policy(info, input, regs);
@@ -618,7 +619,8 @@ static void xc_cpuid_pv_policy(const struct 
cpuid_domain_info *info,
 
 case 0x8000:
 {
-unsigned int max = info->vendor == X86_VENDOR_AMD
+unsigned int max = (info->vendor == X86_VENDOR_AMD ||
+info->vendor == X86_VENDOR_HYGON)
 ? DEF_MAX_AMDEXT : DEF_MAX_INTELEXT;
 
 if ( regs[0] > max )
@@ -724,7 +726,8 @@ static void sanitise_featureset(struct cpuid_domain_info 
*info)
 if ( !info->pv64 )
 {
 clear_bit(X86_FEATURE_LM, info->featureset);
-if ( info->vendor != X86_VENDOR_AMD )
+if ( info->vendor != X86_VENDOR_AMD &&
+ info->vendor != X86_VENDOR_HYGON )
 clear_bit(X86_FEATURE_SYSCALL, info->featureset);
 }
 
@@ -775,7 +778,7 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid,
 input[0] = 0x8000;
 cpuid(input, regs);
 
-if ( info.vendor == X86_VENDOR_AMD )
+if ( info.vendor == X86_VENDOR_AMD || info.vendor == X86_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

[Xen-devel] [PATCH v5 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 
Acked-by: Jan Beulich 
---
 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

[Xen-devel] [PATCH v5 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 
Acked-by: Jan Beulich 
---
 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 cb170ac..a3fb770 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);
@@ -391,7 +392,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);
 
@@ -466,7 +468,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= 0x8000 | min(p->extd.max_leaf & 0x,
-   (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);
 
@@ -508,7 +511,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

[Xen-devel] [PATCH v5 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 
Acked-by: Jan Beulich 
---
 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

[Xen-devel] [PATCH v5 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 
Acked-by: Jan Beulich 
---
 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 73f5407..4a36b63 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 20b86fd..c9a7964 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

[Xen-devel] [PATCH v5 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 
Acked-by: Jan Beulich 
---
 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 84ce67c..4f73375 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_hwdom_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 )
@@ -1099,7 +1104,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

[Xen-devel] [PATCH v5 07/15] x86/apic: Add Hygon Dhyana support

[Pu Wen]

Add Hygon Dhyana support to use modern APIC.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 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 e6130cf..65228cb 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

[Xen-devel] [PATCH v5 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 
Acked-by: Jan Beulich 
---
 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

[Xen-devel] [PATCH v5 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 
Acked-by: Jan Beulich 
---
 xen/arch/x86/cpu/vpmu.c |  8 ++
 xen/arch/x86/cpu/vpmu_amd.c | 61 -
 xen/include/asm-x86/vpmu.h  |  1 +
 3 files changed, 52 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 8f6daf1..375599a 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,10 +877,17 @@ 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;
 break;
+
 default:
 printk(XENLOG_WARNING "VPMU: Unknown CPU vendor: %d. "
"Turning VPMU off.\n", vendor);
diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
index 5efc39b..124b7cb 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 __init 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,44 @@ 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

[Xen-devel] [PATCH v5 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 
Acked-by: Jan Beulich 
---
 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 1a095fc..c14ff1b 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -326,7 +326,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

[Xen-devel] [PATCH v5 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 
Acked-by: Jan Beulich 
---
 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

[Xen-devel] [PATCH v5 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. Read
this MSR will stop the Xen initialization process in some Hygon
systems or produce GPF(0). So directly return false in the function
probe_cpuid_faulting() if !cpu_has_hypervisor.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 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 74c9426..1a095fc 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

[Xen-devel] [PATCH v5 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 
Acked-by: Jan Beulich 
---
 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

Re: [Xen-devel] [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,  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: [Xen-devel] [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,  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: [Xen-devel] [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,  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(0x8008) & 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: [Xen-devel] [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,  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: [Xen-devel] [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,  wrote:

On 2019/4/2 18:20, Jan Beulich wrote:

On 02.04.19 at 08:46,  wrote:

On 2019/4/1 16:41, Jan Beulich wrote:

On 30.03.19 at 11:42,  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: [Xen-devel] [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: [Xen-devel] [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: [Xen-devel] [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,  wrote:
>> On 2019/4/1 16:36, Jan Beulich wrote:
>>> On 30.03.19 at 11:42,  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: [Xen-devel] [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,  wrote:

On 2019/4/1 16:41, Jan Beulich wrote:

On 30.03.19 at 11:42,  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: [Xen-devel] [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,  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 


Thanks.

--
Regards,
Pu Wen


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

Re: [Xen-devel] [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,  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

[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 
Acked-by: Wei Liu 
---
 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 0x8000:
 {
-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] = 0x8000;
 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

[Xen-devel] [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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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= 0x8000 | min(p->extd.max_leaf & 0x,
-   (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

[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 MSR_01DD. So add support for it if the boot param
ler is true.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
---
 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 000..7ccbd84
--- /dev/null
+++ b/xen/arch/x86/cpu/hygon.c
@@ -0,0 +1,92 @@
+#include 
+#include 
+#include 
+#include 
+
+#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(0x801e);
+   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 = 

[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 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

Re: [Xen-devel] [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,  wrote:

On 2019/3/27 0:10, Jan Beulich wrote:

On 25.03.19 at 14:30,  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

Re: [Xen-devel] [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,  wrote:
>> On 2019/3/26 23:49, Jan Beulich wrote:
>>> On 25.03.19 at 14:29,  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 ()"
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: [Xen-devel] [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,  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: [Xen-devel] [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,  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

[Xen-devel] [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

[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 
Acked-by: Wei Liu 
---
 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 0x8000:
 {
-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] = 0x8000;
 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

[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 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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= 0x8000 | min(p->extd.max_leaf & 0x,
-   (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

[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 MSR_01DD. So add support for it if the boot param
ler is true.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
Acked-by: Jan Beulich 
---
 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

[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 
---
 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 000..bbe13c5
--- /dev/null
+++ b/xen/arch/x86/cpu/hygon.c
@@ -0,0 +1,95 @@
+#include 
+#include 
+#include 
+#include 
+
+#include "cpu.h"
+
+#define APICID_SOCKET_ID_BIT 6
+
+static void hygon_get_topology(struct cpuinfo_x86 *c)
+{
+   u32

[Xen-devel] [RFC PATCH] x86/xen/pmu: Use MSRs C001_020X instead of the legacy MSRs for Hygon

[Pu Wen]

The Hygon Dhyana processor supports MSRs C001_020X for the performance
monitor counter(PMC). There are six core performance events counters for
Dhyana but there are only four legacy PMC MSRs. So switching to use MSRs
C001_020X(compatible with the F15H ones) for Xen vPMU infrastructure on
Hygon platform.

Signed-off-by: Pu Wen 
---
 arch/x86/xen/pmu.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
index e13b0b4..6480eed 100644
--- a/arch/x86/xen/pmu.c
+++ b/arch/x86/xen/pmu.c
@@ -92,11 +92,11 @@ static void xen_pmu_arch_init(void)
break;
}
} else if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
-   amd_num_counters = F10H_NUM_COUNTERS;
-   amd_counters_base = MSR_K7_PERFCTR0;
-   amd_ctrls_base = MSR_K7_EVNTSEL0;
-   amd_msr_step = 1;
-   k7_counters_mirrored = 0;
+   amd_num_counters = F15H_NUM_COUNTERS;
+   amd_counters_base = MSR_F15H_PERF_CTR;
+   amd_ctrls_base = MSR_F15H_PERF_CTL;
+   amd_msr_step = 2;
+   k7_counters_mirrored = 1;
} else {
uint32_t eax, ebx, ecx, edx;
 
-- 
2.7.4


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

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

[Pu Wen]

On 2019/3/19 21:58, Jan Beulich wrote:

On 19.03.19 at 14:47,  wrote:

On 2019/3/19 20:58, Jan Beulich wrote:

On 19.03.19 at 12:32,  wrote:

On 2019/3/18 16:59, Jan Beulich wrote:

On 16.03.19 at 11:11,  wrote:

On 2019/3/15 20:41, Jan Beulich wrote:

On 21.02.19 at 10:50,  wrote:

--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -545,6 +545,8 @@ int __init amd_vpmu_init(void)
 switch ( current_cpu_data.x86 )
 {
 case 0x15:
+case 0x17:
+case 0x18:
 num_counters = F15H_NUM_COUNTERS;
 counters = AMD_F15H_COUNTERS;
 ctrls = AMD_F15H_CTRLS;


Unless you know what AMD Fam18 will look like, you can't do it
like this. Fam18 really needs to be further qualified by a vendor
check at this point in time.


Hygon will negotiate with AMD to make sure that only Hygon should use
Fam18h.


In the success case of which please state this in the description.
Until those negotiations have succeeded I'm afraid I'm going to
insist to see the extra check added.

or just add Hygon support at beginning of amd_vpmu_init():
   if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
   num_counters = F15H_NUM_COUNTERS;
   counters = AMD_F15H_COUNTERS;
   ctrls = AMD_F15H_CTRLS;
   k7_counters_mirrored = 1;
   }

or perhaps even better would be two separate switch()-es, one for
AMD and one for Hygon. Possibly even a separate hygon_vpmu_init().


A separate hygon_vpmu_init() is also fine except that the last part of
the function can be shared.


So perhaps split that part out into a static _vpmu_init() or common_init()?


Okay, I'll try to split that part.

--
Regards,
Pu Wen

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

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

[Pu Wen]

On 2019/3/19 20:58, Jan Beulich wrote:
> On 19.03.19 at 12:32,  wrote:
>> On 2019/3/18 16:59, Jan Beulich wrote:
>>> On 16.03.19 at 11:11,  wrote:
>>>> On 2019/3/15 20:41, Jan Beulich wrote:
>>>>> On 21.02.19 at 10:50,  wrote:
>>>>>> --- a/xen/arch/x86/cpu/vpmu_amd.c
>>>>>> +++ b/xen/arch/x86/cpu/vpmu_amd.c
>>>>>> @@ -545,6 +545,8 @@ int __init amd_vpmu_init(void)
>>>>>> switch ( current_cpu_data.x86 )
>>>>>> {
>>>>>> case 0x15:
>>>>>> +case 0x17:
>>>>>> +case 0x18:
>>>>>> num_counters = F15H_NUM_COUNTERS;
>>>>>> counters = AMD_F15H_COUNTERS;
>>>>>> ctrls = AMD_F15H_CTRLS;
>>>>>
>>>>> Unless you know what AMD Fam18 will look like, you can't do it
>>>>> like this. Fam18 really needs to be further qualified by a vendor
>>>>> check at this point in time.
>>>>
>>>> Hygon will negotiate with AMD to make sure that only Hygon should use
>>>> Fam18h.
>>>
>>> In the success case of which please state this in the description.
>>> Until those negotiations have succeeded I'm afraid I'm going to
>>> insist to see the extra check added.
>>
>> How to check vendor? Maybe like this:
>>   case 0x15:
>>   case 0x17:
>>   case 0x18:
>>   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
>>   boot_cpu_data.x86 == 0x18)
>>   return -EINVAL;
>>
>>   num_counters = F15H_NUM_COUNTERS;
>>   counters = AMD_F15H_COUNTERS;
>>   ctrls = AMD_F15H_CTRLS;
>>
>> or just add Hygon support at beginning of amd_vpmu_init():
>>   if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
>>   num_counters = F15H_NUM_COUNTERS;
>>   counters = AMD_F15H_COUNTERS;
>>   ctrls = AMD_F15H_CTRLS;
>>   k7_counters_mirrored = 1;
>>   }
> 
> A suitable variant of the latter or
> 
> int __init amd_vpmu_init(void)
> {
>  unsigned int i, fam = current_cpu_data.x86
> 
>  /*  */
>  if ( current_cpu_data.x86_vendor == X86_VENDOR_HYGON && fam == 0x18 )
> fam = 0x17;

This is the minimum change, I think it's better.

> 
>  switch ( fam )
>  ...
> 
> or perhaps even better would be two separate switch()-es, one for
> AMD and one for Hygon. Possibly even a separate hygon_vpmu_init().

A separate hygon_vpmu_init() is also fine except that the last part of
the function can be shared.

-- 
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH v2 01/14] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

On 2019/3/19 21:02, Jan Beulich wrote:
> On 19.03.19 at 13:33,  wrote:
>> On 2019/3/18 16:55, Jan Beulich wrote:
>>> On 16.03.19 at 10:57,  wrote:
>>>> On 2019/3/15 19:18, Jan Beulich wrote:
>>>>> On 15.03.19 at 11:17,  wrote:
>>>>>> On 2019/3/15 1:11, Jan Beulich wrote:
>>>>>>> This is a lot of duplicated code with only minor differences. I think
>>>>>>> you would be better off calling into the AMD original functions.
>>>>>> These functions and AMD original ones are static. So Hygon cannot 
>>>>>> directly
>>>>>> call into them. Or we can put them into the common cpu code, but I think
>>>>>> it's not good for future maintenance.
>>>>> Just make non-static what needs to be, add an amd_ prefix, and
>>>>> call it from your code.
>>>> That's OK. With this method only init_levelling in amd.c should be added
>>>> an amd_ prefix and called by hygon.c.
>>>> But I'm afraid Hygon should have its own init functions and not call the
>>>> AMD ones. The current Hygon init functions have been heavily stripped
>>>> from the original AMD's.
>>> Let me give you this rule of thumb (subject to discussion): If you can
>>> safely re-use any non-trivial current AMD function with at most minor
>>> adjustments (and irrespective of certain code there being unreachable
>>> on Hygon), then I think it would be better to re-use it than to duplicate
>>> it.
>>
>> I tried, but it will add 0x18 to init_amd(). It's strange because AMD
>> does not have family 18h now. So it becomes unwieldy to maintain
>> init_amd() just at this time. The same situation for amd_get_topology().
>>
>> So I think it's better to carve out init_hygon() and hygon_get_topology()
>> (which also need Hygon's own adjustment for computing phys_proc_id).
> 
> Just to be clear: I've never objected to a separate init_hygon().
> For amd_get_topology() it's less clear: It looks to me as if you
> wouldn't need to add any Hygon conditionals to the function, as
> long as cpu_has(c, X86_FEATURE_TOPOEXT) is true in your case.
 
Yes, it's no need to add Hygon conditional to amd_get_topology() as >=0x17
conditionals are default supported.

-- 
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH v2 01/14] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

On 2019/3/18 16:55, Jan Beulich wrote:
> On 16.03.19 at 10:57,  wrote:
>> On 2019/3/15 19:18, Jan Beulich wrote:
>>> On 15.03.19 at 11:17,  wrote:
>>>> On 2019/3/15 1:11, Jan Beulich wrote:
>>>>> This is a lot of duplicated code with only minor differences. I think
>>>>> you would be better off calling into the AMD original functions.
>>>> These functions and AMD original ones are static. So Hygon cannot directly
>>>> call into them. Or we can put them into the common cpu code, but I think
>>>> it's not good for future maintenance.
>>> Just make non-static what needs to be, add an amd_ prefix, and
>>> call it from your code.
>> That's OK. With this method only init_levelling in amd.c should be added
>> an amd_ prefix and called by hygon.c.
>> But I'm afraid Hygon should have its own init functions and not call the
>> AMD ones. The current Hygon init functions have been heavily stripped
>> from the original AMD's.
> Let me give you this rule of thumb (subject to discussion): If you can
> safely re-use any non-trivial current AMD function with at most minor
> adjustments (and irrespective of certain code there being unreachable
> on Hygon), then I think it would be better to re-use it than to duplicate
> it.

I tried, but it will add 0x18 to init_amd(). It's strange because AMD
does not have family 18h now. So it becomes unwieldy to maintain
init_amd() just at this time. The same situation for amd_get_topology().

So I think it's better to carve out init_hygon() and hygon_get_topology()
(which also need Hygon's own adjustment for computing phys_proc_id).

I think it's time to develop a new patch series for your review.

-- 
Regards,
Pu Wen

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

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

[Pu Wen]

On 2019/3/18 16:59, Jan Beulich wrote:

On 16.03.19 at 11:11,  wrote:

On 2019/3/15 20:41, Jan Beulich wrote:

On 21.02.19 at 10:50,  wrote:

--- a/xen/arch/x86/cpu/vpmu_amd.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -545,6 +545,8 @@ int __init amd_vpmu_init(void)
   switch ( current_cpu_data.x86 )
   {
   case 0x15:
+case 0x17:
+case 0x18:
   num_counters = F15H_NUM_COUNTERS;
   counters = AMD_F15H_COUNTERS;
   ctrls = AMD_F15H_CTRLS;


Unless you know what AMD Fam18 will look like, you can't do it
like this. Fam18 really needs to be further qualified by a vendor
check at this point in time.


Hygon will negotiate with AMD to make sure that only Hygon should use
Fam18h.


In the success case of which please state this in the description.
Until those negotiations have succeeded I'm afraid I'm going to
insist to see the extra check added.


How to check vendor? Maybe like this:
case 0x15:
case 0x17:
case 0x18:
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
boot_cpu_data.x86 == 0x18)
return -EINVAL;

num_counters = F15H_NUM_COUNTERS;
counters = AMD_F15H_COUNTERS;
ctrls = AMD_F15H_CTRLS;

or just add Hygon support at beginning of amd_vpmu_init():
if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
num_counters = F15H_NUM_COUNTERS;
counters = AMD_F15H_COUNTERS;
ctrls = AMD_F15H_CTRLS;
k7_counters_mirrored = 1;
    }

--
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH v2 02/14] x86/cpu/mtrr: Add Hygon Dhyana support to get TOP_MEM2

[Pu Wen]

On 2019/3/18 16:57, Jan Beulich wrote:
>>>> On 16.03.19 at 11:06,  wrote:
>> On 2019/3/15 20:40, Jan Beulich wrote:
>>>>>> On 21.02.19 at 10:48,  wrote:
>>>> 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 
>>>
>>> Acked-by: Jan Beulich 
>>>
>>> I'm afraid I won't be able to offer Reviewed-by tags for any of
>>> this series without you pointing us at the documentation for the
>>> processor (a link should really be in the cover letter).
>>
>> Do you mean the specification for Hygon processor? We don't have any
>> public spec now, but you can reference to the AMD Zen one[1].
> 
> Well, no, not really. There are undoubtedly differences (see your
> reply to my pci_cfg_ok() question as an example). I can ack
> changes on the basis that you know how your processors behave.
> I can give R-b only if I have Hygon-specific doc to check against.

In fact there is no definition of MSR C001_001F(MSR_AMD64_NB_CFG) in the
AMD family 17h models 00h-0Fh PPR, I don't know why there is 0x17 support
in pci_cfg_ok().

Besides, the other MSRs and CPUIDs which are used by Hygon in this patch
series are all defined in this PPR, and the meanings are fully the same.
For example in current patch, bit 21 of MSR C001_0010(MSR_K8_TOP_MEM2)
in print_mtrr_state().

-- 
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH v2 00/14] Add support for Hygon Dhyana Family 18h processor

[Pu Wen]

On 2019/3/15 21:41, Jan Beulich wrote:

On 21.02.19 at 10:48,  wrote:

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


In addition to these changes, what about pci_cfg_ok()? I don't think
I've seen any of the patches touch it.


Because Hygon does not access the extended NB configuration space right
now, so there is no change to pci_cfg_ok().

--
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH v2 11/14] x86/domctl: Add Hygon Dhyana support

[Pu Wen]

On 2019/3/15 21:29, Jan Beulich wrote:

On 21.02.19 at 10:53,  wrote:

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

Signed-off-by: Pu Wen 


Acked-by: Jan Beulich 
with one remark:


@@ -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 and Hygon, clear the duplicated features
+ * in e1d.


I think this wants to be "or" instead of "and".


Yes, will change to "or".

--
Regards,
Pu Wen

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

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

[Pu Wen]

On 2019/3/15 20:41, Jan Beulich wrote:
>>>> On 21.02.19 at 10:50,  wrote:
>> --- a/xen/arch/x86/cpu/vpmu_amd.c
>> +++ b/xen/arch/x86/cpu/vpmu_amd.c
>> @@ -545,6 +545,8 @@ int __init amd_vpmu_init(void)
>>   switch ( current_cpu_data.x86 )
>>   {
>>   case 0x15:
>> +case 0x17:
>> +case 0x18:
>>   num_counters = F15H_NUM_COUNTERS;
>>   counters = AMD_F15H_COUNTERS;
>>   ctrls = AMD_F15H_CTRLS;
> 
> Unless you know what AMD Fam18 will look like, you can't do it
> like this. Fam18 really needs to be further qualified by a vendor
> check at this point in time.

Hygon will negotiate with AMD to make sure that only Hygon should use
Fam18h.

-- 
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH v2 02/14] x86/cpu/mtrr: Add Hygon Dhyana support to get TOP_MEM2

[Pu Wen]

On 2019/3/15 20:40, Jan Beulich wrote:
>>>> On 21.02.19 at 10:48,  wrote:
>> 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 
> 
> Acked-by: Jan Beulich 
> 
> I'm afraid I won't be able to offer Reviewed-by tags for any of
> this series without you pointing us at the documentation for the
> processor (a link should really be in the cover letter).

Do you mean the specification for Hygon processor? We don't have any
public spec now, but you can reference to the AMD Zen one[1].

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

-- 
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH v2 01/14] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

On 2019/3/15 19:18, Jan Beulich wrote:
>>>> On 15.03.19 at 11:17,  wrote:
>> On 2019/3/15 1:11, Jan Beulich wrote:
>>>>>> On 21.02.19 at 10:48,  wrote:
>>>> +static void __init noinline probe_masking_msrs(void)
>>>> +{
>>>> +  const struct cpuinfo_x86 *c = &boot_cpu_data;
>>>> +
>>>> +  /* Work out which masking MSRs we should have. */
>>>> +  cpuidmask_defaults._1cd =
>>>> +  _probe_mask_msr(MSR_K8_FEATURE_MASK, LCAP_1cd);
>>>> +  cpuidmask_defaults.e1cd =
>>>> +  _probe_mask_msr(MSR_K8_EXT_FEATURE_MASK, LCAP_e1cd);
>>>> +  if (c->cpuid_level >= 7)
>>>> +  cpuidmask_defaults._7ab0 =
>>>> +  _probe_mask_msr(MSR_AMD_L7S0_FEATURE_MASK, LCAP_7ab0);
>>>
>>> There's more relevant code here in the original function.
>>
>> The code is used for family 15h. Hygon CPU do not need it.
> 
> There's a single Fam15 conditional in the middle of the function.
> Everything beyond that is again family-independent.
> 
>>>> +  if (opt_cpu_info) {
>>>> +  printk(XENLOG_INFO "Levelling caps: %#x\n", levelling_caps);
>>>> +  printk(XENLOG_INFO
>>>> + "MSR defaults: 1d 0x%08x, 1c 0x%08x, e1d 0x%08x, "
>>>> + "e1c 0x%08x, 7a0 0x%08x, 7b0 0x%08x\n",
>>>> + (uint32_t)cpuidmask_defaults._1cd,
>>>> + (uint32_t)(cpuidmask_defaults._1cd >> 32),
>>>> + (uint32_t)cpuidmask_defaults.e1cd,
>>>> + (uint32_t)(cpuidmask_defaults.e1cd >> 32),
>>>> + (uint32_t)(cpuidmask_defaults._7ab0 >> 32),
>>>> + (uint32_t)cpuidmask_defaults._7ab0);
>>>> +  }
>>>> +
>>>> +  if (levelling_caps)
>>>> +  ctxt_switch_masking = hygon_ctxt_switch_masking;
>>>> +}
>>>
>>> This is a lot of duplicated code with only minor differences. I think
>>> you would be better off calling into the AMD original functions.
>>
>> These functions and AMD original ones are static. So Hygon cannot directly
>> call into them. Or we can put them into the common cpu code, but I think
>> it's not good for future maintenance.
> 
> Just make non-static what needs to be, add an amd_ prefix, and
> call it from your code.

That's OK. With this method only init_levelling in amd.c should be added
an amd_ prefix and called by hygon.c.

But I'm afraid Hygon should have its own init functions and not call the
AMD ones. The current Hygon init functions have been heavily stripped
from the original AMD's.

>> There are many codes to support AMD's
>> different families, the family/model/stepping checking are deeply embedded
>> in codes. If we add Hygon family/model/stepping checking in future version,
>> it will make code interleaved together and hard to maintain.
> 
> We can think about adding the duplication when it becomes
> unwieldy to maintain the shared variant.
> 
>>>> +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);
>>>> +  else if (value & AMD64_DE_CFG_LFENCE_SERIALISE)
>>>> +  /* Already dispatch serialising. */
>>>> +  __set_bit(X86_FEATURE_LFENCE_DISPATCH, c->x86_capability);
>>>
>>> Didn't you cut off too much from the original code (which again
>>> may better be shared, by splitting out into a function)?
>>
>> The cut codes are used for other AMD families except family 17h. Hygon
>> Dhyana is derived from AMD Zen, so we only need the family 17h parts.
>> This also make the init flow minimal.
> 
> How is
> 
>   else if (wrmsr_safe(MSR_AMD64_DE_CFG,
>   value | AMD64_DE_CFG_LFENCE_SERIALISE) ||
>rdmsr_safe(MSR_AMD64_DE_CFG, value) ||
>!(value & AMD64_DE_CFG_LFENCE_SERIALISE))
>   /* Attempt to set failed.  Assume the safer default. */
>   __clear_bit(X86_FEATURE_LFENCE_DISPATCH,
>   c->x86_capability);
>   else
>   /* Successfully enabled! */
>   __set_bit(X86_FEATURE_LFENCE_DISPATCH,
> c->x86_capability);
> 
> family dependent in any way?

Independent here.

-- 
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH v2 01/14] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

On 2019/3/15 1:11, Jan Beulich wrote:
>>>> On 21.02.19 at 10:48,  wrote:
>> 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.
> 
> I'm not convinced of this - it'll get in the way of introducing something
> like Linux'es CONFIG_CPU_SUP_*. Our command line parsing logic
> handles multiple instances of an option quite fine I think, so I'd prefer
> if these were kept static to both files. Or did Andrew ask you to do
> this?

Yes, Andrew asked that these should be moved from the AMD specific code into
the common cpu code (alongside the other masks) rather than duplicated here.

>> --- a/xen/arch/x86/cpu/Makefile
>> +++ b/xen/arch/x86/cpu/Makefile
>> @@ -8,4 +8,5 @@ obj-y += intel.o
>>   obj-y += intel_cacheinfo.o
>>   obj-y += mwait-idle.o
>>   obj-y += shanghai.o
>> +obj-y += hygon.o
>>   obj-y += vpmu.o vpmu_amd.o vpmu_intel.o
> 
> Please insert at the alphabetically correct place.

OK.

...
>>   int intel_cpu_init(void);
>>   int amd_init_cpu(void);
>> +int hygon_init_cpu(void);
>>   int centaur_init_cpu(void);
>>   int shanghai_init_cpu(void);
> 
> Whereas here you should really put the new declaration at the end.

OK.

...
>> +/* Probe for the existance of the expected masking MSRs. */
> 
> Please don't drop the other part of the original comment.

OK. Will revert to the original one.

>> +static void __init noinline probe_masking_msrs(void)
>> +{
>> +const struct cpuinfo_x86 *c = &boot_cpu_data;
>> +
>> +/* Work out which masking MSRs we should have. */
>> +cpuidmask_defaults._1cd =
>> +_probe_mask_msr(MSR_K8_FEATURE_MASK, LCAP_1cd);
>> +cpuidmask_defaults.e1cd =
>> +_probe_mask_msr(MSR_K8_EXT_FEATURE_MASK, LCAP_e1cd);
>> +if (c->cpuid_level >= 7)
>> +cpuidmask_defaults._7ab0 =
>> +_probe_mask_msr(MSR_AMD_L7S0_FEATURE_MASK, LCAP_7ab0);
> 
> There's more relevant code here in the original function.

The code is used for family 15h. Hygon CPU do not need it.

...
>> +if (opt_cpu_info) {
>> +printk(XENLOG_INFO "Levelling caps: %#x\n", levelling_caps);
>> +printk(XENLOG_INFO
>> +   "MSR defaults: 1d 0x%08x, 1c 0x%08x, e1d 0x%08x, "
>> +   "e1c 0x%08x, 7a0 0x%08x, 7b0 0x%08x\n",
>> +   (uint32_t)cpuidmask_defaults._1cd,
>> +   (uint32_t)(cpuidmask_defaults._1cd >> 32),
>> +   (uint32_t)cpuidmask_defaults.e1cd,
>> +   (uint32_t)(cpuidmask_defaults.e1cd >> 32),
>> +   (uint32_t)(cpuidmask_defaults._7ab0 >> 32),
>> +   (uint32_t)cpuidmask_defaults._7ab0);
>> +}
>> +
>> +if (levelling_caps)
>> +ctxt_switch_masking = hygon_ctxt_switch_masking;
>> +}
> 
> This is a lot of duplicated code with only minor differences. I think
> you would be better off calling into the AMD original functions.

These functions and AMD original ones are static. So Hygon cannot directly
call into them. Or we can put them into the common cpu code, but I think
it's not good for future maintenance. There are many codes to support AMD's
different families, the family/model/stepping checking are deeply embedded
in codes. If we add Hygon family/model/stepping checking in future version,
it will make code interleaved together and hard to maintain.

In fact in Linux we keep hygon.c separated from AMD even though there are
some duplicated codes at the moment. Andrew also agreed the logic that
following suit with Linux.

>> +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);
>> +else if (value & AMD64_DE_CFG_LFENCE_SERIALISE)
>> +/* Already dispatch serialising. */
>> +__set_bit(X86_FEATURE_LFENCE_DISPATCH, c->x86_capability);
> 
> Didn't you cut off too much from the original code (which again
> may better be shared, by splitting out into a function)?

The cut codes are used for other AMD families except family 17h. Hygon
Dhyana is derived from AMD Zen, so we only need the family 17h parts.
This also make the init flow minimal.

>> +/* Hygon processors have APIC timer running in deep C states. */
>> +if ( opt_arat )
> 
> Please don't copy the bad spaces inside the parentheses here.

OK. Thanks for the reminding.

-- 
Regards,
Pu Wen

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

Re: [Xen-devel] [PATCH v2 00/14] Add support for Hygon Dhyana Family 18h processor

[Pu Wen]

On 2019/2/22 0:38, Wei Liu wrote:
> I think the version should have been v5?

Aha. This is the second revision of the patch series. So why should it
have been v5?

-- 
Regards,
Pu Wen

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

[Xen-devel] [PATCH v2 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 
---
 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..3a9e290 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 and 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

[Xen-devel] [PATCH v2 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 
---
 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= 0x8000 | min(p->extd.max_leaf & 0x,
-   (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

[Xen-devel] [PATCH v2 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 
---
 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 942ece2..1521041 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -911,7 +911,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;
@@ -993,7 +995,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 )
@@ -1014,8 +1017,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;
@@ -1054,7 +1058,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 )
@@ -1087,7 +1092,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

[Xen-devel] [PATCH v2 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 
Acked-by: Wei Liu 
---
 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 0x8000:
 {
-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] = 0x8000;
 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

[Xen-devel] [PATCH v2 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 
---
 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

[Xen-devel] [PATCH v2 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 MSR_01DD. So add support for it if the boot param
ler is true.

Signed-off-by: Pu Wen 
Acked-by: Jan Beulich 
---
 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

[Xen-devel] [PATCH v2 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 
---
 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 14b0278..f57825c 100644
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -795,7 +795,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