arch/x86/events/amd/core.c | 37 +++++++++++++++++++++++++++++++++++- arch/x86/events/amd/lbr.c | 13 +------------ arch/x86/events/perf_event.h | 13 +++++++++++++ 3 files changed, 50 insertions(+), 13 deletions(-)
Hi all, This backport wires up AMD perfmon v2 so BPF and other software clients can snapshot LBR stacks on demand, similar to the Intel support upstream. The series keeps the LBR-freeze path branchless, adds the perf_snapshot_branch_stack callback for AMD, and drops the sampling-only restriction now that snapshots can be taken from software contexts. Leon Hwang (4): perf/x86/amd: Ensure amd_pmu_core_disable_all() is always inlined perf/x86/amd: Avoid taking branches before disabling LBR perf/x86/amd: Support capturing LBR from software events perf/x86/amd: Don't reject non-sampling events with configured LBR arch/x86/events/amd/core.c | 37 +++++++++++++++++++++++++++++++++++- arch/x86/events/amd/lbr.c | 13 +------------ arch/x86/events/perf_event.h | 13 +++++++++++++ 3 files changed, 50 insertions(+), 13 deletions(-) -- 2.52.0
On Fri, Jan 02, 2026 at 05:03:16PM +0800, Leon Hwang wrote: > Hi all, > > This backport wires up AMD perfmon v2 so BPF and other software clients > can snapshot LBR stacks on demand, similar to the Intel support > upstream. The series keeps the LBR-freeze path branchless, adds the > perf_snapshot_branch_stack callback for AMD, and drops the > sampling-only restriction now that snapshots can be taken from software > contexts. > > Leon Hwang (4): > perf/x86/amd: Ensure amd_pmu_core_disable_all() is always inlined > perf/x86/amd: Avoid taking branches before disabling LBR > perf/x86/amd: Support capturing LBR from software events > perf/x86/amd: Don't reject non-sampling events with configured LBR Why is this for a stable kernel? Isn't it a new feature? If you need this feature, why not use a newer kernel tree? thanks, greg k-h
On 2026/1/8 19:11, Greg KH wrote: > On Fri, Jan 02, 2026 at 05:03:16PM +0800, Leon Hwang wrote: >> Hi all, >> >> This backport wires up AMD perfmon v2 so BPF and other software clients >> can snapshot LBR stacks on demand, similar to the Intel support >> upstream. The series keeps the LBR-freeze path branchless, adds the >> perf_snapshot_branch_stack callback for AMD, and drops the >> sampling-only restriction now that snapshots can be taken from software >> contexts. >> >> Leon Hwang (4): >> perf/x86/amd: Ensure amd_pmu_core_disable_all() is always inlined >> perf/x86/amd: Avoid taking branches before disabling LBR >> perf/x86/amd: Support capturing LBR from software events >> perf/x86/amd: Don't reject non-sampling events with configured LBR > > > Why is this for a stable kernel? Isn't it a new feature? If you need > this feature, why not use a newer kernel tree? > This series enables LBR snapshot support on AMD CPUs. You are right that this is not a bug fix but a feature enablement. If backporting this to the stable tree is not appropriate, that is totally fine. In that case, I will carry these changes in our in-house stable kernel instead. Thanks for the clarification. Thanks, Leon > thanks, > > greg k-h
On Thu, Jan 08, 2026 at 09:53:46PM +0800, Leon Hwang wrote:
>
>
> On 2026/1/8 19:11, Greg KH wrote:
> > On Fri, Jan 02, 2026 at 05:03:16PM +0800, Leon Hwang wrote:
> >> Hi all,
> >>
> >> This backport wires up AMD perfmon v2 so BPF and other software clients
> >> can snapshot LBR stacks on demand, similar to the Intel support
> >> upstream. The series keeps the LBR-freeze path branchless, adds the
> >> perf_snapshot_branch_stack callback for AMD, and drops the
> >> sampling-only restriction now that snapshots can be taken from software
> >> contexts.
> >>
> >> Leon Hwang (4):
> >> perf/x86/amd: Ensure amd_pmu_core_disable_all() is always inlined
> >> perf/x86/amd: Avoid taking branches before disabling LBR
> >> perf/x86/amd: Support capturing LBR from software events
> >> perf/x86/amd: Don't reject non-sampling events with configured LBR
> >
> >
> > Why is this for a stable kernel? Isn't it a new feature? If you need
> > this feature, why not use a newer kernel tree?
> >
>
> This series enables LBR snapshot support on AMD CPUs.
>
> You are right that this is not a bug fix but a feature enablement.
> If backporting this to the stable tree is not appropriate, that is
> totally fine. In that case, I will carry these changes in our in-house
> stable kernel instead.
Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
For what types of patches are acceptable for stable kernels.
And really, you should be moving off of 6.6.y now anyway :)
thanks,
greg k-h
On 2026/1/8 22:02, Greg KH wrote: > On Thu, Jan 08, 2026 at 09:53:46PM +0800, Leon Hwang wrote: >> >> >> On 2026/1/8 19:11, Greg KH wrote: >>> On Fri, Jan 02, 2026 at 05:03:16PM +0800, Leon Hwang wrote: >>>> Hi all, >>>> >>>> This backport wires up AMD perfmon v2 so BPF and other software clients >>>> can snapshot LBR stacks on demand, similar to the Intel support >>>> upstream. The series keeps the LBR-freeze path branchless, adds the >>>> perf_snapshot_branch_stack callback for AMD, and drops the >>>> sampling-only restriction now that snapshots can be taken from software >>>> contexts. >>>> >>>> Leon Hwang (4): >>>> perf/x86/amd: Ensure amd_pmu_core_disable_all() is always inlined >>>> perf/x86/amd: Avoid taking branches before disabling LBR >>>> perf/x86/amd: Support capturing LBR from software events >>>> perf/x86/amd: Don't reject non-sampling events with configured LBR >>> >>> >>> Why is this for a stable kernel? Isn't it a new feature? If you need >>> this feature, why not use a newer kernel tree? >>> >> >> This series enables LBR snapshot support on AMD CPUs. >> >> You are right that this is not a bug fix but a feature enablement. >> If backporting this to the stable tree is not appropriate, that is >> totally fine. In that case, I will carry these changes in our in-house >> stable kernel instead. > > Please read: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > > For what types of patches are acceptable for stable kernels. > > And really, you should be moving off of 6.6.y now anyway :) > > thanks, > > greg k-h Thanks for the pointer and the guidance. I’ll review the stable kernel rules more carefully and adjust accordingly. Appreciate the advice. :) Thanks, Leon
© 2016 - 2026 Red Hat, Inc.