Re: [PATCH v2 28/39] xen/riscv: handle the case when no vCPU migration is needed

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.09.2026 07:55, Oleksii Kurochko wrote:
> On 9/14/26 2:12 PM, Jan Beulich wrote:
>> On 27.08.2026 17:21, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/imsic.c
>>> +++ b/xen/arch/riscv/imsic.c
>>> @@ -689,5 +689,15 @@ int __init vimsic_make_domu_dt_node(struct kernel_info 
>>> *kinfo,
>>>   
>>>   void imsic_migrate_vcpu(struct vcpu *v)
>>>   {
>>> +    /*
>>> +     * The scheduler can mark a freshly created vCPU's unit as migrated and
>>> +     * invoke this before the vCPU has ever run (see the migrated branch in
>>> +     * schedule()). No need to do migration for such vCPUs as they aren't 
>>> fully
>>> +     * initialized (for example, context_switch() will be called after
>>> +     * imsic_migrate_vcpu()).
>>> +     */
>>> +    if ( v->arch.last_cpu == NR_CPUS )
>>
>> May I suggest to use >= ? I'm still somewhat unconvinced of NR_CPUS being a
>> good sentinel. If we/you decided to switch to ~0, >= here would continue to
>> be correct.
> 
> I agree with >= but I am not quite sure that I fully understand what is 
> wrong with NR_CPUS. We have for example the following:
> 
> static inline unsigned int smp_processor_id(void)
> {
>      unsigned int id = tp->processor_id;
> 
>      BUG_ON(id >= NR_CPUS);
> 
>      return id;
> }
> 
> So it is guaranteed that NR_CPUS what be used as cpu id and so it still 
> could be considered as a good sentinel.

Arbitrary numbers can be problematic when used as a sentinel. If you look
at disassembly, you may not recognize that number as a sentinel. Further
there's also a code-gen concern: ~0, aiui, will always generate the same
code (to e.g. load into a register). NR_CPUS, depending on .config, may
not. The value may not be loadable by a single insn.

Jan