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

[Will Deacon]

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?

Will