diff mbox series

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

Message ID 96396a5ea9e1acc527705f71e9cd657b16585a75.1553935727.git.puwen@hygon.cn (mailing list archive)
State Superseded
Headers show
Series Add support for Hygon Dhyana Family 18h processor | expand

Commit Message

Pu Wen March 30, 2019, 10:42 a.m. UTC
There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.

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

Comments

Jan Beulich April 1, 2019, 8:40 a.m. UTC | #1
>>> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.

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

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

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

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

Thanks, Jan

> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -116,6 +116,11 @@ bool __init probe_cpuid_faulting(void)
>  	uint64_t val;
>  	int rc;
>  
> +	if ((boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ||
> +	     boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
> +	    !cpu_has_hypervisor)
> +		return false;
> +
>  	if ((rc = rdmsr_safe(MSR_INTEL_PLATFORM_INFO, val)) == 0)
>  		raw_msr_policy.plaform_info.cpuid_faulting =
>  			val & MSR_PLATFORM_INFO_CPUID_FAULTING;
> -- 
> 2.7.4
Pu Wen April 2, 2019, 6:46 a.m. UTC | #2
On 2019/4/1 16:41, Jan Beulich wrote:
> On 30.03.19 at 11:42, <puwen@hygon.cn> wrote:
>> There is no MSR_INTEL_PLATFORM_INFO for AMD and Hygon families. So directly
>> return false in the function probe_cpuid_faulting() if !cpu_has_hypervisor.
> 
> I think it would have been nice if you had mentioned the real
> reason why you want to bypass the MSR accesses. This way it
> sounds as if the change was only cosmetic, and hence could be
> left out.

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

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

Jan

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

We deliberately emulate MSR_INTEL_PLATFORM_INFO on all systems

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

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

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

Yes,for some early Hygon steppings.

> having this issue - are you telling us otherwise?

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

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

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

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

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

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

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

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

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

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

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

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

~Andrew
diff mbox series

Patch

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;