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

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 9/14/26 2:12 PM, Jan Beulich wrote:
> On 27.08.2026 17:21, Oleksii Kurochko wrote:
> > The IMSIC vsfile mapping is performed in continue_new_vcpu(), since the
> > target pCPU must be known at that point. It is therefore possible for
> > imsic_migrate_vcpu() to be called before continue_new_vcpu() has
> > executed, in which case v->arch.last_pcpu is NR_CPUS and there is nothing
> > to migrate.
> >
> > Add a BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard
> > against silent incorrect behaviour or unexpected panics in guest VMs until
> > the function is fully implemented.
> This doesn't adequately describe the change made: The BUG_ON() was already
> there.
Agree, it should be just:

Keep the BUG_ON() at the end of the function until imsic_migrate_vcpu() 
is fully implemented, to avoid ending up with a vCPU which isn't fully 
migrated to the new IMSIC interrupt file.
> > --- 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.
Thanks.

~ Oleksii