>>> On 26.11.14 at 15:32, <boris.ostrov...@oracle.com> wrote:
> On 11/25/2014 08:49 AM, Jan Beulich wrote:
>>>>> On 17.11.14 at 00:07, <boris.ostrov...@oracle.com> wrote:
>>> @@ -244,19 +256,19 @@ void vpmu_initialise(struct vcpu *v)
>>> switch ( vendor )
>>> {
>>> case X86_VENDOR_AMD:
>>> - if ( svm_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
>>> - opt_vpmu_enabled = 0;
>>> + if ( svm_vpmu_initialise(v) != 0 )
>>> + vpmu_mode = XENPMU_MODE_OFF;
>>> break;
>>>
>>> case X86_VENDOR_INTEL:
>>> - if ( vmx_vpmu_initialise(v, opt_vpmu_enabled) != 0 )
>>> - opt_vpmu_enabled = 0;
>>> + if ( vmx_vpmu_initialise(v) != 0 )
>>> + vpmu_mode = XENPMU_MODE_OFF;
>>> break;
>> So this turns off the vPMU globally upon failure of initializing
>> some random vCPU. Why is that? I see this was the case even
>> before your entire series, but shouldn't this be fixed _before_
>> enhancing the whole thing to support PV/PVH?
>
> Yes, that's probably too strong. Do you want to fix this as an early
> patch (before PV(H)) support gets in? I'd rather do it in the patch that
> moves things into initcalls.
Yes, I think this should be fixed in a prereq patch, thus allowing it
to be easily backported if so desired.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
