Re: [PATCH v1 1/2] powercap: intel_rapl: Prepare read_raw interface for atomic-context callers

[Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@linux.intel.com>]

On 2/13/26 10:37 PM, Raag Jadav wrote:
> On Thu, Nov 20, 2025 at 04:05:38PM -0800, Kuppuswamy Sathyanarayanan wrote:
>> The current read_raw() implementation of the TPMI, MMIO and MSR
>> interfaces does not distinguish between atomic and non-atomic callers.
>>
>> rapl_msr_read_raw() uses rdmsrq_safe_on_cpu(), which can sleep and
>> issue cross CPU calls. When MSR-based RAPL PMU support is enabled, PMU
>> event handlers can invoke this function from atomic context where
>> sleeping or rescheduling is not allowed. In atomic context, the caller
>> is already executing on the target CPU, so a direct rdmsrq() is
>> sufficient.
>>
>> To support such usage, introduce an atomic flag to the read_raw()
>> interface to allow callers pass the context information. Modify the
>> common RAPL code to propagate this flag, and set the flag to reflect
>> the calling contexts.
>>
>> Utilize the atomic flag in rapl_msr_read_raw() to perform direct MSR
>> read with rdmsrq() when running in atomic context, and a sanity check
>> to ensure target CPU matches the current CPU for such use cases.
>>
>> The TPMI and MMIO implementations do not require special atomic
>> handling, so the flag is ignored in those paths.
>>
>> This is a preparatory patch for adding MSR-based RAPL PMU support.
> ...
>
>> -static int rapl_msr_read_raw(int cpu, struct reg_action *ra)
>> +static int rapl_msr_read_raw(int cpu, struct reg_action *ra, bool atomic)
>>   {
>> +	/*
>> +	 * When called from atomic-context (eg PMU event handler)
>> +	 * perform MSR read directly using rdmsrq().
>> +	 */
>> +	if (atomic) {
>> +		if (unlikely(smp_processor_id() != cpu))
>> +			return -EIO;
> This series breaks[1] our application[2] in cases where the reads are
> issued from any available CPU it is scheduled on. This issue is not seen on
> older platforms which use the original arch/x86 RAPL implementation.
>
> Can someone please shed some light on the change of userspace expectations?
> Or did I miss any points in the documentation?
>
> [1] https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6935
> [2] https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/lib/igt_power.c

The access with non-lead CPUs is fixed by following series:

https://lore.kernel.org/linux-pm/CAJZ5v0gh_3y4+2qepC5Mqos+y+kBfGgeEKdmL5s6J4MBGcrQzw@mail.gmail.com/T/#mabe68b0d5c3e5571c9333ff915d38562ec7fed71

Can you please re-test with this above series?


> Raag
>
>> +		rdmsrq(ra->reg.msr, ra->value);
>> +		goto out;
>> +	}
>> +
>>   	if (rdmsrq_safe_on_cpu(cpu, ra->reg.msr, &ra->value)) {
>>   		pr_debug("failed to read msr 0x%x on cpu %d\n", ra->reg.msr, cpu);
>>   		return -EIO;
>>   	}
>> +
>> +out:
>>   	ra->value &= ra->mask;
>>   	return 0;
>>   }

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer