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

[Kohei Enju]

On 05/18 18:21, Catalin Marinas wrote:
> 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.

Sure, I'm happy to do. Thank you for the suggestion.
I'll work on v2.

Thanks,
Kohei

> 
> With that:
> 
> Reviewed-by: Catalin Marinas <catalin.marinas at arm.com>
>