Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1483667 > unrolled thread

[PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo Kyle Huey <me@kylehuey.com> - 2016-09-14 23:10 +0200
    Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in  /proc/cpuinfo Dave Hansen <dave.hansen@linux.intel.com> - 2016-09-14 23:40 +0200
      Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo Kyle Huey <me@kylehuey.com> - 2016-09-15 00:10 +0200
        Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo Andy Lutomirski <luto@amacapital.net> - 2016-09-15 03:20 +0200
          Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo Kyle Huey <me@kylehuey.com> - 2016-09-15 04:30 +0200
          Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo "H. Peter Anvin" <hpa@zytor.com> - 2016-09-15 22:50 +0200
            Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo Andy Lutomirski <luto@amacapital.net> - 2016-09-16 01:20 +0200
      Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in  /proc/cpuinfo David Vrabel <david.vrabel@citrix.com> - 2016-09-15 12:10 +0200
    Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting  capabilities in /proc/cpuinfo David Vrabel <david.vrabel@citrix.com> - 2016-09-15 12:10 +0200
      Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID  faulting capabilities in /proc/cpuinfo "Jan Beulich" <JBeulich@suse.com> - 2016-09-15 12:30 +0200
        Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting  capabilities in /proc/cpuinfo Kyle Huey <me@kylehuey.com> - 2016-09-15 21:20 +0200
          Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting  capabilities in /proc/cpuinfo Andy Lutomirski <luto@amacapital.net> - 2016-09-15 21:40 +0200
            Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting  capabilities in /proc/cpuinfo Kyle Huey <me@kylehuey.com> - 2016-09-16 01:40 +0200
          Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting  capabilities in /proc/cpuinfo Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-09-15 21:50 +0200

#1483667 — [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

Xen advertises the underlying support for CPUID faulting but not does pass
through writes to the relevant MSR, nor does it virtualize it, so it does
not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.

Signed-off-by: Kyle Huey <khuey@kylehuey.com>
---
 arch/x86/include/asm/cpufeatures.h |  1 +
 arch/x86/include/asm/msr-index.h   |  1 +
 arch/x86/kernel/cpu/scattered.c    | 14 ++++++++++++++
 arch/x86/xen/enlighten.c           |  3 +++
 4 files changed, 19 insertions(+)

diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index 92a8308..78b9d06 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -190,6 +190,7 @@
 
 #define X86_FEATURE_CPB		( 7*32+ 2) /* AMD Core Performance Boost */
 #define X86_FEATURE_EPB		( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS support */
+#define X86_FEATURE_CPUID_FAULT ( 7*32+ 4) /* Intel CPUID faulting */
 
 #define X86_FEATURE_HW_PSTATE	( 7*32+ 8) /* AMD HW-PState */
 #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 56f4c66..83908d5 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -41,6 +41,7 @@
 #define MSR_IA32_PERFCTR1		0x000000c2
 #define MSR_FSB_FREQ			0x000000cd
 #define MSR_PLATFORM_INFO		0x000000ce
+#define CPUID_FAULTING_SUPPORT		(1UL << 31)
 
 #define MSR_NHM_SNB_PKG_CST_CFG_CTL	0x000000e2
 #define NHM_C3_AUTO_DEMOTE		(1UL << 25)
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index 8cb57df..d502da1 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -24,6 +24,17 @@ enum cpuid_regs {
 	CR_EBX
 };
 
+static int supports_cpuid_faulting(void)
+{
+	unsigned int lo, hi;
+
+	if (rdmsr_safe(MSR_PLATFORM_INFO, &lo, &hi) == 0 &&
+	    (lo & CPUID_FAULTING_SUPPORT))
+		return 1;
+	else
+		return 0;
+}
+
 void init_scattered_cpuid_features(struct cpuinfo_x86 *c)
 {
 	u32 max_level;
@@ -54,4 +65,7 @@ void init_scattered_cpuid_features(struct cpuinfo_x86 *c)
 		if (regs[cb->reg] & (1 << cb->bit))
 			set_cpu_cap(c, cb->feature);
 	}
+
+	if (supports_cpuid_faulting())
+		set_cpu_cap(c, X86_FEATURE_CPUID_FAULT);
 }
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index b86ebb1..2c47f0c 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1050,6 +1050,9 @@ static u64 xen_read_msr_safe(unsigned int msr, int *err)
 #endif
 			val &= ~X2APIC_ENABLE;
 		break;
