[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v15 11/21] x86/VPMU: Interface for setting PMU mode and flags



>>> On 26.11.14 at 15:32, <boris.ostrovsky@xxxxxxxxxx> wrote:

> On 11/25/2014 08:49 AM, Jan Beulich wrote:
>>>>> On 17.11.14 at 00:07, <boris.ostrovsky@xxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.