Linux Perf Users
 help / color / mirror / Atom feed
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

  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