[PATCH v2] virt: arm-cca-guest: use raw variant of smp_processor_id() in arm_cca_report_new()

[Will Deacon]

On Tue, Jun 02, 2026 at 04:48:43PM +0100, Suzuki K Poulose wrote:
> On 02/06/2026 12:01, Will Deacon wrote:
> > On Tue, May 19, 2026 at 07:12:08PM +0900, Kohei Enju wrote:
> > > With CONFIG_DEBUG_PREEMPT=y, smp_processor_id() becomes an alias of
> > > debug_smp_processor_id(). This debug function complains when certain
> > > conditions that ensure CPU ID stability are not met, specifically when
> > > it's called from a preemptible context.
> > > 
> > > In arm_cca_report_new(), which runs in a preemptible context,
> > > smp_processor_id() triggers a splat [0] due to this.
> > > 
> > > However, the CPU ID obtained here is used as the target CPU for
> > > smp_call_function_single() to designate a specific CPU for subsequent
> > > operations, not to assert that the current thread will continue to
> > > execute on the same CPU. Therefore, snapshotting the CPU ID itself is
> > > correct, and thus there's no actual harm except for the splat.
> > > 
> > > Use raw_smp_processor_id() instead, to directly retrieve the current CPU
> > > ID without the debug checks, avoiding the unnecessary warning message
> > > while preserving the correct functional behavior.
> > 
> > That's pretty disgusting imo so I'd like to see some more justification
> > for this approach.
> > 
> > > Note that while migrate_disable() would pin the task to the current CPU,
> > > this path should not block CPU hotplug events. Therefore, we snapshot
> > > the current CPU ID and accept that smp_call_function_single() may fail
> > > if the CPU goes offline.
> > 
> > Why shouldn't it block CPU hotplug events? What happens if the CPU goes
> > offline and comes back online again during the loop of continue calls?
> 
> It need not. It can continue the calls. The RMM keeps track of the internal
> progress in the "REC" object for this "VCPU". Hotplug ON/OFF
> doesn't change the REC object in CCA Guest. So, a REC can come back and
> execute it. But the Linux could fail the operation if the CPU isn't
> available for fetching the report, after we do a RSI_ATTEST_TOKEN_INIT.

I couldn't really shake that out of the RMM spec tbh:
RSI_ATTESTATION_TOKEN_CONTINUE is allowed to return RSI_ERROR_UNKNOWN
and I couldn't find anything about hotplug.

But my main point, really, is why are we not using migrate_disable()
here? I can't see the justification.

Will