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

[Suzuki K Poulose]

On 09/06/2026 14:16, Kohei Enju wrote:
> On 06/03 12:48, Will Deacon wrote:
>> 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.

Like I said, we are dealing with Virtual CPUs (RECs here) and the only 
condition that the RMM enforces is the _CONTINUE calls are issued on the
same VCPU (REC). Hotplug doesn't change the REC (as a REC cannot be
modified or added once the Realm is ACTIVE).

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

There is no reason, why we couldn't use this. TBH, I wasn't aware of the
helper ;-) at the time this was initially designed and we didn't want to
block CPU hotplug. We could always request a new report, it is not like
aborting a report generation has any side effects.

> 
> Hi Will,
> Sorry for the late reply.
> 
> I agree that using migrate_disable() makes this path simpler and
> clearer.
> 
> I've reviewed the discussion where the original commit was introduced:
>      https://lore.kernel.org/linux-arm-kernel/7a83461d-40fd-4e61-8833-5dae2abaf82b@arm.com/
> but I couldn't find a strong reason why we shouldn't block CPU hotplug
> or use migrate_disable(), even though I can see the current design was
> intentional.
> 
> So I'm happy to rework the patch to use migrate_disable() and remove
> the smp_call_function_single() calls if there are no objections.

I am fine with removing with migrate_disable() approach.

Cheers
Suzuki

> 
>>
>> Will
>>