[Xen-devel] [PATCH v3] SVM: Add union intstat_t for offset 68h in vmcb struct
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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