+	case MSR_PLATFORM_INFO:
+		val &= ~CPUID_FAULTING_SUPPORT;
+		break;
 	}
 	return val;
 }
-- 
2.7.4

[toc] | [next] | [standalone]

#1483698 — Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On 09/14/2016 02:01 PM, Kyle Huey wrote:
> Xen advertises the underlying support for CPUID faulting but not does pass
> through writes to the relevant MSR, nor does it virtualize it, so it does
> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.

That needs to make it into a comment, please.

That *is* a Xen bug, right?

> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
> ---
>  arch/x86/include/asm/cpufeatures.h |  1 +
>  arch/x86/include/asm/msr-index.h   |  1 +
>  arch/x86/kernel/cpu/scattered.c    | 14 ++++++++++++++
>  arch/x86/xen/enlighten.c           |  3 +++
>  4 files changed, 19 insertions(+)
> 
> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
> index 92a8308..78b9d06 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -190,6 +190,7 @@
>  
>  #define X86_FEATURE_CPB		( 7*32+ 2) /* AMD Core Performance Boost */
>  #define X86_FEATURE_EPB		( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS support */
> +#define X86_FEATURE_CPUID_FAULT ( 7*32+ 4) /* Intel CPUID faulting */
>  
>  #define X86_FEATURE_HW_PSTATE	( 7*32+ 8) /* AMD HW-PState */
>  #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface */
> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> index 56f4c66..83908d5 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -41,6 +41,7 @@
>  #define MSR_IA32_PERFCTR1		0x000000c2
>  #define MSR_FSB_FREQ			0x000000cd
>  #define MSR_PLATFORM_INFO		0x000000ce
> +#define CPUID_FAULTING_SUPPORT		(1UL << 31)
>  
>  #define MSR_NHM_SNB_PKG_CST_CFG_CTL	0x000000e2
>  #define NHM_C3_AUTO_DEMOTE		(1UL << 25)
> diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
> index 8cb57df..d502da1 100644
> --- a/arch/x86/kernel/cpu/scattered.c
> +++ b/arch/x86/kernel/cpu/scattered.c
> @@ -24,6 +24,17 @@ enum cpuid_regs {
>  	CR_EBX
>  };
>  
> +static int supports_cpuid_faulting(void)
> +{
> +	unsigned int lo, hi;
> +
> +	if (rdmsr_safe(MSR_PLATFORM_INFO, &lo, &hi) == 0 &&
> +	    (lo & CPUID_FAULTING_SUPPORT))
> +		return 1;
> +	else
> +		return 0;
> +}

Is any of this useful to optimize away at compile-time?  We have config
options for when we're running as a guest, and this seems like a feature
that isn't available when running on bare metal.

> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> index b86ebb1..2c47f0c 100644
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1050,6 +1050,9 @@ static u64 xen_read_msr_safe(unsigned int msr, int *err)
>  #endif
>  			val &= ~X2APIC_ENABLE;
>  		break;
> +	case MSR_PLATFORM_INFO:
> +		val &= ~CPUID_FAULTING_SUPPORT;
> +		break;
>  	}
>  	return val;
>  }

Does this mean that Xen guests effectively can't take advantage of this
feature?

[toc] | [prev] | [next] | [standalone]

#1483720

On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
<dave.hansen@linux.intel.com> wrote:
> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>> Xen advertises the underlying support for CPUID faulting but not does pass
>> through writes to the relevant MSR, nor does it virtualize it, so it does
>> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
>
> That needs to make it into a comment, please.
>
> That *is* a Xen bug, right?

