[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191115183341.GB22747@tassilo.jf.intel.com>
Date: Fri, 15 Nov 2019 10:33:41 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: "Liang, Kan" <kan.liang@...ux.intel.com>
Cc: Peter Zijlstra <peterz@...radead.org>, acme@...hat.com,
mingo@...nel.org, linux-kernel@...r.kernel.org, eranian@...gle.com
Subject: Re: [PATCH] perf/x86/intel: Avoid PEBS_ENABLE MSR access in PMI
> @@ -2620,6 +2624,15 @@ static int handle_pmi_common(struct pt_regs *regs,
> u64 status)
> handled++;
> x86_pmu.drain_pebs(regs);
> status &= x86_pmu.intel_ctrl | GLOBAL_STATUS_TRACE_TOPAPMI;
> +
> + /*
> + * PMI may land after cpuc->enabled=0 in x86_pmu_disable()
> and
> + * PMI throttle may be triggered for the PMI.
> + * For this rare case, intel_pmu_pebs_disable() will not
> touch
> + * MSR_IA32_PEBS_ENABLE. Explicitly disable the PEBS here.
> + */
> + if (unlikely(!cpuc->enabled && !cpuc->pebs_enabled))
> + wrmsrl(MSR_IA32_PEBS_ENABLE, 0);
How does the enable_all() code know to reenable it in this case?
-Andi
Powered by blists - more mailing lists