[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

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

[Andrii Nakryiko]

On Fri, Oct 23, 2026 at 5:42 AM Puranjay Mohan <puranjay@kernel.org> 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.
>
> 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)

On Intel CPU side, we reset this FREEZE bit in
__intel_pmu_lbr_enable() if is_lbr_call_stack_bit_set(), with the
comment "LBR callstack does not work well with FREEZE_LBRS_ON_PMI.".
So this is not *exactly* what Intel side of things is doing, and I'm
not sure I fully understand the differences, so hopefully someone more
knowledgeable can help.

But what Puranjay is trying to do here is to at least make a
user-mode-only LBR and IP + callstack to be coherent (for PGO data
collection, which we then use for user space app compilation), by
disabling freezing for LBR.

It doesn't seem like there is anything we can do on AMD hardware for
when we want kernel-side LBR and precise IP to be in sync,
unfortunately, but at least for user-space only case it would allow us
to not plain disable freezing altogether at kernel boot time.

Does this approach make sense?


> +                       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

[Sandipan Das]

On 30-10-2026 01:42, Andrii Nakryiko wrote:
> On Fri, Oct 23, 2026 at 5:42 AM Puranjay Mohan <puranjay@kernel.org> 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.
>>
>> 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)
> 
> On Intel CPU side, we reset this FREEZE bit in
> __intel_pmu_lbr_enable() if is_lbr_call_stack_bit_set(), with the
> comment "LBR callstack does not work well with FREEZE_LBRS_ON_PMI.".
> So this is not *exactly* what Intel side of things is doing, and I'm
> not sure I fully understand the differences, so hopefully someone more
> knowledgeable can help.
> 
> But what Puranjay is trying to do here is to at least make a
> user-mode-only LBR and IP + callstack to be coherent (for PGO data
> collection, which we then use for user space app compilation), by
> disabling freezing for LBR.
> 
> It doesn't seem like there is anything we can do on AMD hardware for
> when we want kernel-side LBR and precise IP to be in sync,
> unfortunately, but at least for user-space only case it would allow us
> to not plain disable freezing altogether at kernel boot time.
> 
> Does this approach make sense?
> 

Yes, the intent to keep the LBR and IP coherent is clear. However, my
concern is that this may end up dropping the branches preceding the
hotspots since a CPU might keep executing in userspace until the PMI
handler runs. I'm not sure about the effect that this is going to have
on PGO but what if we rely on a mechanism (UAPI + tool flags) to let
users explicitly request freeze?

If there is an use-case where freeze helps, then the facility can be
explicitly requested.

> 
>> +                       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

[Andrii Nakryiko]

On Mon, Nov 2, 2026 at 2:08 AM Sandipan Das <sandipan.das@amd.com> wrote:
>
> On 30-10-2026 01:42, Andrii Nakryiko wrote:
> > On Fri, Oct 23, 2026 at 5:42 AM Puranjay Mohan <puranjay@kernel.org> 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.
> >>
> >> 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)
> >
> > On Intel CPU side, we reset this FREEZE bit in
> > __intel_pmu_lbr_enable() if is_lbr_call_stack_bit_set(), with the
> > comment "LBR callstack does not work well with FREEZE_LBRS_ON_PMI.".
> > So this is not *exactly* what Intel side of things is doing, and I'm
> > not sure I fully understand the differences, so hopefully someone more
> > knowledgeable can help.
> >
> > But what Puranjay is trying to do here is to at least make a
> > user-mode-only LBR and IP + callstack to be coherent (for PGO data
> > collection, which we then use for user space app compilation), by
> > disabling freezing for LBR.
> >
> > It doesn't seem like there is anything we can do on AMD hardware for
> > when we want kernel-side LBR and precise IP to be in sync,
> > unfortunately, but at least for user-space only case it would allow us
> > to not plain disable freezing altogether at kernel boot time.
> >
> > Does this approach make sense?
> >
>
> Yes, the intent to keep the LBR and IP coherent is clear. However, my
> concern is that this may end up dropping the branches preceding the
> hotspots since a CPU might keep executing in userspace until the PMI
> handler runs. I'm not sure about the effect that this is going to have
> on PGO but what if we rely on a mechanism (UAPI + tool flags) to let
> users explicitly request freeze?
>
> If there is an use-case where freeze helps, then the facility can be
> explicitly requested.

heh, it's actually the other way, freezing **hurts** consistency
here... should API requested freeze *opt-out*? because freezing, if
supported by CPU, currently, is the default behavior not requiring
opt-in. Or are you proposing to not enable freeze (even if
cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE) is true), and then
make user space request freezing with the new UAPI config flag?

I'm not against expanding UAPI, but it feels like a very quirky little
thing which also stems from AMD-only limitation of not supporting
precise IP capture with LBR enabled


BTW, the alternative that internal customers actually requested
initially instead of this was to completely disable freezing at start
up through the kernel command line. Which seems like the worst
outcome.

Thoughts? This all seems unfortunately messy, but hopefully we can
figure out some non-intrusive but workable solution.

>
> >
> >> +                       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

[Sandipan Das]

On 04-11-2026 00:39, Andrii Nakryiko wrote:
> On Mon, Nov 2, 2026 at 2:08 AM Sandipan Das <sandipan.das@amd.com> wrote:
>>
>> On 30-10-2026 01:42, Andrii Nakryiko wrote:
>>> On Fri, Oct 23, 2026 at 5:42 AM Puranjay Mohan <puranjay@kernel.org> 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.
>>>>
>>>> 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)
>>>
>>> On Intel CPU side, we reset this FREEZE bit in
>>> __intel_pmu_lbr_enable() if is_lbr_call_stack_bit_set(), with the
>>> comment "LBR callstack does not work well with FREEZE_LBRS_ON_PMI.".
>>> So this is not *exactly* what Intel side of things is doing, and I'm
>>> not sure I fully understand the differences, so hopefully someone more
>>> knowledgeable can help.
>>>
>>> But what Puranjay is trying to do here is to at least make a
>>> user-mode-only LBR and IP + callstack to be coherent (for PGO data
>>> collection, which we then use for user space app compilation), by
>>> disabling freezing for LBR.
>>>
>>> It doesn't seem like there is anything we can do on AMD hardware for
>>> when we want kernel-side LBR and precise IP to be in sync,
>>> unfortunately, but at least for user-space only case it would allow us
>>> to not plain disable freezing altogether at kernel boot time.
>>>
>>> Does this approach make sense?
>>>
>>
>> Yes, the intent to keep the LBR and IP coherent is clear. However, my
>> concern is that this may end up dropping the branches preceding the
>> hotspots since a CPU might keep executing in userspace until the PMI
>> handler runs. I'm not sure about the effect that this is going to have
>> on PGO but what if we rely on a mechanism (UAPI + tool flags) to let
>> users explicitly request freeze?
>>
>> If there is an use-case where freeze helps, then the facility can be
>> explicitly requested.
> 
> heh, it's actually the other way, freezing **hurts** consistency
> here... should API requested freeze *opt-out*? because freezing, if
> supported by CPU, currently, is the default behavior not requiring
> opt-in. Or are you proposing to not enable freeze (even if
> cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE) is true), and then
> make user space request freezing with the new UAPI config flag?
> 

The latter. The default will be freeze disabled irrespective of the
CPUID feature bit.

> I'm not against expanding UAPI, but it feels like a very quirky little
> thing which also stems from AMD-only limitation of not supporting
> precise IP capture with LBR enabled
> 

I agree but it can live as an AMD-only flag in perf_event_attr.config2
or something similar and advertised through x86_pmu.format_attrs.

> 
> BTW, the alternative that internal customers actually requested
> initially instead of this was to completely disable freezing at start
> up through the kernel command line. Which seems like the worst
> outcome.
> 
> Thoughts? This all seems unfortunately messy, but hopefully we can
> figure out some non-intrusive but workable solution.
> 
>>
>>>
>>>> +                       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

