[PATCH] perf/x86/amd/lbr: Freeze LBR on PMI only when kernel branches are recorded

[PATCH] perf/x86/amd/lbr: Freeze LBR on PMI only when kernel branches are recorded

[Puranjay Mohan]

On CPUs with X86_FEATURE_AMD_LBR_PMC_FREEZE the LBR is always frozen on
PMI, so the branch stack ends before the IP and callchain, which are
taken when the NMI is delivered. IBS rejects branch-stack events, so
there is no precise alternative.

The freeze only keeps the PMI handler's branches out of the stack, which
matters only when branches into the kernel are recorded; without it the
stack fills with the handler's own branches. A user-only filter does not
record them, and parts without the feature are never frozen (see commit
598c2fafc06f ("perf/x86/amd/lbr: Use freeze based on availability")).

Freeze unless the value written to LBR_SELECT, which is shared by all
events on the CPU, suppresses branches into the kernel.

With perf record -e ex_ret_brn_tkn:u -j any,u on a Zen 5 part running
CPython, the function of the sampled IP differs from the function of
LBR[0].to in 84.3% of samples with the freeze and in 0.1% without it.

Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
 arch/x86/events/amd/lbr.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c
index a55646fcb8465..7ec50380ac81d 100644
--- a/arch/x86/events/amd/lbr.c
+++ b/arch/x86/events/amd/lbr.c
@@ -392,7 +392,7 @@ void amd_pmu_lbr_sched_task(struct perf_event_pmu_context *pmu_ctx,
 void amd_pmu_lbr_enable_all(void)
 {
 	struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
-	u64 lbr_select, dbg_ctl, dbg_extn_cfg;
+	u64 lbr_select = 0, dbg_ctl, dbg_extn_cfg;
 
 	if (!cpuc->lbr_users || !x86_pmu.lbr_nr)
 		return;
@@ -405,7 +405,12 @@ void amd_pmu_lbr_enable_all(void)
 
 	if (cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE)) {
 		rdmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
-		wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI);
+		/* Freeze unless the filter suppresses branches into the kernel */
+		if (lbr_select & LBR_KERNEL)
+			dbg_ctl &= ~DEBUGCTLMSR_FREEZE_LBRS_ON_PMI;
+		else
+			dbg_ctl |= DEBUGCTLMSR_FREEZE_LBRS_ON_PMI;
+		wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
 	}
 
 	rdmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg);

base-commit: 0f443787a7f6ae907975742680aac2600483eaf1
-- 
2.53.0-Meta

Re: [PATCH] perf/x86/amd/lbr: Freeze LBR on PMI only when kernel branches are recorded

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf/x86/amd/lbr: cleared lbr_select in amd_pmu_lbr_del() forces PMI freeze
--

commit 2fc471183ee73ff1339b34a8c3b4d4e03264c10b
Author: Puranjay Mohan <puranjay@kernel.org>

perf/x86/amd/lbr: Freeze LBR on PMI only when kernel branches are recorded

This commit skips setting DEBUGCTLMSR_FREEZE_LBRS_ON_PMI on CPUs with
X86_FEATURE_AMD_LBR_PMC_FREEZE when LBR_SELECT suppresses branches into the
kernel.

> diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c
> index a55646fcb8465..7ec50380ac81d 100644
> --- a/arch/x86/events/amd/lbr.c
> +++ b/arch/x86/events/amd/lbr.c
> @@ -392,7 +392,7 @@ void amd_pmu_lbr_sched_task(struct perf_event_pmu_context *pmu_ctx,
>  void amd_pmu_lbr_enable_all(void)
>  {
>  	struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
> -	u64 lbr_select, dbg_ctl, dbg_extn_cfg;
> +	u64 lbr_select = 0, dbg_ctl, dbg_extn_cfg;
>  
>  	if (!cpuc->lbr_users || !x86_pmu.lbr_nr)
>  		return;
> @@ -405,7 +405,12 @@ void amd_pmu_lbr_enable_all(void)
>  
>  	if (cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE)) {
>  		rdmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
> -		wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI);
> +		/* Freeze unless the filter suppresses branches into the kernel */
> +		if (lbr_select & LBR_KERNEL)
> +			dbg_ctl &= ~DEBUGCTLMSR_FREEZE_LBRS_ON_PMI;
> +		else
> +			dbg_ctl |= DEBUGCTLMSR_FREEZE_LBRS_ON_PMI;
> +		wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
>  	}

[Severity: Medium]
Can DEBUGCTLMSR_FREEZE_LBRS_ON_PMI still be set for user-only branch-stack
events when more than one branch-stack event is scheduled on the same CPU?

