[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

Jan

> +        return;
> +
>      BUG_ON("unimplemented");
>  }




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.