[Andrii Nakryiko]

On Wed, Nov 4, 2026 at 10:17 PM Sandipan Das <sandipan.das@amd.com> wrote:
>
> On 04-11-2026 00:39, Andrii Nakryiko wrote:
> > On Mon, Nov 2, 2026 at 2:08 AM Sandipan Das <sandipan.das@amd.com> wrote:
> >>
> >> On 30-10-2026 01:42, Andrii Nakryiko wrote:
> >>> On Fri, Oct 23, 2026 at 5:42 AM Puranjay Mohan <puranjay@kernel.org> 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.
> >>>>
> >>>> 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)
> >>>
> >>> On Intel CPU side, we reset this FREEZE bit in
> >>> __intel_pmu_lbr_enable() if is_lbr_call_stack_bit_set(), with the
> >>> comment "LBR callstack does not work well with FREEZE_LBRS_ON_PMI.".
> >>> So this is not *exactly* what Intel side of things is doing, and I'm
> >>> not sure I fully understand the differences, so hopefully someone more
> >>> knowledgeable can help.
> >>>
> >>> But what Puranjay is trying to do here is to at least make a
> >>> user-mode-only LBR and IP + callstack to be coherent (for PGO data
> >>> collection, which we then use for user space app compilation), by
> >>> disabling freezing for LBR.
> >>>
> >>> It doesn't seem like there is anything we can do on AMD hardware for
> >>> when we want kernel-side LBR and precise IP to be in sync,
> >>> unfortunately, but at least for user-space only case it would allow us
> >>> to not plain disable freezing altogether at kernel boot time.
> >>>
> >>> Does this approach make sense?
> >>>
> >>
> >> Yes, the intent to keep the LBR and IP coherent is clear. However, my
> >> concern is that this may end up dropping the branches preceding the
> >> hotspots since a CPU might keep executing in userspace until the PMI
> >> handler runs. I'm not sure about the effect that this is going to have
> >> on PGO but what if we rely on a mechanism (UAPI + tool flags) to let
> >> users explicitly request freeze?
> >>
> >> If there is an use-case where freeze helps, then the facility can be
> >> explicitly requested.
> >
> > heh, it's actually the other way, freezing **hurts** consistency
> > here... should API requested freeze *opt-out*? because freezing, if
> > supported by CPU, currently, is the default behavior not requiring
> > opt-in. Or are you proposing to not enable freeze (even if
> > cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE) is true), and then
> > make user space request freezing with the new UAPI config flag?
> >
>
> The latter. The default will be freeze disabled irrespective of the
> CPUID feature bit.
>

sounds good, thanks! I'll ask Puranjay to make these changes for the
next revision

> > I'm not against expanding UAPI, but it feels like a very quirky little
> > thing which also stems from AMD-only limitation of not supporting
> > precise IP capture with LBR enabled
> >
>
> I agree but it can live as an AMD-only flag in perf_event_attr.config2
> or something similar and advertised through x86_pmu.format_attrs.
>
> >
> > BTW, the alternative that internal customers actually requested
> > initially instead of this was to completely disable freezing at start
> > up through the kernel command line. Which seems like the worst
> > outcome.
> >
> > Thoughts? This all seems unfortunately messy, but hopefully we can
> > figure out some non-intrusive but workable solution.
> >
> >>
> >>>
> >>>> +                       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
> >>>>
> >>
>

[PATCH RFC] perf/x86/amd/lbr: Don't freeze the LBR on PMI for user-only filters

[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 if branches into the kernel are recorded. Skip it when
LBR_SELECT suppresses them, and add a freeze format bit (config2:0) to
request it anyway.

Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
Thanks both. A user-only default with an explicit request works for me,
with one exception I would like to keep: when branches into the kernel
are recorded the freeze has to stay. On a Zen 5 part with the freeze
cleared and a user+kernel filter, every entry in every sample was a
branch taken by amd_pmu_v2_handle_irq() or amd_pmu_lbr_read(), so users
recording kernel branches would regress with a "never freeze" default.

This RFC does the following:
 - LBR_SELECT suppresses kernel branches: no freeze, unless the new
   AMD-only freeze format bit (config2:0, advertised through the format
   attributes) is set.
 - Otherwise: freeze as today.

That needs no tool changes for the user-only case and gives an explicit
way to request the freeze. This version is only compile tested; I will
retest on a Zen 5 part if the approach is acceptable.

 arch/x86/events/amd/core.c | 14 ++++++++++++++
 arch/x86/events/amd/lbr.c  | 21 ++++++++++++++++++---
 2 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
index 49b6b8fce5664..d63649c756a58 100644
--- a/arch/x86/events/amd/core.c
+++ b/arch/x86/events/amd/core.c
@@ -1404,8 +1404,22 @@ static struct attribute_group group_events_amd_brs = {
 
 #endif	/* CONFIG_PERF_EVENTS_AMD_BRS */
 
+PMU_FORMAT_ATTR(freeze, "config2:0");
+
+static struct attribute *amd_pmu_lbr_format_attrs[] = {
+	&format_attr_freeze.attr,
+	NULL,
+};
+
+static struct attribute_group group_format_amd_lbr = {
+	.name       = "format",
+	.attrs      = amd_pmu_lbr_format_attrs,
+	.is_visible = amd_branches_is_visible,
+};
+
 static const struct attribute_group *amd_attr_update[] = {
 	&group_caps_amd_branches,
+	&group_format_amd_lbr,
 #ifdef CONFIG_PERF_EVENTS_AMD_BRS
 	&group_events_amd_brs,
 #endif
diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c
index a55646fcb8465..f45e2c53566af 100644
--- a/arch/x86/events/amd/lbr.c
+++ b/arch/x86/events/amd/lbr.c
@@ -10,6 +10,12 @@
 /* LBR Branch Select valid bits */
 #define LBR_SELECT_MASK		0x1ff
 
+/* attr.config2: freeze the LBR on PMI */
+#define LBR_CFG2_FREEZE		BIT_ULL(0)
+
+/* Software only, masked out before writing LBR_SELECT */
+#define LBR_FREEZE		BIT_ULL(63)
+
 /*
  * LBR Branch Select filter bits which when set, ensures that the
  * corresponding type of branches are not recorded
@@ -307,6 +313,9 @@ static int amd_pmu_lbr_setup_filter(struct perf_event *event)
 	/* Filter bits operate in suppress mode */
 	reg->config = mask ^ LBR_SELECT_MASK;
 
+	if (event->attr.config2 & LBR_CFG2_FREEZE)
+		reg->config |= LBR_FREEZE;
+
 	return 0;
 }
 
@@ -392,20 +401,26 @@ 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_cfg = 0, lbr_select = 0, dbg_ctl, dbg_extn_cfg;
 
 	if (!cpuc->lbr_users || !x86_pmu.lbr_nr)
 		return;
 
 	/* Set hardware branch filter */
 	if (cpuc->lbr_select) {
-		lbr_select = cpuc->lbr_sel->config & LBR_SELECT_MASK;
+		lbr_cfg = cpuc->lbr_sel->config;
+		lbr_select = lbr_cfg & LBR_SELECT_MASK;
 		wrmsrq(MSR_AMD64_LBR_SELECT, lbr_select);
 	}
 
 	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);
+		/* Skip the freeze if kernel branches are suppressed, unless asked */
+		if ((lbr_select & LBR_KERNEL) && !(lbr_cfg & LBR_FREEZE))
+			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 RFC] perf/x86/amd/lbr: Don't freeze the LBR on PMI for user-only filters

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] perf/x86/amd/lbr: freeze format exposed and accepted without feature check
- [Medium] perf/x86/amd/lbr: wrong freeze state in amd_pmu_lbr_enable_all() for multi-event LBR
--

commit 4ee339b2b2fdce2f2f85b09e93b75d05b24049b1
Author: Puranjay Mohan <puranjay@kernel.org>

