Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for PVH guests

2014-11-25 Thread Boris Ostrovsky 

On 11/25/2014 03:45 AM, Jan Beulich wrote:

@@ -1429,6 +1429,12 @@ int vlapic_init(struct vcpu *v)
  
  HVM_DBG_LOG(DBG_LEVEL_VLAPIC, %d, v-vcpu_id);
  
+if ( is_pvh_vcpu(v) )

+{
+vlapic-hw.disabled = VLAPIC_HW_DISABLED;



I did consider doing that but I thought that this flag is meant to be 
set when the guest clears MSR_IA32_APICBASE_ENABLE to disable APIC and 
therefore I'd be overloading it (the flag) in a way.


Regardless, do you think that disabling VPMU for PVH is worth anyway?

-boris




+return 0;
+}
+
  vlapic-pt.source = PTSRC_lapic;
  
  if (vlapic-regs_page == NULL)







___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for PVH guests

2014-11-25 Thread Jan Beulich 
 On 25.11.14 at 15:38, boris.ostrov...@oracle.com wrote:
 On 11/25/2014 03:45 AM, Jan Beulich wrote:
 @@ -1429,6 +1429,12 @@ int vlapic_init(struct vcpu *v)
   
   HVM_DBG_LOG(DBG_LEVEL_VLAPIC, %d, v-vcpu_id);
   
 +if ( is_pvh_vcpu(v) )
 +{
 +vlapic-hw.disabled = VLAPIC_HW_DISABLED;
 
 
 I did consider doing that but I thought that this flag is meant to be 
 set when the guest clears MSR_IA32_APICBASE_ENABLE to disable APIC and 
 therefore I'd be overloading it (the flag) in a way.

There's no overloading here - we're then simply treating all PVH
vCPU-s as having permanently hardware-disabled LAPICs (reflecting
current reality).

 Regardless, do you think that disabling VPMU for PVH is worth anyway?

That depends on what (bad) consequences not doing so has.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for PVH guests

2014-11-25 Thread Boris Ostrovsky 

On 11/25/2014 09:55 AM, Jan Beulich wrote:



Regardless, do you think that disabling VPMU for PVH is worth anyway?

That depends on what (bad) consequences not doing so has.


I haven't seen anything (besides VAPIC accesses) but I think it would be 
prudent to prevent any VPMU activity from happening. I can see, for 
example MSRs and APIC vector being written. All of which look benign on 
the first sight but who knows...


-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-xen-4.5] x86/pvh/vpmu: Disable VPMU for PVH guests

2014-11-25 Thread Konrad Rzeszutek Wilk 
On Tue, Nov 25, 2014 at 04:39:54PM +, Jan Beulich wrote:
  On 25.11.14 at 17:19, boris.ostrov...@oracle.com wrote:
  On 11/25/2014 09:55 AM, Jan Beulich wrote:
 
  Regardless, do you think that disabling VPMU for PVH is worth anyway?
  That depends on what (bad) consequences not doing so has.
  
  I haven't seen anything (besides VAPIC accesses) but I think it would be 
  prudent to prevent any VPMU activity from happening. I can see, for 
  example MSRs and APIC vector being written. All of which look benign on 
  the first sight but who knows...
 
 Yeah, it's not really a problem to put it in (if Konrad agrees; remember
 that PVH is still experimental, and hence fixing bugs caused only by it
 may be out of scope at this point - in any event I think that if your
 patch is to go in, mine should too).

The beaty of experimental is that we can add it later in the cycle as
at worst they will regress something that is unbaked already.

From that perspective the bar to put fixes for 'experimental' is lower
than normal code. The part that I am worried about is the common paths
and this potentially causing regressions on the those.

But the potential for that is low that I am OK with these patches
going in. 
 
 Jan
 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel