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

[Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>]

On 2026-09-14 14:12:07+02:00, 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.
> 
> > --- 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 also agree that ~0 would be better.
> 
> Jan