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

[Ravi Bangoria]

On 18-Aug-26 2:49 PM, Peter Zijlstra wrote:
> 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@xxxxxxx>
>>>
>>> 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.

I don't have a compelling use case either.

fwiw, IBS PMUs already dump this metadata (including the physical address)
through PERF_SAMPLE_RAW, so this information isn't completely unavailable
to userspace today.

Thanks,
Ravi