Re: [PATCH v3] x86/resctrl: Fix miscount of bandwidth event when reactivating previously Unavailable RMID

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

Hi Reinette,

On 10/9/2025 11:19 PM, Reinette Chatre wrote:
> Hi Babu,
> 
> On 10/9/25 11:29 AM, Babu Moger wrote:
>> Users can create as many monitoring groups as the number of RMIDs supported
>> by the hardware. However, on AMD systems, only a limited number of RMIDs
>> are guaranteed to be actively tracked by the hardware. RMIDs that exceed
>> this limit are placed in an "Unavailable" state. When a bandwidth counter
>> is read for such an RMID, the hardware sets MSR_IA32_QM_CTR.Unavailable
>> (bit 62). When such an RMID starts being tracked again the hardware counter
>> is reset to zero. MSR_IA32_QM_CTR.Unavailable remains set on first read
>> after tracking re-starts and is clear on all subsequent reads as long as
>> the RMID is tracked.
>>
>> resctrl miscounts the bandwidth events after an RMID transitions from the
>> "Unavailable" state back to being tracked. This happens because when the
>> hardware starts counting again after resetting the counter to zero, resctrl
>> in turn compares the new count against the counter value stored from the
>> previous time the RMID was tracked. This results in resctrl computing an
>> event value that is either undercounting (when new counter is more than
>> stored counter)	or a mistaken overflow (when new counter is less than
> 
> Since there is going to be a respin ... there is a stray tab above.
> 

Yes. Thanks
-Babu