Backport VeLinux k6.6 Venice IBS Enhancements - #125
PvsNarasimha wants to merge 34 commits into
Conversation
|
Thanks for backporting this. |
|
Thanks for reviewing. I checked this issue and found that the upstream fix has already been backported in this branch. The commit is: dde994d ("perf build: Add tools/arch/x86/include/asm/amd/ibs.h to sync the headers") Could you please let me know on which architecture and configuration you encountered the build failure? Also, if possible, could you share the build log or the exact error message? That would help me understand whether there is another missing dependency or a different issue causing the failure. |
The build failure is on aarch64. The error log: |
|
Thanks for pointing out the issue. I have addressed the problem with a few patches included in this PR and the cover letter, and it now appears to be resolved. Could you please verify it on your end? Please find the relevant build log snippet below: CC util/arm64-frame-pointer-unwind-support.o As shown above, util/amd-sample-raw.o is now being compiled successfully, and the build completes without issues. |
|
Is the arm64 patch necessary? |
|
Hi, Thanks for pointing this out. Yes, the two arm64/sysreg patches are necessary.
Without: arm64 patches the perf build fails on the target AArch64 VeLinux kernel. Regarding the commits reported by CI:
I verified that these commits are not required to resolve the build failure. The perf build succeeds without them, so they are not needed for this backport. Thanks. |
Hi, Thanks for your clarification. Thanks |
|
Hi, Okay, sure. I will backport the two Arm64 fix patches, d7396a72eae7 and ee811bc733be, and update the commit list accordingly. |
|
Hi, I've updated the patch list with the required dependencies, and the build is now successful. Could you please review and verify it on your end? |
Thanks for your work, now CI and compiled are successfully. |
|
Hello， we have some failed tests on Venice when applying this PR, could you help to verify them. Thanks.
perf record -q -e cycles:u -j any,u -a -o cycles-u-branch.data -- sleep 1
perf record --call-graph fp -j any,u -e cycles:upp -a -c 16009 -- sleep 1
perf stat -e l3_cache_accesses,l3_misses -a -- sleep 1
perf stat -M PipelineL1,PipelineL2 -- sleep 1
perf stat -e amd_umc_0// -a -- sleep 1
perf stat -e amd_umc_0/umc_cas_cmd.rd/,amd_umc_0/umc_cas_cmd.wr/ -a -- sleep 1 |
|
Hi, These are usage issues, not bugs in the PR. Cases 2 and 3 fail the same way on the stock pre-PR perf too, so they're hardware/usage behavior rather than regressions. /home/amd/Narasimha/kernel/tools/perf/perf # PR build, matches kernel
4,5,6 work as written Summary Not a failure — perf report does complete; the original timeout 30 just killed it early because -j any,u makes report disassemble every sampled DSO via objdump. timeout 180 resolves it. |
|
I recheck the umc and failed again. perf stat -a -e amd_umc_0/umc_mem_clk/ -- sleep 1 Performance counter stats for 'system wide': This is some ai analysis, it may be help. • The root cause is clear: the kernel decodes the number of available UMC hardware counters as zero, so perf cannot assign a counter to the requested event. This is not because the BSK kernel is missing the existing generic UMC support patches:
The problem is the CPUID encoding reported by this AMD Family 1Ah Model 50h engineering sample: CPUID Fn80000022: The current kernel reads the total number of UMC counters from EBX[21:16], which evaluates to zero. However, bit 22 is set. If the field is interpreted as a 64 total counters / 16 active UMCs = 4 counters per UMC Because the kernel currently calculates: 0 total counters / 16 UMCs = 0 counters per UMC it registers all 16 amd_umc_* PMUs with zero counters. When perf tries to schedule an event, no hardware counter can be allocated. The event therefore has A more accurate conclusion is:
The latest upstream Linux code still defines num_umc_pmc as a six-bit field and uses the same UMC initialization logic: upstream field definition The next step is to confirm the official CPUID Fn80000022 EBX definition for Family 1Ah Model 50h with AMD or the platform team:
Because 64 = 16 × 4, the most likely explanation is missing seven-bit counter enumeration support for this new platform, rather than a perf command issue. |
|
Hi @Liangyan-bd, I tested this on my local machine, and the command is working as expected. Please find the validation details below. Steps to Build and Test
root@volcano9f8e-oshost:/home/amd/Narasimha/kernel/tools/perf# ./perf stat -a -e amd_umc_0/umc_mem_clk/ -- sleep 1 Performance counter stats for 'system wide': root@volcano9f8e-oshost:/home/amd/Narasimha/kernel/tools/perf# dmesg | grep amd_uncore # should show "4 amd_umc_N counters detected" on this box The output confirms detection of: 16 AMD Data Fabric (DF) counters Test System Details: The validation was performed on an AMD EPYC 9755 (Turin, Family 26) platform. The UMC performance events were detected correctly, and the perf stat command executed successfully without any issues. Please let me know if you need any additional information or if you observe any issues while validating this on your setup. |
commit 6057b90ecc84f232dd32a047a086a4c4c271765f upstream. While at it, rename the same function in s390 cpum_sf PMU. Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ravi Bangoria <ravi.bangoria@amd.com> Reviewed-by: Ravi Bangoria <ravi.bangoria@amd.com> Acked-by: Thomas Richter <tmricht@linux.ibm.com> Link: https://lore.kernel.org/r/20241203180441.1634709-2-namhyung@kernel.org Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit d29e744c71673a71da8f8522799ee02744cad6c9 upstream.
While IBS is available for per-thread profiling, still regular users
cannot open an event due to the default paranoid setting (2) which
doesn't allow unprivileged users to get kernel samples. That means
it needs to set exclude_kernel bit in the attribute but IBS driver
would reject it since it has PERF_PMU_CAP_NO_EXCLUDE. This is not what
we want and I've been getting requests to fix this issue.
This should be done in the hardware, but until we get the HW fix we may
allow exclude_{kernel,user,hv} in the attribute and silently drop the
samples in the PMU IRQ handler. It won't guarantee the sampling
frequency or even it'd miss some with fixed period too. Not ideal,
but that'd still be helpful to regular users.
To minimize the confusion, let's add 'swfilt' bit to attr.config2 which
is exposed in the sysfs format directory so that users can figure out
if the kernel support the privilege filters by software.
$ perf record -e ibs_op/swfilt=1/u true
This uses perf_exclude_event() which checks regs->cs. But it should be
fine because set_linear_ip() also updates the CS according to the RIP
provided by IBS.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Ravi Bangoria <ravi.bangoria@amd.com>
Reviewed-by: Ravi Bangoria <ravi.bangoria@amd.com>
Link: https://lore.kernel.org/r/20241203180441.1634709-3-namhyung@kernel.org
Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 003c0414318a1829a1a5b195ad81e8a7960c3f5d upstream. Definition of these macros are very simple and they are used at only one place. Get rid of unnecessary redirection. Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Namhyung Kim <namhyung@kernel.org> Link: https://lkml.kernel.org/r/20250115054438.1021-2-ravi.bangoria@amd.com Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 88c7bcad71c83f52f24108dedcecae0d18dbc627 upstream.
Valid perf event sample period value for IBS PMUs (Fetch and Op both)
is limited to multiple of 0x10. perf_ibs_init() has this check:
if (!event->attr.sample_freq && hwc->sample_period & 0x0f)
return -EINVAL;
But it's broken since hwc->sample_period will always be 0 when
event->attr.sample_freq is 0 (irrespective of event->attr.freq value.)
One option to fix this is to change the condition:
- if (!event->attr.sample_freq && hwc->sample_period & 0x0f)
+ if (!event->attr.freq && hwc->sample_period & 0x0f)
However, that will break all userspace tools which have been using IBS
event with sample_period not multiple of 0x10.
Another option is to remove the condition altogether and mask lower
nibble _silently_, same as what current code is inadvertently doing.
I'm preferring this approach as it keeps the existing behavior.
Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lkml.kernel.org/r/20250115054438.1021-3-ravi.bangoria@amd.com
Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
…nterface
commit e1e7844ced88f9558a48579390a7d4eaac6a28eb upstream.
Most perf_event_attr->config bits directly maps to IBS_{FETCH|OP}_CTL
MSR. Since the sample period is programmed in these control registers,
IBS PMU driver allows opening an IBS event by setting sample period
value directly in perf_event_attr->config instead of using explicit
perf_event_attr->sample_period interface.
However, this logic is not applicable for freq mode events since the
semantics of control register fields are applicable only to fixed
sample period whereas the freq mode event adjusts sample period after
each and every sample. Currently, IBS driver (unintentionally) allows
creating freq mode event via ->config interface, which is semantically
wrong as well as detrimental because it can be misused to bypass
perf_event_max_sample_rate checks.
Don't allow freq mode event creation through perf_event_attr->config
interface.
Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lkml.kernel.org/r/20250115054438.1021-6-ravi.bangoria@amd.com
Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit b2fc7b282bf7c1253b01c8da84e894539a3e709d upstream. 0x10 is the minimum sample period for IBS Fetch and 0x90 for IBS Op. Current IBS PMU driver uses 0x10 for both the PMUs, which is incorrect. Fix it by adding PMU specific minimum period values in struct perf_ibs. Also, bail out opening a 'sample period mode' event if the user requested sample period is less than PMU supported minimum value. For a 'freq mode' event, start calibrating sample period from PMU specific minimum period. Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Namhyung Kim <namhyung@kernel.org> Link: https://lkml.kernel.org/r/20250115054438.1021-7-ravi.bangoria@amd.com Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 1afbdd970f50f2e0431fae26b25d4e54e561fa7f upstream. IBS Fetch and IBS Op PMUs have constraints on sample period. The sample period is verified at the time of opening an event but not at the ioctl() interface. Hence, a user can open an event with valid period but change it later with ioctl(). Add a ->check_period() callback to verify the period provided at ioctl() is also valid. Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Namhyung Kim <namhyung@kernel.org> Link: https://lkml.kernel.org/r/20250115054438.1021-8-ravi.bangoria@amd.com Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit fa5d0a824e3bbd1f793d962f9e012ab0a8ee11c5 upstream. The sample_period needs to be recalibrated after every sample to match the desired sampling freq for a 'freq mode event'. Since the next sample_period is calculated by generic kernel, PMU specific constraints are not (explicitly) reckoned. The sample_period value is programmed in a MaxCnt field of IBS PMUs, and the MaxCnt field has following constraints: 1) MaxCnt must be multiple of 0x10. Kernel keeps track of residual / over-counted period into period_left, which should take care of this constraint by programming MaxCnt with (sample_period & ~0xF) and adding remaining period into the next sample. 2) MaxCnt must be >= 0x10 for IBS Fetch PMU and >= 0x90 for IBS Op PMU. Currently, IBS PMU driver allows sample_period below min_period, which is an undefined HW behavior. Reset sample_period to min_period whenever it's less than that. Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20250115054438.1021-9-ravi.bangoria@amd.com Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit d20610c19b4a22bc69085b7eb7a02741d51de30e upstream. IBS Op PMU on Zen5 uarch added new Load Latency filtering capability. It's advertised by CPUID_Fn8000001B_EAX bit 12. When enabled, IBS HW will raise interrupt only for sample that had an IbsDcMissLat value greater than N cycles, where N is a programmable value defined as multiples of 128 (i.e. 128, 256, 384 etc.) from 128-2048 cycles. Similar to L3MissOnly, IBS HW internally drops the sample and restarts if the sample does not meet the filtering criteria. Add support for LdLat filtering in IBS Op PMU. Since hardware supports threshold in multiple of 128, add a software filter on top to support latency threshold with the granularity of 1 cycle between [128-2048]. Example usage: # perf record -a -e ibs_op/ldlat=128/ -- sleep 5 Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20250205060547.1337-2-ravi.bangoria@amd.com Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 0b347a4218da08b1eb400c259d193bff463dae87 upstream.
IBS Op PMU on Zen5 reports DTLB and page size information differently
compared to prior generation. The change is enumerated by
CPUID_Fn8000001B_EAX[19].
IBS_OP_DATA3 Zen3/4 Zen5
----------------------------------------------------------------
19 IbsDcL2TlbHit1G Reserved
----------------------------------------------------------------
6 IbsDcL2tlbHit2M Reserved
----------------------------------------------------------------
5 IbsDcL1TlbHit1G PageSize:
4 IbsDcL1TlbHit2M 0 - 4K
1 - 2M
2 - 1G
3 - Reserved
Valid only if
IbsDcPhyAddrValid = 1
----------------------------------------------------------------
3 IbsDcL2TlbMiss IbsDcL2TlbMiss
Valid only if
IbsDcPhyAddrValid = 1
----------------------------------------------------------------
2 IbsDcL1tlbMiss IbsDcL1tlbMiss
Valid only if
IbsDcPhyAddrValid = 1
----------------------------------------------------------------
o Currently, only bit 2 and 3 are interpreted by IBS NMI handler for
PERF_SAMPLE_DATA_SRC. Add dependency on IbsDcPhyAddrValid for those
bits.
o Introduce new IBS Op PMU capability and expose it to userspace via
PMU's sysfs directory.
Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20250205060547.1337-3-ravi.bangoria@amd.com
Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 65a99264f5e5a2bcc8c905f7b2d633e8991672ac upstream. The IBS software filter is filtering kernel samples for regular users in the PMI handler. It checks the instruction address in the IBS register to determine if it was in kernel mode or not. But it turns out that it's possible to report a kernel data address even if the instruction address belongs to user-space. Matteo Rizzo found that when an instruction raises an exception, IBS can report some kernel data addresses like IDT while holding the faulting instruction's RIP. To prevent an information leak, it should double check if the data address in PERF_SAMPLE_DATA is in the kernel space as well. [ mingo: Clarified the changelog ] Suggested-by: Matteo Rizzo <matteorizzo@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20250317163755.1842589-1-namhyung@kernel.org Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 50a53b60e141d7e31368a87e222e4dd5597bd4ae upstream.
Although IBS "swfilt" can prevent leaking samples with kernel RIP to the
userspace, there are few subtle cases where a 'data' address and/or a
'branch target' address can fall under kernel address range although RIP
is from userspace. Prevent leaking kernel 'data' addresses by discarding
such samples when {exclude_kernel=1,swfilt=1}.
IBS can now be invoked by unprivileged user with the introduction of
"swfilt". However, this creates a loophole in the interface where an
unprivileged user can get physical address of the userspace virtual
addresses through IBS register raw dump (PERF_SAMPLE_RAW). Prevent this
as well.
This upstream commit fixed the most obvious leak:
65a99264f5e5 perf/x86: Check data address for IBS software filter
Follow that up with a more complete fix.
Fixes: d29e744c7167 ("perf/x86: Relax privilege filter restriction on AMD IBS")
Suggested-by: Matteo Rizzo <matteorizzo@google.com>
Co-developed-by: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/20250321161251.1033-1-ravi.bangoria@amd.com
Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 3846389c03a8518884f09056611619bd1461ffc7 upstream. Collect AMD specific platform header files in <asm/amd/*.h>. Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mario Limonciello <superm1@kernel.org> Link: https://lore.kernel.org/r/20250413084144.3746608-2-mingo@kernel.org Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 01336b5559785a136de1cac49705f63a70a755bc upstream.
Add interrupt throttling accounting for below cases:
o IBS Op PMU: A software filter (in addition to the hardware filter)
drops samples whose load latency is below the user-specified
threshold.
o IBS Fetch PMU: Samples discarded due to the zero-RIP erratum (#1197).
Although these samples are discarded, the NMI cost is still incurred, so
they should be counted for interrupt throttling.
Fixes: 26db2e0 ("perf/x86/amd/ibs: Work around erratum #1197")
Fixes: d20610c19b4a22bc69085b7eb7a02741d51de30e ("perf/amd/ibs: Add support for OP Load Latency Filtering")
Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Link: https://patch.msgid.link/20260216042216.1440-2-ravi.bangoria@amd.com
Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 723a290326e015b07931eabc603d3735999377be upstream.
Commit 50a53b60e141 ("perf/amd/ibs: Prevent leaking sensitive data to
userspace") zeroed the physical address and also cleared the PhyAddrVal
flag before copying the value into a perf sample to avoid exposing
physical addresses to unprivileged users.
Clearing PhyAddrVal, however, has an unintended side-effect: several
other IBS fields are considered valid only when this bit is set. As a
result, those otherwise correct fields are discarded, reducing IBS
functionality.
Continue to zero the physical address, but keep the PhyAddrVal bit
intact so the related fields remain usable while still preventing any
address leak.
Fixes: 50a53b60e141 ("perf/amd/ibs: Prevent leaking sensitive data to userspace")
Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Link: https://patch.msgid.link/20260216042216.1440-4-ravi.bangoria@amd.com
Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit b0a09142622a994c4f4088c3f61db5da87cfc711 upstream.
Calling perf_allow_kernel() from the NMI context is unsafe and could be
fatal. Capture the permission at event-initialization time by storing it
in event->hw.flags, and have the NMI handler rely on that cached flag
instead of making the call directly.
[Backport Changes]
In file arch/x86/events/amd/ibs.c, within the function perf_ibs_init(),
the upstream code adds conditional block with perf_allow_kernel().
However, in our codebase perf_allow_kernel() is implemented as
perf_allow_kernel(&event->attr). Therefore the call was adjusted
accordingly during the backport.
Fixes: 50a53b60e141d ("perf/amd/ibs: Prevent leaking sensitive data to userspace")
Reported-by: Sadasivan Shaiju <sadasivan.shaiju2@amd.com>
Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Link: https://patch.msgid.link/20260216042216.1440-5-ravi.bangoria@amd.com
Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 8ae68bfec97596a3656ce8d0a7b1240d888eab10 upstream. IBS OP on future hardware supports recording samples only for instructions that does streaming store. Like the existing IBS filters, samples pointing to instruction which does not cause streaming store are discarded and IBS restarts internally. Example: $ perf record -e ibs_op/strmst=1/ -- <workload> Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260216042530.1546-7-ravi.bangoria@amd.com Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit b2ea0f541d354c10186a894e8bf5bf83abf8a517 upstream. IBS OP on future hardware can indicate data source from remote socket as well. Advertise this capability to userspace so that userspace tools can decode IBS data accordingly. Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260216042530.1546-8-ravi.bangoria@amd.com Signed-off-by: suryasaimadhu <SaiMadhu.KoyyalaHariVenkata@amd.com> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 79baac8 upstream. GCC 14 introduces a new -Walloc-size included in -Wextra which errors out like: builtin-top.c: In function ‘prompt_integer’: builtin-top.c:360:21: error: allocation of insufficient size ‘0’ for type ‘char’ with size ‘1’ [-Werror=alloc-size] 360 | char *buf = malloc(0), *p; | ^~~~~~ Just set it to NULL, getline() will do the allocation. Signed-off-by: Sun Haiyong <sunhaiyong@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20231204082055.91877-1-siyanteng@loongson.cn Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 7bbe8f0 upstream. the definition of calloc is as follows: void *calloc(size_t nmemb, size_t size); number of members is in the first parameter and the size is in the second parameter. Fix error messages on gcc 14 20240102: error: 'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] Committer notes: I noticed this on fedora 40 and rawhide. Signed-off-by: Sun Haiyong <sunhaiyong@loongson.cn> Acked-by: Namhyung Kim <namhyung@kernel.org> Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20240106094129.3337057-1-siyanteng@loongson.cn Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit bb6b4143503750318a3f85975186db899a3caaf2 upstream.
To pick up the changes from:
861c6b1185fbb2e3 ("x86/platform/amd: Add standard header guards to <asm/amd/ibs.h>")
A small change to tools/perf/check-headers.sh was made to cope with the
move of this header done in:
3846389c03a85188 ("x86/platform/amd: Move the <asm/amd-ibs.h> header to <asm/amd/ibs.h>")
That don't result in any changes in the tools, just address this perf
build warning:
Warning: Kernel ABI header differences:
diff -u tools/arch/x86/include/asm/amd/ibs.h arch/x86/include/asm/amd/ibs.h
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/aEtCi0pup5FEwnzn@x1
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit c1ab4ce3cb759f69fb9085a060e568b73e8f5cd8 upstream.
Synchronize with what we did with the kernel side header in:
3846389c03a8 ("x86/platform/amd: Move the <asm/amd-ibs.h> header to <asm/amd/ibs.h>")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 0a35bd285f43c26ccec33872fc6bb679069eaea8 upstream. Convert SCTLR_EL2 to the sysreg infrastructure, as per the 2025-12_rel revision of the Registers.json file. Note that we slightly deviate from the above, as we stick to the ARM ARM M.a definition of SCTLR_EL2[9], which is RES0, in order to avoid dragging the POE2 definitions... Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260202184329.2724080-2-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit c382ee674c8b5005798606267d660cf995218b18 upstream. Convert TRFCR to automatic generation. Add separate definitions for ELx and EL2 as TRFCR_EL1 doesn't have CX. This also mirrors the previous definition so no code change is required. Also add TRFCR_EL12 which will start to be used in a later commit. Unfortunately, to avoid breaking the Perf build with duplicate definition errors, the tools copy of the sysreg.h header needs to be updated at the same time rather than the usual second commit. This is because the generated version of sysreg (arch/arm64/include/generated/asm/sysreg-defs.h), is currently shared and tools/ does not have its own copy. Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: James Clark <james.clark@arm.com> Signed-off-by: James Clark <james.clark@linaro.org> Link: https://lore.kernel.org/r/20250106142446.628923-4-james.clark@linaro.org Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
… events
commit d7396a72eae795d7f968fb451237b6ac1616d712 upstream.
SCTLR_EL2.EIS and SCTLR_EL2.EOS control whether exception entry and
exit at EL2 are Context Synchronisation Events (CSEs). Per ARM DDI
0487 M.b D24.2.175 (p. D24-9754):
- !FEAT_ExS: the bit is RES1, so the entry/exit is unconditionally
a CSE.
- FEAT_ExS: the reset value is architecturally UNKNOWN; software
must set the bit to make the entry/exit a CSE.
INIT_SCTLR_EL2_MMU_ON in arch/arm64/include/asm/sysreg.h sets neither
bit. KVM/arm64 hot paths rely on ERET from EL2 being a CSE, and on
synchronous EL1->EL2 entry being a CSE, to elide explicit ISBs after
MSRs to context-switching system registers (HCR_EL2, ZCR_EL2,
ptrauth keys, etc.). On FEAT_ExS hardware those reliances are not
architecturally backed unless EOS=1 (and, for entry, EIS=1).
Until commit 0a35bd285f43 ("arm64: Convert SCTLR_EL2 to sysreg
infrastructure"), SCTLR_EL2_RES1 was a hand-rolled mask that
included BIT(11) (EOS) and BIT(22) (EIS), so INIT_SCTLR_EL2_MMU_ON
was setting both unconditionally. The conversion made
SCTLR_EL2_RES1 auto-generated; because the sysreg tooling only
models unconditionally-RES1 fields and EIS/EOS are RES1 only when
FEAT_ExS is absent, the auto-generated mask is UL(0). The seven
other bits dropped from the old mask (positions 4, 5, 16, 18, 23,
28, 29) are unconditionally RES1 in the E2H=0 SCTLR_EL2 layout per
DDI 0487 M.b D24.2.175, so dropping them is harmless. EIS and EOS
are the only bits whose semantics changed for FEAT_ExS hardware
and where the kernel relies on the value being 1.
Make the guarantee explicit: include SCTLR_ELx_EIS | SCTLR_ELx_EOS in
INIT_SCTLR_EL2_MMU_ON so that EL2 exception entry and exit are
unconditionally CSEs regardless of whether FEAT_ExS is implemented.
This matches the pairing in arch/arm64/kvm/config.c which treats EIS
and EOS together as RES1 under !FEAT_ExS.
Fixes: 0a35bd285f43 ("arm64: Convert SCTLR_EL2 to sysreg infrastructure")
Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com>
Assisted-by: Gemini:gemini-3.1-pro review-prompts
Signed-off-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260501112149.2824881-2-tabba@google.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit aaf69eff6cdb8613ff1f6a520821f769dc92f969 upstream.
Currently the userspace and kernel filters for guests are never set, so
no trace will be generated for them. Add support for tracing guests by
passing the desired TRFCR value to KVM so it can be applied to the
guest.
By writing either E1TRE or E0TRE, filtering on either guest kernel or
guest userspace is also supported. And if both E1TRE and E0TRE are
cleared when exclude_guest is set, that option is supported too. This
change also brings exclude_host support which is difficult to add as a
separate commit without excess churn and resulting in no trace at all.
cpu_prohibit_trace() gets moved to TRBE because the ETM driver doesn't
need the read, it already has the base TRFCR value. TRBE only needs
the read to disable it and then restore.
Testing
=======
The addresses were counted with the following:
$ perf report -D | grep -Eo 'EL2|EL1|EL0' | sort | uniq -c
Guest kernel only:
$ perf record -e cs_etm//Gk -a -- true
535 EL1
1 EL2
Guest user only (only 5 addresses because the guest runs slowly in the
model):
$ perf record -e cs_etm//Gu -a -- true
5 EL0
Host kernel only:
$ perf record -e cs_etm//Hk -a -- true
3501 EL2
Host userspace only:
$ perf record -e cs_etm//Hu -a -- true
408 EL0
1 EL2
Signed-off-by: James Clark <james.clark@arm.com>
Link: https://lore.kernel.org/r/20250106142446.628923-8-james.clark@linaro.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit 01009b06a6b52d8439c55b530633a971c13b6cb2 upstream. There is no such thing as TRFCR_ELx in the architecture. What we have is TRFCR_EL1, for which TRFCR_EL12 is an accessor. Rename TRFCR_ELx_* to TRFCR_EL1_*, and fix the bit of code using these names. Similarly, TRFCR_EL12 is redefined as a mapping to TRFCR_EL1. Reviewed-by: James Clark <james.clark@linaro.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/87cygsqgkh.wl-maz@kernel.org Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
commit ee811bc733be5c57a2bfecdf2f6f5d4db466200a upstream.
Timestamps in the trace data appear as all zeros on recent kernels,
although the feature works correctly on old kernels (e.g., v6.12).
Since commit c382ee674c8b ("arm64/sysreg/tools: Move TRFCR definitions
to sysreg"), the TRFCR_ELx_TS_{VIRTUAL|GUEST_PHYSICAL|PHYSICAL} macros
were updated to remove the bit shift. As a result, the driver no longer
shifts bits when operates the timestamp field.
Fix this by using the FIELD_PREP() and FIELD_GET() helpers.
Reported-by: Tamas Zsoldos <tamas.zsoldos@arm.com>
Fixes: c382ee674c8b ("arm64/sysreg/tools: Move TRFCR definitions to sysreg")
Signed-off-by: Leo Yan <leo.yan@arm.com>
Reviewed-by: James Clark <james.clark@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20250519174945.2245271-2-leo.yan@arm.com
Signed-off-by: PvsNarasimha <PVS.NarasimhaRao@amd.com>
4dc566f to
2ad7f78
Compare
Actually i did the test as the same above but still failed. The below is the result from my test machine. |
|
And could you tell us what's the update for the latest change? |
Hi, I ran the requested command on our validation system. The CPUID leaf 0x80000022 results are indeed different from the results you shared. Command: taskset -c 0 cpuid -1 -r -l 0x80000022 -s 0 Output from our system: CPU: Kernel Version: 6.6.122veniceibs Test System Details: Processor: AMD EPYC 9755 128-Core Processor (Turin) Compared to your system, the CPUID values for leaf 0x80000022 are different, which indicates that the reported IBS capabilities differ between the two platforms. Could you also please share the following information from your system? $ lscpu |
I found one minor conflict with the following patch:
I have resolved the conflict by rebasing the PR on the latest 6.6-velinux tip. The PR has now been updated with the latest changes. |
Please check below. Thanks! |
May i ask the CPUID leaf 0x80000022 results of Venice shoule be like what you provided? |
I performed the validation on a Venice system (Family 26, Model 80), which matches your platform. Test Environment The UMC performance event works correctly on our Venice system. root@venice-host:/home/amd/Narasimha/kernel/tools/perf# ./perf stat -a -e amd_umc_0/umc_mem_clk/ -- sleep 1 Performance counter stats for 'system wide': root@venice-host:/home/amd/Narasimha/kernel/tools/perf# uname -r For reference, the CPUID leaf 0x80000022 on our Venice system reports: root@venice-host:/home/amd/Narasimha/kernel/tools/perf# lscpu | egrep "Model name|CPU family|Model|Stepping" Despite these differences in the reported CPUID capabilities, the amd_umc_0/umc_mem_clk event works correctly on our Venice system with the PR kernel. |
root@xxxx:~# dmesg | grep amd_uncore |
Can you Please share me the .config file for your installed kernel ? Run below command ? |
root@xxx:~#grep AMD_UNCORE /boot/config-$(uname -r) |
|
Hi, Could you please share the following information from your system? It will be helpful for our further investigation. $ lscpu $ find /sys/bus/event_source/devices/ -name "amd_umc*" $ cpuid -1 | grep 80000022 $ dmesg | grep -i amd $ perf list | grep umc These details will help us compare the hardware capabilities and verify whether the UMC PMUs are being detected and initialized correctly on your platform. Thank you in advance! |
|
root@xxx: |
|
Thank you for the confirmation! I'm currently working on the fix. Once it is finalized, I'll submit it as a formal patch for your review. |
|
Could you also upstream this patch? We would like to upstream first. Thanks! |
f5f37d1 to
2ad7f78
Compare
|
Thanks for your work, this PR has merged. |
8 participants
Newly added and check-depend patches for resolving Build failures
perf top: Remove needless malloc(0) call that triggers -Walloc-size
perf tools: Fix calloc() arguments to address error introduced in gcc-14
tools arch amd ibs: Sync ibs.h with the kernel sources
tools/arch/x86: Move the <asm/amd-ibs.h> header to <asm/amd/ibs.h>
arm64: Convert SCTLR_EL2 to sysreg infrastructurex
arm64/sysreg/tools: Move TRFCR definitions to sysreg
KVM: arm64: Make EL2 exception entry and exit context-synchronization events
coresight: Pass guest TRFCR value to KVM
arm64/sysreg: Get rid of TRFCR_ELx SysregFields
coresight: etm4x: Fix timestamp bit field handling
Unit test Results:
Enable fetch latency filtering
$ ./perf record -e ibs_fetch/fetchlat=128/ -c 10000 -a -- sleep 5
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.817 MB perf.data ]
Enable RIP bit63 hardware filtering
$./perf record -e ibs_op//u -- ./stream_store_test
[ perf record: Woken up 3 times to write data ]
[ perf record: Captured and wrote 0.022 MB perf.data ]
Enable streaming store filter
$ ./perf record -e ibs_op/strmst=1/ -- ./stream_store_test
[ perf record: Woken up 3 times to write data ]
[ perf record: Captured and wrote 0.031 MB perf.data (2 samples) ]
perf/amd/ibs: Advertise remote socket capability.
$ ls /sys/bus/event_source/devices/ibs_op/caps
dtlb_pgsize ldlat rmtsocket strmst zen4_ibs_extensions