Re: [PATCH v2 1/3] x86/resctrl: Fix ABMC counter programming for extended counter ranges

Hi Reinette,

On 9/14/2026 4:50 PM, Reinette Chatre wrote:

Hi Babu,

On 9/14/26 2:30 PM, Reinette Chatre wrote:

quoted

On 9/14/26 10:17 AM, Babu Moger wrote:

quoted

On 9/11/26 17:03, Reinette Chatre wrote:

quoted

On 9/4/26 11:06 AM, Babu Moger wrote:

...

quoted

quoted

quoted

Fix the issues with the following changes:

1. Update the cntr_id field handling to support the full hardware ABMC
counter range and ensure that counter programming does not interfere with
unrelated counters.

Sashiko's assessment that this statement is not accurate looks correct to me.

Looks like the enumeration needs a check to limit the number of supported
counters if the hardware supports more than what can be configured? It seems
awkward that such hardware could exist and unclear why the spec has a mismatch in

You're right. The spec overlooked this scenario. I've notified the concerned team.


Do you want me add this check?

-               r->mon.num_mbm_cntrs = (ebx & GENMASK(15, 0)) + 1;
+               r->mon.num_mbm_cntrs = (ebx & GENMASK(12, 0)) + 1;

Yes please.

Sure.

quoted

quoted

quoted

the number of bits here. Even if cntr_id expands further to use the remaining
reserved bits it would still not be sufficient to configure all the numbers
that hardware may claim to support. Are there perhaps more field width changes
in this upcoming spec update?

Two fields(ctrl_id and bw_src) in here are changing for this register. I dont know about other changes yet.

quoted

quoted

2. Expand the bw_src field to 15 bits.

Do the comments describing the RMID field width when reading the monitoring
data (__cntr_id_read() and __rmid_read_phys()) need an update also?

The RMID field width is expected to change. We can revisit this when that happens.

This patch is that change, no? bw_src is expanded to 15 bits, and bw_src contains
the RMID.

This is the new RMID field width for monitoring configuration, after configuration
the counter needs to be read for the monitoring data via MSR_IA32_QM_EVTSEL and per
__cntr_id_read() the RMID field is still restricted (although not enforce by resctrl)
to 12 bits:

	* 43:32   RMID            RMID or counter ID in ABMC mode

That is correct.

quoted

resctrl also supports switching between "default" and "mbm_event" mode and there
is no support for the number of RMIDs changing between the modes ... this reading
an event in "default" mode should support the same number of RMIDs as
"mbm_event" mode and we see in __rmid_read_phys() (although, again not enforced)
that it supports even fewer bits for RMID
	
	IA32_QM_EVTSEL.RMID (bits 41:32) are configured with valid RMID

Yes.

quoted

Looks like after this patch there are quite a few different field widths for RMID
between what is documented, used directly, and actually enforced.

To add to this it looks like PLZA currently supports 12 bit RMIDs per

	https://lore.kernel.org/lkml/702b88901bc62f07829144a96cc887471b427da8.1787772750.git.babu.moger@amd.com/ (local)

I assume this field will also be updated to 15 bits?

Yes, I have already raised this with the appropriate team, and it is 
expected to be addressed.

The original issue arose when programming a Counter ID wider than 5 
bits. To address that issue, the Counter ID width needs to be increased 
to 12 bits.

Currently, the RMID width is 12 bits, and there is no hardware that 
supports a width greater than 12 bits.

How about we address the Counter ID issue for now and revisit the RMID 
width when the specification changes?

Would that work?

Thanks
Babu