perf/x86/amd/lbr: Don't freeze the LBR on PMI for user-only filters

This commit skips setting DEBUGCTLMSR_FREEZE_LBRS_ON_PMI on PMI when kernel
branches are suppressed in LBR_SELECT, while adding a freeze format attribute
(config2:0) to allow user space to explicitly request freezing the LBR.

> diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
> index 49b6b8fce5664..d63649c756a58 100644
> --- a/arch/x86/events/amd/core.c
> +++ b/arch/x86/events/amd/core.c
> @@ -1404,8 +1404,22 @@ static struct attribute_group group_events_amd_brs = {
>  
>  #endif	/* CONFIG_PERF_EVENTS_AMD_BRS */
>  
> +PMU_FORMAT_ATTR(freeze, "config2:0");
> +
> +static struct attribute *amd_pmu_lbr_format_attrs[] = {
> +	&format_attr_freeze.attr,
> +	NULL,
> +};
> +
> +static struct attribute_group group_format_amd_lbr = {
> +	.name       = "format",
> +	.attrs      = amd_pmu_lbr_format_attrs,
> +	.is_visible = amd_branches_is_visible,
> +};
> +
>  static const struct attribute_group *amd_attr_update[] = {
>  	&group_caps_amd_branches,
> +	&group_format_amd_lbr,
>  #ifdef CONFIG_PERF_EVENTS_AMD_BRS
>  	&group_events_amd_brs,
>  #endif
> diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c
> index a55646fcb8465..f45e2c53566af 100644
> --- a/arch/x86/events/amd/lbr.c
> +++ b/arch/x86/events/amd/lbr.c
> @@ -10,6 +10,12 @@
>  /* LBR Branch Select valid bits */
>  #define LBR_SELECT_MASK		0x1ff
>  
> +/* attr.config2: freeze the LBR on PMI */
> +#define LBR_CFG2_FREEZE		BIT_ULL(0)
> +
> +/* Software only, masked out before writing LBR_SELECT */
> +#define LBR_FREEZE		BIT_ULL(63)
> +
>  /*
>   * LBR Branch Select filter bits which when set, ensures that the
>   * corresponding type of branches are not recorded
> @@ -307,6 +313,9 @@ static int amd_pmu_lbr_setup_filter(struct perf_event *event)
>  	/* Filter bits operate in suppress mode */
>  	reg->config = mask ^ LBR_SELECT_MASK;
>  
> +	if (event->attr.config2 & LBR_CFG2_FREEZE)
> +		reg->config |= LBR_FREEZE;
> +
>  	return 0;
>  }

[Severity: Medium]
Should group_format_amd_lbr and amd_pmu_lbr_setup_filter() check for
X86_FEATURE_AMD_LBR_PMC_FREEZE?

In arch/x86/events/amd/core.c, group_format_amd_lbr uses
amd_branches_is_visible():

static umode_t
amd_branches_is_visible(struct kobject *kobj, struct attribute *attr, int i)
{
	return x86_pmu.lbr_nr ? attr->mode : 0;
}

Because x86_pmu.lbr_nr is non-zero both on Zen 3 BRS systems (where
amd_brs_detect() sets x86_pmu.lbr_nr = 16) and on LBRv2 systems or VMs that do
not advertise X86_FEATURE_AMD_LBR_PMC_FREEZE, the sysfs format attribute
/sys/bus/event_source/devices/cpu/format/freeze is exposed on systems that
cannot freeze the LBR on PMI.

In addition, when a user opens an event with LBR_CFG2_FREEZE set in
event->attr.config2 on those systems, amd_pmu_lbr_setup_filter() accepts it
and sets LBR_FREEZE in reg->config, while amd_pmu_lbr_enable_all() silently
ignores it because the MSR_IA32_DEBUGCTLMSR update is guarded by
cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE).

Should the visibility callback and amd_pmu_lbr_setup_filter() verify
cpu_feature_enabled(X86_FEATURE_AMD_LBR_PMC_FREEZE) and return -EOPNOTSUPP if
freeze is requested when unsupported?

> @@ -392,20 +401,26 @@ 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_cfg = 0, lbr_select = 0, dbg_ctl, dbg_extn_cfg;
>  
>  	if (!cpuc->lbr_users || !x86_pmu.lbr_nr)
>  		return;
>  
>  	/* Set hardware branch filter */
>  	if (cpuc->lbr_select) {
> -		lbr_select = cpuc->lbr_sel->config & LBR_SELECT_MASK;
> +		lbr_cfg = cpuc->lbr_sel->config;
> +		lbr_select = lbr_cfg & LBR_SELECT_MASK;
>  		wrmsrq(MSR_AMD64_LBR_SELECT, lbr_select);
>  	}
>  
>  	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);
> +		/* Skip the freeze if kernel branches are suppressed, unless asked */
> +		if ((lbr_select & LBR_KERNEL) && !(lbr_cfg & LBR_FREEZE))
> +			dbg_ctl &= ~DEBUGCTLMSR_FREEZE_LBRS_ON_PMI;
> +		else
> +			dbg_ctl |= DEBUGCTLMSR_FREEZE_LBRS_ON_PMI;
> +		wrmsrq(MSR_IA32_DEBUGCTLMSR, dbg_ctl);
>  	}

[Severity: Medium]
Can this re-enable DEBUGCTLMSR_FREEZE_LBRS_ON_PMI for an active user-only LBR
event when multiple branch-stack events are scheduled on the same CPU?

In arch/x86/events/amd/lbr.c, amd_pmu_lbr_add() sets cpuc->lbr_select = 1 and
increments cpuc->lbr_users, but amd_pmu_lbr_del() unconditionally clears
cpuc->lbr_select to 0 whenever any branch-stack event is removed:

void amd_pmu_lbr_del(struct perf_event *event)
{
	struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);

	if (!x86_pmu.lbr_nr)
		return;

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

	cpuc->lbr_users--;
...
}

If two user-only branch-stack events are active on a CPU (cpuc->lbr_users == 2)
and one of them is removed via amd_pmu_lbr_del(), cpuc->lbr_users remains 1
 while cpuc->lbr_select becomes 0.

When amd_pmu_v2_enable_all() then calls amd_pmu_lbr_enable_all(), the
if (cpuc->lbr_select) block is skipped, leaving lbr_cfg and lbr_select as 0.
As a result, (lbr_select & LBR_KERNEL) evaluates to false and
amd_pmu_lbr_enable_all() sets DEBUGCTLMSR_FREEZE_LBRS_ON_PMI in
MSR_IA32_DEBUGCTLMSR even though the remaining active event suppresses kernel
branches and did not request a freeze.

Additionally, if a user-only event with freeze=0 is added alongside an event
that requires freezing (either recording kernel branches or with freeze=1),
amd_pmu_lbr_add() overwrites cpuc->lbr_sel->config with the new event's config,
causing amd_pmu_lbr_enable_all() to clear DEBUGCTLMSR_FREEZE_LBRS_ON_PMI for
both events.

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

Re: [PATCH RFC] perf/x86/amd/lbr: Don't freeze the LBR on PMI for user-only filters

[Andrii Nakryiko]

