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.

Signed-off-by: Huang Shijie <huangsj@hygon.cn>
---
 arch/x86/events/amd/ibs.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/x86/events/amd/ibs.c b/arch/x86/events/amd/ibs.c
index 3531f9c23b8c..e5376ad5b2ec 100644
--- a/arch/x86/events/amd/ibs.c
+++ b/arch/x86/events/amd/ibs.c
@@ -1318,11 +1318,31 @@ static void perf_ibs_parse_ld_st_data(__u64 sample_type,
 	}
 }
 
+static void perf_ibs_parse_fetch_data(__u64 sample_type,
+				      struct perf_ibs_data *ibs_data,
+				      struct perf_sample_data *data)
+{
+	union ibs_fetch_ctl fetch_ctl;
+
+	if (!(sample_type & PERF_SAMPLE_PHYS_ADDR))
+		return;
+
+	fetch_ctl.val = ibs_data->regs[ibs_fetch_msr_idx(MSR_AMD64_IBSFETCHCTL)];
+	if (!fetch_ctl.phy_addr_valid)
+		return;
+
+	data->phys_addr = ibs_data->regs[ibs_fetch_msr_idx(MSR_AMD64_IBSFETCHPHYSAD)];
+	data->sample_flags |= PERF_SAMPLE_PHYS_ADDR;
+}
+
 static bool perf_ibs_is_mem_sample_type(struct perf_ibs *perf_ibs,
 					struct perf_event *event)
 {
 	u64 sample_type = event->attr.sample_type;
 
+	if (perf_ibs == &perf_ibs_fetch)
+		return sample_type & PERF_SAMPLE_PHYS_ADDR;
+
 	return perf_ibs == &perf_ibs_op &&
 	       sample_type & (PERF_SAMPLE_DATA_SRC |
 			      PERF_SAMPLE_WEIGHT_TYPE |
@@ -1555,6 +1575,8 @@ static int perf_ibs_handle_irq(struct perf_ibs *perf_ibs, struct pt_regs *iregs)
 
 	if (perf_ibs == &perf_ibs_op)
 		perf_ibs_parse_ld_st_data(event->attr.sample_type, &ibs_data, &data);
+	else
+		perf_ibs_parse_fetch_data(event->attr.sample_type, &ibs_data, &data);
 
 	/*
 	 * rip recorded by IbsOpRip will not be consistent with rsp and rbp
-- 
2.53.0

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>

Thanks,
Ravi

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?

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.

Thanks,
Ravi

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.

On Tue, Aug 18, 2026 at 11:19:13AM +0200, Peter Zijlstra wrote:
> > >>
> > >> 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.

I just use this patch to track a program's memory footprint, including
the front-end(Fetch samples) and back-end(Op samples) in NUMA server.

So I also think there is no need to add a PERF_SAMPLE_IP_PHYS_ADDR for this.

Thanks
Huang Shijie


> 
> 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.
>

On Tue, Aug 18, 2026 at 07:04:31PM +0800, Huang Shijie wrote:
> On Tue, Aug 18, 2026 at 11:19:13AM +0200, Peter Zijlstra wrote:
> > > >>
> > > >> 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.
> 
> I just use this patch to track a program's memory footprint, including
> the front-end(Fetch samples) and back-end(Op samples) in NUMA server.
> 
> So I also think there is no need to add a PERF_SAMPLE_IP_PHYS_ADDR for this.

Ah, so I think me asking about the use of PHYS_ADDR previously, resulted
in the two PAGE_SIZE numbers. I suppose what you're looking for is
PAGE_NODE.

The trouble with physical addresses is that it is very hard for
userspace to do anything useful with them. At least the node mapping is
somewhat doable I suppose.

On Tue, Aug 18, 2026 at 01:30:48PM +0200, Peter Zijlstra wrote:
> On Tue, Aug 18, 2026 at 07:04:31PM +0800, Huang Shijie wrote:
> > On Tue, Aug 18, 2026 at 11:19:13AM +0200, Peter Zijlstra wrote:
> > > > >>
> > > > >> 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.
> > 
> > I just use this patch to track a program's memory footprint, including
> > the front-end(Fetch samples) and back-end(Op samples) in NUMA server.
> > 
> > So I also think there is no need to add a PERF_SAMPLE_IP_PHYS_ADDR for this.
> 
> Ah, so I think me asking about the use of PHYS_ADDR previously, resulted
> in the two PAGE_SIZE numbers. I suppose what you're looking for is
> PAGE_NODE.
> 
> The trouble with physical addresses is that it is very hard for
> userspace to do anything useful with them. At least the node mapping is
It is not trouble for us. :)

1.) We can get the physical address ranges in NUMA by parsing the "/sys/devices/system/memeory".
2.) With IBS samples, we can get the physical memory access records.

With 1 & 2, we can draw a detail picture for the memory footprint.
And we can use the result to improve the performance in NUMA.

Thanks
Huang Shijie

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@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.

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