On Tue, Nov 25, 2014 at 04:39:54PM +, Jan Beulich wrote:
> >>> On 25.11.14 at 17:19, 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
>>> On 25.11.14 at 17:19, 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
> p
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 happe
>>> On 25.11.14 at 15:38, 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
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
>>> On 24.11.14 at 20:49, wrote:
> Currently when VPMU is enabled on a system both HVM and PVH VPCUs will
> initialize their VPMUs, including setting up vpmu_ops. As result even
> though VPMU will not work for PVH guests (APIC is not supported there),
> the guest may decide to perform a write to a
Currently when VPMU is enabled on a system both HVM and PVH VPCUs will
initialize their VPMUs, including setting up vpmu_ops. As result even
though VPMU will not work for PVH guests (APIC is not supported there),
the guest may decide to perform a write to a PMU MSR. This will cause a
call to is_vla
