[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |