From: Ravi Bangoria <ravi.bangoria@amd.com>
To: <sashiko@lists.linux.dev>, <linux-perf-users@vger.kernel.org>
Subject: Re: [PATCH v3 4/8] perf amd ibs: Suppress bogus TlbRefillLat and DCPhysAd on Zen4+
Date: Tue, 12 May 2026 14:19:04 +0530 [thread overview]
Message-ID: <6e7b96a8-f053-4f2c-b15e-0e798a3514cf@amd.com> (raw)
In-Reply-To: <20260508182027.F2DF1C2BCC7@smtp.kernel.org>
>> @@ -253,8 +260,12 @@ static void amd_dump_ibs_op(struct perf_sample *sample)
>> pr_ibs_op_data3(*op_data3);
>> if (op_data3->dc_lin_addr_valid)
>> printf("IbsDCLinAd:\t%016llx\n", *(rip + 4));
>> - if (op_data3->dc_phy_addr_valid)
>> +
>> + /* Use !zen4_ibs_extensions as a proxy for Zen3 and earlier */
>> + if (op_data3->dc_phy_addr_valid && *(rip + 5) &&
>> + (!zen4_ibs_extensions || op_data3->dc_lin_addr_valid)) {
>> printf("IbsDCPhysAd:\t%016llx\n", *(rip + 5));
>> + }
>
> Does checking *(rip + 5) here suppress valid memory accesses to physical
> address 0x0?
>
> While this successfully hides kernel-zeroed addresses for unprivileged users,
> it seems like it cannot distinguish between software-zeroed values and actual
> 0x0 addresses. Could this silently discard valid diagnostic data during
> privileged profiling sessions if an actual hardware access to physical page 0
> occurs?
This doesn't seem like a genuine concern. The first physical page is reserved
on x86 systems, so normal workload should never access it.
$ head -1 /proc/iomem
00000000-00000fff : Reserved
Thanks,
Ravi
next prev parent reply other threads:[~2026-05-12 8:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-08 5:59 [PATCH v3 0/8] perf tools amd ibs: Fixes + Zen6 enhancements Ravi Bangoria
2026-05-08 5:59 ` [PATCH v3 1/8] perf test amd ibs: Fix incorrect kernel version check Ravi Bangoria
2026-05-08 5:59 ` [PATCH v3 2/8] perf tool ibs: Sync AMD IBS header file Ravi Bangoria
2026-05-08 5:59 ` [PATCH v3 3/8] perf test ibs: Skip privilege test on Zen6 and newer platforms Ravi Bangoria
2026-05-08 6:00 ` [PATCH v3 4/8] perf amd ibs: Suppress bogus TlbRefillLat and DCPhysAd on Zen4+ Ravi Bangoria
2026-05-08 18:20 ` sashiko-bot
2026-05-12 8:49 ` Ravi Bangoria [this message]
2026-05-08 6:00 ` [PATCH v3 5/8] perf amd ibs: Make Fetch status bits dependent on PhyAddrValid for newer platforms Ravi Bangoria
2026-05-08 6:00 ` [PATCH v3 6/8] perf amd ibs: Decode Remote-Socket flag in IBS OP raw dump Ravi Bangoria
2026-05-08 6:00 ` [PATCH v3 7/8] perf amd ibs: Decode Streaming-store " Ravi Bangoria
2026-05-08 6:00 ` [PATCH v3 8/8] perf doc: Document new IBS capabilities in man page Ravi Bangoria
2026-05-10 6:41 ` [PATCH v3 0/8] perf tools amd ibs: Fixes + Zen6 enhancements Namhyung Kim
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=6e7b96a8-f053-4f2c-b15e-0e798a3514cf@amd.com \
--to=ravi.bangoria@amd.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox