Re: [PATCH] accel/mshv: mitigate early boot vcpu exit race

[Magnus Kulke <magnuskulke@linux.microsoft.com>]

On Thu, Jun 25, 2026 at 03:15:16PM +0200, Paolo Bonzini wrote:
> 
> These two should not be needed.  The sequence of events is:
> 
> - exit from here
> 
> - "while (!cpu->unplug || cpu_can_run(cpu))" is still true
> 
> - qemu_process_cpu_events() runs:
>   - set exit_request == false
>   - cpu_thread_is_idle(cpu) is false due to cpu->stop == true
>   - qemu_process_cpu_events_common() runs:
>     - sets cpu->thread_kicked == false
>     - qemu_cpu_stop() sets cpu->stopped == true
> 
> - cpu_can_run(cpu) is now false, so mshv_cpu_exec() does not run
> 
> - ... but !cpu->unplug is true -> another run around the loop
> 
> - now cpu_thread_is_idle(cpu) is true, so the thread goes to sleep.
> 
> > +            ret = EXCP_INTERRUPT;
> > +            break;
> > +        }
> 
> 
> Also, for cleanliness I'd put the lines after the "if (cpu->accel->dirty)"
> immediately below.
> 
> 
> > +/*
> > + * mshv-custom kick implementation:
> > + *
> > + * We set cpu->exit_request before the SIG_IPI is delivered to the vcpu
> > + * thread (as part of cpus_kick_thread()). It is consumed in the
> > + * mshv_cpu_exec loop.
> > + */
> > +static void mshv_kick_vcpu_thread(CPUState *cpu)
> > +{
> > +    qatomic_set_mb(&cpu->exit_request, true);
> > +    cpus_kick_thread(cpu);
> > +}
> > +
> 
> This should not be necessary, either.  In recent versions of QEMU,
> cpu->exit_request is set appropriately by cpu_exit(); see commits
> ac6c8a390b4 and f8217ae54e4 and nearby.
> 
> Accelerators can write cpu->exit_request, but only within the accelerator
> thread if they want to kick themselves out of cpu_exec(). For example, KVM
> does this to run kvm_arch_process_async_events(); but MSHV does not have
> anything similar.
> 
> Paolo

I see, we indeed just need to honor cpu->exit_request in the loop and
break out if it is set, this only seems to be address the issue that the
patch was attempting to fix. Since we also need to it for the migration
case, I submit a revised patch as part of a migration series, so we can
abandon this one.

thanks!

magnus