Yes.  Xen needs to either not advertise the feature or actually
support it.  This came up in the prior thread ("[PATCH] prctl,x86 Add
PR_[GET|SET]_CPUID for controlling the CPUID instruction.").

>> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
>> ---
>>  arch/x86/include/asm/cpufeatures.h |  1 +
>>  arch/x86/include/asm/msr-index.h   |  1 +
>>  arch/x86/kernel/cpu/scattered.c    | 14 ++++++++++++++
>>  arch/x86/xen/enlighten.c           |  3 +++
>>  4 files changed, 19 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
>> index 92a8308..78b9d06 100644
>> --- a/arch/x86/include/asm/cpufeatures.h
>> +++ b/arch/x86/include/asm/cpufeatures.h
>> @@ -190,6 +190,7 @@
>>
>>  #define X86_FEATURE_CPB              ( 7*32+ 2) /* AMD Core Performance Boost */
>>  #define X86_FEATURE_EPB              ( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS support */
>> +#define X86_FEATURE_CPUID_FAULT ( 7*32+ 4) /* Intel CPUID faulting */
>>
>>  #define X86_FEATURE_HW_PSTATE        ( 7*32+ 8) /* AMD HW-PState */
>>  #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface */
>> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
>> index 56f4c66..83908d5 100644
>> --- a/arch/x86/include/asm/msr-index.h
>> +++ b/arch/x86/include/asm/msr-index.h
>> @@ -41,6 +41,7 @@
>>  #define MSR_IA32_PERFCTR1            0x000000c2
>>  #define MSR_FSB_FREQ                 0x000000cd
>>  #define MSR_PLATFORM_INFO            0x000000ce
>> +#define CPUID_FAULTING_SUPPORT               (1UL << 31)
>>
>>  #define MSR_NHM_SNB_PKG_CST_CFG_CTL  0x000000e2
>>  #define NHM_C3_AUTO_DEMOTE           (1UL << 25)
>> diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
>> index 8cb57df..d502da1 100644
>> --- a/arch/x86/kernel/cpu/scattered.c
>> +++ b/arch/x86/kernel/cpu/scattered.c
>> @@ -24,6 +24,17 @@ enum cpuid_regs {
>>       CR_EBX
>>  };
>>
>> +static int supports_cpuid_faulting(void)
>> +{
>> +     unsigned int lo, hi;
>> +
>> +     if (rdmsr_safe(MSR_PLATFORM_INFO, &lo, &hi) == 0 &&
>> +         (lo & CPUID_FAULTING_SUPPORT))
>> +             return 1;
>> +     else
>> +             return 0;
>> +}
>
> Is any of this useful to optimize away at compile-time?  We have config
> options for when we're running as a guest, and this seems like a feature
> that isn't available when running on bare metal.

On the contrary, this is only available when we're on bare metal.
Neither Xen nor KVM virtualize CPUID faulting (although KVM correctly
suppresses MSR_PLATFORM_INFO's report of support for it).

>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index b86ebb1..2c47f0c 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -1050,6 +1050,9 @@ static u64 xen_read_msr_safe(unsigned int msr, int *err)
>>  #endif
>>                       val &= ~X2APIC_ENABLE;
>>               break;
>> +     case MSR_PLATFORM_INFO:
>> +             val &= ~CPUID_FAULTING_SUPPORT;
>> +             break;
>>       }
>>       return val;
>>  }
>
> Does this mean that Xen guests effectively can't take advantage of this
> feature?

Yes.

- Kyle

[toc] | [prev] | [next] | [standalone]

#1483805

On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey <me@kylehuey.com> wrote:
> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
> <dave.hansen@linux.intel.com> wrote:
>> On 09/14/2016 02:01 PM, Kyle Huey wrote:

>> Is any of this useful to optimize away at compile-time?  We have config
>> options for when we're running as a guest, and this seems like a feature
>> that isn't available when running on bare metal.
>
> On the contrary, this is only available when we're on bare metal.
> Neither Xen nor KVM virtualize CPUID faulting (although KVM correctly
> suppresses MSR_PLATFORM_INFO's report of support for it).

KVM could easily support this.  If rr starts using it, I think KVM
*should* add support, possibly even for older CPUs that don't support
the feature in hardware.

It's too bad that x86 doesn't give us the instruction bytes on a
fault.  Otherwise we could lazily switch this feature.

--Andy

[toc] | [prev] | [next] | [standalone]

#1483825

On Wed, Sep 14, 2016 at 6:17 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey <me@kylehuey.com> wrote:
>> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
>> <dave.hansen@linux.intel.com> wrote:
>>> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>
>>> Is any of this useful to optimize away at compile-time?  We have config
>>> options for when we're running as a guest, and this seems like a feature
>>> that isn't available when running on bare metal.
>>
>> On the contrary, this is only available when we're on bare metal.
>> Neither Xen nor KVM virtualize CPUID faulting (although KVM correctly
>> suppresses MSR_PLATFORM_INFO's report of support for it).
>
> KVM could easily support this.  If rr starts using it, I think KVM
> *should* add support, possibly even for older CPUs that don't support
> the feature in hardware.
>
> It's too bad that x86 doesn't give us the instruction bytes on a
> fault.  Otherwise we could lazily switch this feature.

We are *very* interested in having KVM and Xen support virtualization
of this feature.  I am planning to work on KVM after I get this series
of patches in :)

- Kyle

[toc] | [prev] | [next] | [standalone]

#1484532

On September 14, 2016 6:17:51 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey <me@kylehuey.com> wrote:
>> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
>> <dave.hansen@linux.intel.com> wrote:
>>> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>
>>> Is any of this useful to optimize away at compile-time?  We have
>config
>>> options for when we're running as a guest, and this seems like a
>feature
>>> that isn't available when running on bare metal.
>>
>> On the contrary, this is only available when we're on bare metal.
>> Neither Xen nor KVM virtualize CPUID faulting (although KVM correctly
>> suppresses MSR_PLATFORM_INFO's report of support for it).
>
>KVM could easily support this.  If rr starts using it, I think KVM
>*should* add support, possibly even for older CPUs that don't support
>the feature in hardware.
>
>It's too bad that x86 doesn't give us the instruction bytes on a
>fault.  Otherwise we could lazily switch this feature.
>
>--Andy

You can "always" examine the instruction bytes in memory... have to make sure you properly consider the impact of race conditions though.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

[toc] | [prev] | [next] | [standalone]

#1484616

On Thu, Sep 15, 2016 at 1:38 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On September 14, 2016 6:17:51 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>>On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey <me@kylehuey.com> wrote:
>>> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
>>> <dave.hansen@linux.intel.com> wrote:
>>>> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>>
>>>> Is any of this useful to optimize away at compile-time?  We have
>>config
>>>> options for when we're running as a guest, and this seems like a
>>feature
>>>> that isn't available when running on bare metal.
>>>
>>> On the contrary, this is only available when we're on bare metal.
>>> Neither Xen nor KVM virtualize CPUID faulting (although KVM correctly
>>> suppresses MSR_PLATFORM_INFO's report of support for it).
>>
>>KVM could easily support this.  If rr starts using it, I think KVM
>>*should* add support, possibly even for older CPUs that don't support
>>the feature in hardware.
>>
>>It's too bad that x86 doesn't give us the instruction bytes on a
>>fault.  Otherwise we could lazily switch this feature.
>>
>>--Andy
>
> You can "always" examine the instruction bytes in memory... have to make sure you properly consider the impact of race conditions though.

I'd rather avoid needing to worry about those race conditions if at
all possible, though.  Intel and AMD both have fancy "decode assists"
and such -- it would be quite nice IMO if we could get the same data
exposed in the handlers of synchronous faults.

If Intel or AMD were to do this for real, presumably the rule would be
that any fault-class exception caused by a validly-decoded instruction
at CPL3 (so #PF and #GP would count but #DB probably wouldn't, and #DF
wouldn't either unless the initial fault did) would stash away the
faulting instruction and other entries would instead stash away
"nothing here".  Some pair of MSRs or new instruction would read out
information.  Then we could accurately emulate CPUID, we could
accurately emulate page-faulting instructions if we cared, etc.  All
of the relevant hardware must already mostly exist because VMX and SVM
both have this capability.

--Andy

[toc] | [prev] | [next] | [standalone]

#1483945 — Re: [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On 14/09/16 22:35, Dave Hansen wrote:
> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>> Xen advertises the underlying support for CPUID faulting but not does pass
>> through writes to the relevant MSR, nor does it virtualize it, so it does
>> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
> 
> That needs to make it into a comment, please.
> 
> That *is* a Xen bug, right?

This is probably fixed in the latest version of Xen.  Andrew Cooper
would know for sure.

>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -1050,6 +1050,9 @@ static u64 xen_read_msr_safe(unsigned int msr, int *err)
>>  #endif
>>  			val &= ~X2APIC_ENABLE;
>>  		break;
>> +	case MSR_PLATFORM_INFO:
>> +		val &= ~CPUID_FAULTING_SUPPORT;
>> +		break;
>>  	}
>>  	return val;
>>  }
> 
> Does this mean that Xen guests effectively can't take advantage of this
> feature?

PV guests only.

David

[toc] | [prev] | [next] | [standalone]

#1483943 — Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On 14/09/16 22:01, Kyle Huey wrote:
> Xen advertises the underlying support for CPUID faulting but not does pass
> through writes to the relevant MSR, nor does it virtualize it, so it does
> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.

Could you clarify in the commit message that it is PV guests that are
affected.

> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -1050,6 +1050,9 @@ static u64 xen_read_msr_safe(unsigned int msr, int *err)
>  #endif
>  			val &= ~X2APIC_ENABLE;
>  		break;
> +	case MSR_PLATFORM_INFO:
> +		val &= ~CPUID_FAULTING_SUPPORT;
> +		break;
>  	}
>  	return val;
>  }

