All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] x86/hvm: Conditionally leave CPUID Faulting active in HVM context
@ 2017-01-16 11:17 Andrew Cooper
  2017-01-16 12:53 ` Jan Beulich
  2017-01-23 14:41 ` Andrew Cooper
  0 siblings, 2 replies; 4+ messages in thread
From: Andrew Cooper @ 2017-01-16 11:17 UTC (permalink / raw)
  To: Xen-devel; +Cc: Andrew Cooper, Kevin Tian, Jun Nakajima, Jan Beulich

If the hardware supports faulting, and the guest has chosen to use it, leave
faulting active in HVM context.

It is more efficient to have hardware convert CPUID to a #GP fault (which we
don't intercept), than to take a VMExit and have Xen re-inject a #GP fault.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Jun Nakajima <jun.nakajima@intel.com>
CC: Kevin Tian <kevin.tian@intel.com>
---
 xen/arch/x86/cpu/intel.c   |  5 +++--
 xen/arch/x86/hvm/vmx/vmx.c | 12 ++++++++++--
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index 2e11662..d0e380c 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -175,8 +175,9 @@ static void intel_ctxt_switch_levelling(const struct vcpu *next)
 		 * generating the maximum full cpuid policy into Xen, at which
 		 * this problem will disappear.
 		 */
-		set_cpuid_faulting(nextd && is_pv_domain(nextd) &&
-				   !is_control_domain(nextd));
+		set_cpuid_faulting(nextd && !is_control_domain(nextd) &&
+				   (is_pv_domain(nextd) ||
+				    next->arch.cpuid_faulting));
 		return;
 	}
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 61925cf..19294cb 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2866,11 +2866,19 @@ static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content)
         break;
 
     case MSR_INTEL_MISC_FEATURES_ENABLES:
+    {
+        bool old_cpuid_faulting = v->arch.cpuid_faulting;
+
         if ( msr_content & ~MSR_MISC_FEATURES_CPUID_FAULTING )
             goto gp_fault;
-        v->arch.cpuid_faulting =
-            !!(msr_content & MSR_MISC_FEATURES_CPUID_FAULTING);
+
+        v->arch.cpuid_faulting = msr_content & MSR_MISC_FEATURES_CPUID_FAULTING;
+
+        if ( cpu_has_cpuid_faulting &&
+             (old_cpuid_faulting ^ v->arch.cpuid_faulting) )
+            ctxt_switch_levelling(v);
         break;
+    }
 
     default:
         if ( passive_domain_do_wrmsr(msr, msr_content) )
-- 
2.1.4


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

^ permalink raw reply related	[flat|nested] 4+ messages in thread
* Re: [PATCH] x86/hvm: Conditionally leave CPUID Faulting active in HVM context
  2017-01-16 11:17 [PATCH] x86/hvm: Conditionally leave CPUID Faulting active in HVM context Andrew Cooper
@ 2017-01-16 12:53 ` Jan Beulich
  2017-01-23 14:41 ` Andrew Cooper
  1 sibling, 0 replies; 4+ messages in thread
From: Jan Beulich @ 2017-01-16 12:53 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: Kevin Tian, Jun Nakajima, Xen-devel

