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

["Moger, Babu" <bmoger@amd.com>]

Hi Reinette,

On 9/14/2026 4:50 PM, Reinette Chatre wrote:
> Hi Babu,
> 
> On 9/14/26 2:30 PM, Reinette Chatre wrote:
>> On 9/14/26 10:17 AM, Babu Moger wrote:
>>> On 9/11/26 17:03, Reinette Chatre wrote:
>>>> On 9/4/26 11:06 AM, Babu Moger wrote:
>>
>> ...
>>
>>>>>
>>>>> 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.

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

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

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