|
[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");
> }
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |