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

[Catalin Marinas <catalin.marinas@arm.com>]

Hi Kohei,

On Mon, May 18, 2026 at 10:38:53PM +0900, Kohei Enju wrote:
> On 05/18 13:33, Catalin Marinas wrote:
> > On Mon, May 18, 2026 at 12:31:31PM +0900, Kohei Enju wrote:
> > > diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> > > index 0c9ea24a200c..2d450caee3e4 100644
> > > --- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> > > +++ b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> > > @@ -108,7 +108,7 @@ static int arm_cca_report_new(struct tsm_report *report, void *data)
> > >  	 * allocate outblob based on the returned value from the 'init'
> > >  	 * call and that cannot be done in an atomic context.
> > >  	 */
> > > -	cpu = smp_processor_id();
> > > +	cpu = raw_smp_processor_id();
> > 
> > That's just hiding the warning which might be genuine, irrespective of
> > what the comment says. Sashiko has some good points:
> > 
> > https://sashiko.dev/#/patchset/20260518033157.1865498-1-enju.kohei@fujitsu.com
> > 
> > Basically what guarantees that the cpu won't go offline? Can we use
> > migrate_disable() and ignore the smp_call_function_single() altogether?
> > It looks like a hack anyway.
[...]
> You've raised a very valid point about raw_smp_processor_id()
> potentially hiding a genuine issue. I agree this would be a concern in
> most contexts.
> 
> However, this implementation was intentionally designed not to block CPU
> hotplug:
> https://lore.kernel.org/linux-arm-kernel/7a83461d-40fd-4e61-8833-5dae2abaf82b@arm.com/
> 
> As mentioned in the thread above, the potential failure from the target
> CPU going offline (resulting in -ENXIO) is an expected and tolerated
> condition in this path.
> Using migrate_disable() would go against the non-blocking design goal.
> 
> Given the context, the debug warning looks false positive for our
> specific use case to me, and I believe raw_smp_processor_id() correctly
> reflects the design intent by simply acquiring a CPU number without
> debug checks.

Thanks, I wasn't aware of the old discussion. If user-space can
tolerate, than it's fine.

Would you mind updating the comment above the changed line? It talks
about not allocating memory in atomic context, so migrate_disable()
would solve this. Just mention that it can't block CPU hotplug events
either and user-space can handle spurious errors.

With that:

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>