Re: [PATCH v11 19/23] x86/resctrl: Export interface to report telemetry unbind/remove

[Reinette Chatre <reinette.chatre@intel.com>]

Hi Tony,

On 9/16/26 9:26 AM, Luck, Tony wrote:
> On Wed, Sep 09, 2026 at 09:08:29PM -0700, Reinette Chatre wrote:
>> On 8/31/26 10:44 AM, Tony Luck wrote:
>>
>> ...
>>
>>> diff --git a/arch/x86/kernel/cpu/resctrl/intel_aet.c b/arch/x86/kernel/cpu/resctrl/intel_aet.c
>>> index c3bd3536c514..5cd2711d00e7 100644
>>> --- a/arch/x86/kernel/cpu/resctrl/intel_aet.c
>>> +++ b/arch/x86/kernel/cpu/resctrl/intel_aet.c
>>
>> ..
>>
>>> @@ -439,6 +462,8 @@ int intel_aet_read_event(int domid, u32 rmid, void *arch_priv, u64 *val)
>>>  	void *pevt0;
>>>  	u32 idx;
>>>  
>>> +	guard(mutex)(&aet_register_lock);
>>> +
>>
>> hmmm ... this means that reading an event can sleep now ... but it is still
>> possible to call this via IPI (smp_call_function_any()) if the CPU is part
>> of the nohz_full subset?
> 
> All AET events are implemented with counters in MMIO space and can be
> read from any CPU. So this check in mon_event_read() bypasses the
> check for nohz CPUs:
> 
> 	if (evt->any_cpu) {
> 		mon_event_count(rr);
> 		goto out_ctx_free;
> 	}

Thank you for the reminder.

> But even if it didn't, is there some prohibition for nohz CPUs to
> sleep? I can see possible issues with a timed delay that might rely on a
> clock tick to wake. But it would seem that any read(2) system call
> from a regular file might sleep waiting for I/O completion.

resctrl reads RMIDs that use MSR_IA32_QM_EVTSEL/MSR_IA32_QM_CTR by scheduling the
MSR reading work to run on a CPU that belongs to the domain via smp_call_on_cpu().
On a nohz CPU this scheduling may never complete since the nohz CPU just stays in
user space running its workload. The nohz CPU instead needs to be interrupted via
IPI using smp_call_function_any() and it is that work that is run via IPI that cannot
sleep.

Reinette