Acked-by: David Vrabel <david.vrabel@citrix.com>

David

[toc] | [prev] | [next] | [standalone]

#1483954 — Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

>>> On 15.09.16 at 12:05, <david.vrabel@citrix.com> wrote:
> On 14/09/16 22:01, Kyle Huey wrote:
>> Xen advertises the underlying support for CPUID faulting but not does pass
>> through writes to the relevant MSR, nor does it virtualize it, so it does
>> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
> 
> Could you clarify in the commit message that it is PV guests that are
> affected.

What makes you think HVM ones aren't?

Jan

[toc] | [prev] | [next] | [standalone]

#1484476 — Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 15.09.16 at 12:05, <david.vrabel@citrix.com> wrote:
>> On 14/09/16 22:01, Kyle Huey wrote:
>>> Xen advertises the underlying support for CPUID faulting but not does pass
>>> through writes to the relevant MSR, nor does it virtualize it, so it does
>>> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
>>
>> Could you clarify in the commit message that it is PV guests that are
>> affected.
>
> What makes you think HVM ones aren't?

Testing on EC2, HVM guests are affected as well.  Not sure what to do
about that.

- Kyle

[toc] | [prev] | [next] | [standalone]

#1484500 — Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Thu, Sep 15, 2016 at 12:11 PM, Kyle Huey <me@kylehuey.com> wrote:
> On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 15.09.16 at 12:05, <david.vrabel@citrix.com> wrote:
>>> On 14/09/16 22:01, Kyle Huey wrote:
>>>> Xen advertises the underlying support for CPUID faulting but not does pass
>>>> through writes to the relevant MSR, nor does it virtualize it, so it does
>>>> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
>>>
>>> Could you clarify in the commit message that it is PV guests that are
>>> affected.
>>
>> What makes you think HVM ones aren't?
>
> Testing on EC2, HVM guests are affected as well.  Not sure what to do
> about that.
>

It's kind of nasty, but it shouldn't be *too* hard to probe for this
thing during early boot.  Allocate a page somewhere that has the user
bit set, put something like this in it:

cpuid
inc %eax  /* return 1 */
movw %ax, %ss /* force %GP to get out of here */

Call it like this from asm (real asm, not inline):

FRAME_BEGIN
pushq %rbx

xorl %eax, %eax

/* Push return frame */
pushq %ss
pushq %rsp
addq $8, (%rsp)
pushfq
pushq %cs
pushq $end_of_cpuid_faulting_test

/* Call it! */
pushq $__USER_DS
pushq $0
pushq $X86_EFLAGS_FIXED  /* leave IF off when running the CPL3 stub */
pushq $__USER_CS
pushq [address of userspace stub]
INTERRUPT_RETURN

end_of_cpuid_faulting_test:
pop %rbx

FRAME_END

Run this after the main GDT is loaded but while the #GP vector is
temporarily pointing to:

movq SS-RIP(%rsp), %rsp  /* pop the real return frame */
INTERRUPT_RETURN

and with interrupts off.  The function should return 0 if CPUID
faulting works and 1 if it doesn't.

Yeah, this is gross, but it should work.  I'm not sure how okay I am
with putting this crap in the kernel...

[toc] | [prev] | [next] | [standalone]

#1484623 — Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On Thu, Sep 15, 2016 at 12:37 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Thu, Sep 15, 2016 at 12:11 PM, Kyle Huey <me@kylehuey.com> wrote:
>> On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 15.09.16 at 12:05, <david.vrabel@citrix.com> wrote:
>>>> On 14/09/16 22:01, Kyle Huey wrote:
>>>>> Xen advertises the underlying support for CPUID faulting but not does pass
>>>>> through writes to the relevant MSR, nor does it virtualize it, so it does
>>>>> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
>>>>
>>>> Could you clarify in the commit message that it is PV guests that are
>>>> affected.
>>>
>>> What makes you think HVM ones aren't?
>>
>> Testing on EC2, HVM guests are affected as well.  Not sure what to do
>> about that.
>>
>
> It's kind of nasty, but it shouldn't be *too* hard to probe for this
> thing during early boot.  Allocate a page somewhere that has the user
> bit set, put something like this in it:
>
> cpuid
> inc %eax  /* return 1 */
> movw %ax, %ss /* force %GP to get out of here */
>
> Call it like this from asm (real asm, not inline):
>
> FRAME_BEGIN
> pushq %rbx
>
> xorl %eax, %eax
>
> /* Push return frame */
> pushq %ss
> pushq %rsp
> addq $8, (%rsp)
> pushfq
> pushq %cs
> pushq $end_of_cpuid_faulting_test
>
> /* Call it! */
> pushq $__USER_DS
> pushq $0
> pushq $X86_EFLAGS_FIXED  /* leave IF off when running the CPL3 stub */
> pushq $__USER_CS
> pushq [address of userspace stub]
> INTERRUPT_RETURN
>
> end_of_cpuid_faulting_test:
> pop %rbx
>
> FRAME_END
>
> Run this after the main GDT is loaded but while the #GP vector is
> temporarily pointing to:
>
> movq SS-RIP(%rsp), %rsp  /* pop the real return frame */
> INTERRUPT_RETURN
>
> and with interrupts off.  The function should return 0 if CPUID
> faulting works and 1 if it doesn't.
>
> Yeah, this is gross, but it should work.  I'm not sure how okay I am
> with putting this crap in the kernel...

This is rather heroic :)

I think it's more trouble than it's worth though.  The latest series I
submitted doesn't try to handle this.  Instead I'll patch Xen to fix
the bug.

- Kyle

[toc] | [prev] | [next] | [standalone]

#1484502 — Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

On 09/15/2016 03:11 PM, Kyle Huey wrote:
> On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 15.09.16 at 12:05, <david.vrabel@citrix.com> wrote:
>>> On 14/09/16 22:01, Kyle Huey wrote:
>>>> Xen advertises the underlying support for CPUID faulting but not does pass
>>>> through writes to the relevant MSR, nor does it virtualize it, so it does
>>>> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
>>> Could you clarify in the commit message that it is PV guests that are
>>> affected.
>> What makes you think HVM ones aren't?
> Testing on EC2, HVM guests are affected as well.  Not sure what to do
> about that.

You could clear capability bit in xen_set_cpu_features() but of course
this assumes you will never again read MSR_PLATFORM_INFO.

-boris

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web