>>> On 16.01.17 at 12:17, <andrew.cooper3@citrix.com> wrote:
> If the hardware supports faulting, and the guest has chosen to use it, leave
> faulting active in HVM context.
> 
> It is more efficient to have hardware convert CPUID to a #GP fault (which we
> don't intercept), than to take a VMExit and have Xen re-inject a #GP fault.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

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


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

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: [PATCH] x86/hvm: Conditionally leave CPUID Faulting active in HVM context
  2017-01-16 11:17 [PATCH] x86/hvm: Conditionally leave CPUID Faulting active in HVM context Andrew Cooper
  2017-01-16 12:53 ` Jan Beulich
@ 2017-01-23 14:41 ` Andrew Cooper
  2017-01-24  7:58   ` Tian, Kevin
  1 sibling, 1 reply; 4+ messages in thread
From: Andrew Cooper @ 2017-01-23 14:41 UTC (permalink / raw)
  To: Xen-devel; +Cc: Kevin Tian, Jun Nakajima

On 16/01/17 11:17, Andrew Cooper wrote:
> If the hardware supports faulting, and the guest has chosen to use it, leave
> faulting active in HVM context.
>
> It is more efficient to have hardware convert CPUID to a #GP fault (which we
> don't intercept), than to take a VMExit and have Xen re-inject a #GP fault.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Jun Nakajima <jun.nakajima@intel.com>
> CC: Kevin Tian <kevin.tian@intel.com>

Ping VT-x ?

> ---
>  xen/arch/x86/cpu/intel.c   |  5 +++--
>  xen/arch/x86/hvm/vmx/vmx.c | 12 ++++++++++--
>  2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
> index 2e11662..d0e380c 100644
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -175,8 +175,9 @@ static void intel_ctxt_switch_levelling(const struct vcpu *next)
>  		 * generating the maximum full cpuid policy into Xen, at which
>  		 * this problem will disappear.
>  		 */
> -		set_cpuid_faulting(nextd && is_pv_domain(nextd) &&
> -				   !is_control_domain(nextd));
> +		set_cpuid_faulting(nextd && !is_control_domain(nextd) &&
> +				   (is_pv_domain(nextd) ||
> +				    next->arch.cpuid_faulting));
>  		return;
>  	}
>  
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 61925cf..19294cb 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2866,11 +2866,19 @@ static int vmx_msr_write_intercept(unsigned int msr, uint64_t msr_content)
>          break;
>  
>      case MSR_INTEL_MISC_FEATURES_ENABLES:
> +    {
> +        bool old_cpuid_faulting = v->arch.cpuid_faulting;
> +
>          if ( msr_content & ~MSR_MISC_FEATURES_CPUID_FAULTING )
>              goto gp_fault;
> -        v->arch.cpuid_faulting =
> -            !!(msr_content & MSR_MISC_FEATURES_CPUID_FAULTING);
> +
> +        v->arch.cpuid_faulting = msr_content & MSR_MISC_FEATURES_CPUID_FAULTING;
> +
> +        if ( cpu_has_cpuid_faulting &&
> +             (old_cpuid_faulting ^ v->arch.cpuid_faulting) )
> +            ctxt_switch_levelling(v);
>          break;
> +    }
>  
>      default:
>          if ( passive_domain_do_wrmsr(msr, msr_content) )


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

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: [PATCH] x86/hvm: Conditionally leave CPUID Faulting active in HVM context
  2017-01-23 14:41 ` Andrew Cooper
@ 2017-01-24  7:58   ` Tian, Kevin
  0 siblings, 0 replies; 4+ messages in thread
From: Tian, Kevin @ 2017-01-24  7:58 UTC (permalink / raw)
  To: Andrew Cooper, Xen-devel; +Cc: Nakajima, Jun

> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> Sent: Monday, January 23, 2017 10:41 PM
> 
> On 16/01/17 11:17, Andrew Cooper wrote:
> > If the hardware supports faulting, and the guest has chosen to use it, leave
> > faulting active in HVM context.
> >
> > It is more efficient to have hardware convert CPUID to a #GP fault (which we
> > don't intercept), than to take a VMExit and have Xen re-inject a #GP fault.
> >
> > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > ---
> > CC: Jan Beulich <JBeulich@suse.com>
> > CC: Jun Nakajima <jun.nakajima@intel.com>
> > CC: Kevin Tian <kevin.tian@intel.com>
> 
> Ping VT-x ?
> 

sorry overlooked this one:

Reviewed-by: Kevin Tian <kevin.tian@intel.com>

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

^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-01-24  7:58 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-16 11:17 [PATCH] x86/hvm: Conditionally leave CPUID Faulting active in HVM context Andrew Cooper
2017-01-16 12:53 ` Jan Beulich
2017-01-23 14:41 ` Andrew Cooper
2017-01-24  7:58   ` Tian, Kevin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.