All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Puranjay Mohan" <puranjay@kernel.org>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH RFC] perf/x86/amd/lbr: Don't freeze the LBR on PMI for user-only filters
Date: Thu, 05 Nov 2026 17:23:01 +0000	[thread overview]
Message-ID: <sashiko-outbox-199604@kernel.org> (raw)
In-Reply-To: <20261105170340.165507-1-puranjay@kernel.org>

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

  reply	other threads:[~2026-11-05 17:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-23 12:41 [PATCH] perf/x86/amd/lbr: Freeze LBR on PMI only when kernel branches are recorded Puranjay Mohan
2026-10-23 13:01 ` sashiko-bot
2026-10-23 15:18   ` Puranjay Mohan
2026-10-26 15:35 ` Sandipan Das
2026-10-29 20:12 ` Andrii Nakryiko
2026-11-02 10:08   ` Sandipan Das
2026-11-03 19:09     ` Andrii Nakryiko
2026-11-05  6:17       ` Sandipan Das
2026-11-05 16:58         ` Andrii Nakryiko
2026-11-05 17:03         ` [PATCH RFC] perf/x86/amd/lbr: Don't freeze the LBR on PMI for user-only filters Puranjay Mohan
2026-11-05 17:23           ` sashiko-bot [this message]
2026-11-06  1:07           ` Andrii Nakryiko
2026-11-10 19:05             ` Andrii Nakryiko
2026-11-12 11:09               ` Ravi Bangoria
2026-11-12 16:40                 ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-199604@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=puranjay@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.