When two user-only branch-stack events are added via amd_pmu_lbr_add(),
cpuc->lbr_users is incremented to 2 and cpuc->lbr_select is set to 1.

If one of those events is subsequently removed or scheduled out via
x86_pmu_del() -> amd_pmu_del_event() -> amd_pmu_lbr_del(), cpuc->lbr_select
is unconditionally cleared even though another branch-stack event remains
active:

arch/x86/events/amd/lbr.c:amd_pmu_lbr_del() {
	if (!x86_pmu.lbr_nr)
		return;

	if (has_branch_stack(event))
		cpuc->lbr_select = 0;

	cpuc->lbr_users--;
}

When amd_pmu_lbr_enable_all() then runs with cpuc->lbr_users == 1 and
cpuc->lbr_select == 0:

	if (cpuc->lbr_select) {
		lbr_select = cpuc->lbr_sel->config & LBR_SELECT_MASK;
		wrmsrq(MSR_AMD64_LBR_SELECT, lbr_select);
	}

the if (cpuc->lbr_select) block is skipped, leaving the local lbr_select at
0 (and also leaving MSR_AMD64_LBR_SELECT zeroed after a context switch calls
amd_pmu_lbr_sched_task() -> amd_pmu_lbr_reset()).

Wouldn't (lbr_select & LBR_KERNEL) then evaluate to false and re-enable
DEBUGCTLMSR_FREEZE_LBRS_ON_PMI despite the remaining active event
suppressing kernel branches?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261023124157.75524-1-puranjay@kernel.org?part=1

Re: [PATCH] perf/x86/amd/lbr: Freeze LBR on PMI only when kernel branches are recorded

[Puranjay Mohan]

On Fri, Oct 23, 2026 at 2:01 PM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] perf/x86/amd/lbr: cleared lbr_select in amd_pmu_lbr_del() forces PMI freeze
> --
>
> commit 2fc471183ee73ff1339b34a8c3b4d4e03264c10b
> Author: Puranjay Mohan <puranjay@kernel.org>
>
> perf/x86/amd/lbr: Freeze LBR on PMI only when kernel branches are recorded
>
> This commit skips setting DEBUGCTLMSR_FREEZE_LBRS_ON_PMI on CPUs with
> X86_FEATURE_AMD_LBR_PMC_FREEZE when LBR_SELECT suppresses branches into the
> kernel.
>
> > diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c
> > index a55646fcb8465..7ec50380ac81d 100644
> > --- a/arch/x86/events/amd/lbr.c
> > +++ b/arch/x86/events/amd/lbr.c
> > @@ -392,7 +392,7 @@ void amd_pmu_lbr_sched_task(struct perf_event_pmu_context *pmu_ctx,
> >  void amd_pmu_lbr_enable_all(void)
> >  {
> >       struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
> > -     u64 lbr_select, dbg_ctl, dbg_extn_cfg;
> > +     u64 lbr_select = 0, dbg_ctl, dbg_extn_cfg;
> >
> >       if (!cpuc->lbr_users || !x86_pmu.lbr_nr)
> >               return;
> > @@ -405,7 +405,12 @@ void amd_pmu_lbr_enable_all(void)
> >
> >       if (cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE)) {
> >               rdmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
> > -             wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI);
> > +             /* Freeze unless the filter suppresses branches into the kernel */
> > +             if (lbr_select & LBR_KERNEL)
> > +                     dbg_ctl &= ~DEBUGCTLMSR_FREEZE_LBRS_ON_PMI;
> > +             else
> > +                     dbg_ctl |= DEBUGCTLMSR_FREEZE_LBRS_ON_PMI;
> > +             wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
> >       }
>
> [Severity: Medium]
> Can DEBUGCTLMSR_FREEZE_LBRS_ON_PMI still be set for user-only branch-stack
> events when more than one branch-stack event is scheduled on the same CPU?
>
> When two user-only branch-stack events are added via amd_pmu_lbr_add(),
> cpuc->lbr_users is incremented to 2 and cpuc->lbr_select is set to 1.
>
> If one of those events is subsequently removed or scheduled out via
> x86_pmu_del() -> amd_pmu_del_event() -> amd_pmu_lbr_del(), cpuc->lbr_select
> is unconditionally cleared even though another branch-stack event remains
> active:
>
> arch/x86/events/amd/lbr.c:amd_pmu_lbr_del() {
>         if (!x86_pmu.lbr_nr)
>                 return;
>
>         if (has_branch_stack(event))
>                 cpuc->lbr_select = 0;
>
>         cpuc->lbr_users--;
> }
>
> When amd_pmu_lbr_enable_all() then runs with cpuc->lbr_users == 1 and
> cpuc->lbr_select == 0:
>
>         if (cpuc->lbr_select) {
>                 lbr_select = cpuc->lbr_sel->config & LBR_SELECT_MASK;
>                 wrmsrq(MSR_AMD64_LBR_SELECT, lbr_select);
>         }
>
> the if (cpuc->lbr_select) block is skipped, leaving the local lbr_select at
> 0 (and also leaving MSR_AMD64_LBR_SELECT zeroed after a context switch calls
> amd_pmu_lbr_sched_task() -> amd_pmu_lbr_reset()).
>
> Wouldn't (lbr_select & LBR_KERNEL) then evaluate to false and re-enable
> DEBUGCTLMSR_FREEZE_LBRS_ON_PMI despite the remaining active event
> suppressing kernel branches?

The behaviour is real, but it is not a regression: it is what
amd_pmu_lbr_del() does today. It clears lbr_select while other
branch-stack events remain, so LBR_SELECT is not reprogrammed.
amd_pmu_lbr_reset() on sched-in can also leave it zeroed, which
allows kernel branches. Clearing the freeze in that state would let
the PMI handler's own branches into the LBR, so it has to stay set,
as it does without this patch.

Restoring the benefit means tracking the shared filter properly in
lbr_del(), which is a separate change.

Re: [PATCH] perf/x86/amd/lbr: Freeze LBR on PMI only when kernel branches are recorded

[Sandipan Das]

On 23-10-2026 18:11, Puranjay Mohan wrote:
> On CPUs with X86_FEATURE_AMD_LBR_PMC_FREEZE the LBR is always frozen on
> PMI, so the branch stack ends before the IP and callchain, which are
> taken when the NMI is delivered. IBS rejects branch-stack events, so
> there is no precise alternative.
> 
> The freeze only keeps the PMI handler's branches out of the stack, which
> matters only when branches into the kernel are recorded; without it the
> stack fills with the handler's own branches. A user-only filter does not
> record them, and parts without the feature are never frozen (see commit
> 598c2fafc06f ("perf/x86/amd/lbr: Use freeze based on availability")).
> 
> Freeze unless the value written to LBR_SELECT, which is shared by all
> events on the CPU, suppresses branches into the kernel.
> 
> With perf record -e ex_ret_brn_tkn:u -j any,u on a Zen 5 part running
> CPython, the function of the sampled IP differs from the function of
> LBR[0].to in 84.3% of samples with the freeze and in 0.1% without it.
> 

I think the reason behind this observation is skid. Without freeze, LBR
keeps recording new branches until the PMI arrives and causes a privilege
level change. With freeze, it stops at the exact point where a PMC
overflows.

The sites where the overflows occur are the potential hotspots. So if
skid is large enough and the intent of PGO workflows is to always capture
the last branch right before the overflow/hotspot, then having freeze
enabled may be necessary.

> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
> ---
>  arch/x86/events/amd/lbr.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c
> index a55646fcb8465..7ec50380ac81d 100644
> --- a/arch/x86/events/amd/lbr.c
> +++ b/arch/x86/events/amd/lbr.c
> @@ -392,7 +392,7 @@ void amd_pmu_lbr_sched_task(struct perf_event_pmu_context *pmu_ctx,
>  void amd_pmu_lbr_enable_all(void)
>  {
>  	struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
> -	u64 lbr_select, dbg_ctl, dbg_extn_cfg;
> +	u64 lbr_select = 0, dbg_ctl, dbg_extn_cfg;
>  
>  	if (!cpuc->lbr_users || !x86_pmu.lbr_nr)
>  		return;
> @@ -405,7 +405,12 @@ void amd_pmu_lbr_enable_all(void)
>  
>  	if (cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE)) {
>  		rdmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
> -		wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl | DEBUGCTLMSR_FREEZE_LBRS_ON_PMI);
> +		/* Freeze unless the filter suppresses branches into the kernel */
> +		if (lbr_select & LBR_KERNEL)
> +			dbg_ctl &= ~DEBUGCTLMSR_FREEZE_LBRS_ON_PMI;
> +		else
> +			dbg_ctl |= DEBUGCTLMSR_FREEZE_LBRS_ON_PMI;
> +		wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
>  	}
>  
>  	rdmsrq(MSR_AMD_DBG_EXTN_CFG, dbg_extn_cfg);
> 
> base-commit: 0f443787a7f6ae907975742680aac2600483eaf1