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

[Sathyanarayanan Kuppuswamy]

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