Re: [RFC PATCH] perf/amd/ibs: Report physical address for IBS fetch samples

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Aug 18, 2026 at 02:34:26PM +0530, Ravi Bangoria wrote:
> On 18-Aug-26 1:30 PM, Peter Zijlstra wrote:
> > On Tue, Aug 18, 2026 at 10:29:08AM +0530, Ravi Bangoria wrote:
> >> On 17-Aug-26 1:03 PM, Huang Shijie wrote:
> >>> The IBS Fetch sampling does not report the physical address of the
> >>> fetched instruction even when PERF_SAMPLE_PHYS_ADDR is requested,
> >>> while IBS Op sampling does.
> >>>
> >>> This patch reports physical address for IBS fetch samples which can be
> >>> used for profiling the running program.
> >>
> >> PERF_SAMPLE_PHYS_ADDR is meant to capture the _data_ physical address, which
> >> IBS Fetch doesn't provide. So, repurposing semantics of PERF_SAMPLE_PHYS_ADDR
> >> for IBS Fetch seems reasonable.
> >>
> >> Reviewed-by: Ravi Bangoria <ravi.bangoria@amd.com>
> > 
> > Well, why confuse things?
> > 
> > As you say, PHYS_ADDR is for ADDR, which is the *data* address, and
> > FETCH is an instruction address, which we find in IP, not DATA.
> > 
> > What would be the purpose of confusing things and making PHYS_ADDR
> > relate to IP?
> 
> Agreed, that would create confusion.
> 
> Do you think we should introduce a new type PERF_SAMPLE_IP_PHYS_ADDR?
> I didn't suggest it earlier because I thought it would be overkill.

Well, that all depends on how useful this data is. As is, I see very
little words on the benefit of having this data.

In fact, I'm not really sure what PHYS_ADDR is good for, so clearly I'm
missing a bit to begin with.

That is; if there is a very convincing argument to actually have this
data, that might help justifying either accepting this 'hack' or perhaps
introducing more fields.