On Thu, Nov 5, 2026 at 9:03 AM Puranjay Mohan <puranjay@kernel.org> 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 if branches into the kernel are recorded. Skip it when
> LBR_SELECT suppresses them, and add a freeze format bit (config2:0) to
> request it anyway.
>
> Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
> ---
> Thanks both. A user-only default with an explicit request works for me,
> with one exception I would like to keep: when branches into the kernel
> are recorded the freeze has to stay. On a Zen 5 part with the freeze
> cleared and a user+kernel filter, every entry in every sample was a
> branch taken by amd_pmu_v2_handle_irq() or amd_pmu_lbr_read(), so users
> recording kernel branches would regress with a "never freeze" default.
>
> This RFC does the following:
>  - LBR_SELECT suppresses kernel branches: no freeze, unless the new
>    AMD-only freeze format bit (config2:0, advertised through the format
>    attributes) is set.
>  - Otherwise: freeze as today.
>
> That needs no tool changes for the user-only case and gives an explicit
> way to request the freeze. This version is only compile tested; I will
> retest on a Zen 5 part if the approach is acceptable.
>
>  arch/x86/events/amd/core.c | 14 ++++++++++++++
>  arch/x86/events/amd/lbr.c  | 21 ++++++++++++++++++---
>  2 files changed, 32 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
> index 49b6b8fce5664..d63649c756a58 100644
> --- a/arch/x86/events/amd/core.c
> +++ b/arch/x86/events/amd/core.c
> @@ -1404,8 +1404,22 @@ static struct attribute_group group_events_amd_brs = {
>
>  #endif /* CONFIG_PERF_EVENTS_AMD_BRS */
>
> +PMU_FORMAT_ATTR(freeze, "config2:0");
> +
> +static struct attribute *amd_pmu_lbr_format_attrs[] = {
> +       &format_attr_freeze.attr,
> +       NULL,
> +};
> +
> +static struct attribute_group group_format_amd_lbr = {
> +       .name       = "format",
> +       .attrs      = amd_pmu_lbr_format_attrs,
> +       .is_visible = amd_branches_is_visible,
> +};
> +
>  static const struct attribute_group *amd_attr_update[] = {
>         &group_caps_amd_branches,
> +       &group_format_amd_lbr,
>  #ifdef CONFIG_PERF_EVENTS_AMD_BRS
>         &group_events_amd_brs,
>  #endif
> diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c
> index a55646fcb8465..f45e2c53566af 100644
> --- a/arch/x86/events/amd/lbr.c
> +++ b/arch/x86/events/amd/lbr.c
> @@ -10,6 +10,12 @@
>  /* LBR Branch Select valid bits */
>  #define LBR_SELECT_MASK                0x1ff
>
> +/* attr.config2: freeze the LBR on PMI */
> +#define LBR_CFG2_FREEZE                BIT_ULL(0)
> +
> +/* Software only, masked out before writing LBR_SELECT */
> +#define LBR_FREEZE             BIT_ULL(63)
> +
>  /*
>   * LBR Branch Select filter bits which when set, ensures that the
>   * corresponding type of branches are not recorded
> @@ -307,6 +313,9 @@ static int amd_pmu_lbr_setup_filter(struct perf_event *event)
>         /* Filter bits operate in suppress mode */
>         reg->config = mask ^ LBR_SELECT_MASK;
>
> +       if (event->attr.config2 & LBR_CFG2_FREEZE)
> +               reg->config |= LBR_FREEZE;
> +
>         return 0;
>  }
>
> @@ -392,20 +401,26 @@ 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_cfg = 0, lbr_select = 0, dbg_ctl, dbg_extn_cfg;
>
>         if (!cpuc->lbr_users || !x86_pmu.lbr_nr)
>                 return;
>
>         /* Set hardware branch filter */
>         if (cpuc->lbr_select) {
> -               lbr_select = cpuc->lbr_sel->config & LBR_SELECT_MASK;
> +               lbr_cfg = cpuc->lbr_sel->config;
> +               lbr_select = lbr_cfg & LBR_SELECT_MASK;
>                 wrmsrq(MSR_AMD64_LBR_SELECT, lbr_select);
>         }
>
>         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);
> +               /* Skip the freeze if kernel branches are suppressed, unless asked */
> +               if ((lbr_select & LBR_KERNEL) && !(lbr_cfg & LBR_FREEZE))

heh, so we basically either

a) opt-in freeze with *new config*, but do it *only for non-kernel LBR*

or

b) opt-out freeze *only for non-kernel LBR* _unconditionally_, but
without adding any new config

In both cases we have a behavior that makes sense in practice, but a)
adds some new config, while b) doesn't add anything. End result is the
same, just more configuration and need to change user space code to
opt-out the freeze.

Is a) worth it, or we should stick to b) and keep it simple, Sandipan?

> +                       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
>