Re: [PATCH] KVM: Drop kvm_vcpu.ready to squash race where "ready" can get stuck "true"

[Sean Christopherson <seanjc@google.com>]

On Tue, Apr 14, 2026, zhanghao wrote:
> On Thu, Apr 09, 2026, Sean Christopherson wrote:
> > Drop kvm_vcpu.ready and instead detect the case where a recently awakened
> > vCPU is runnable but not yet scheduled in by explicitly, manually checking
> > for a target vCPU that is (a) scheduled out, (b) wants to run, (c) is
> > marked as blocking in its stat, but (d) not actually flagged as blocking.
> > I.e. treat a runnable vCPU that's in the blocking sequence but not truly
> > blocking as a candidate for directed yield.
> > 
> > Keying off vcpu->stat.generic.blocking will yield some number of false
> > positives, e.g. if the vCPU is preempted _before_ blocking, but the rate of
> > false positives should be roughly the same as the existing approach, as
> > kvm_sched_out() would previously mark the vCPU as ready when it's scheduled
> > out and runnable.
> > 
> > Eliminating the write to vcpu->ready in kvm_vcpu_wake_up() fixes a race
> > where vcpu->ready could be set *after* the target vCPU is scheduled in,
> > e.g. if the task waking the target vCPU is preempted (or otherwise delayed)
> > after waking the vCPU, but before setting vcpu->ready.  Hitting the race
> > leads to a very degraded state as KVM will constantly attempt to schedule
> > in a vCPU that is already running.

...

> kvm_vcpu.ready still exists in struct kvm_vcpu, but there are no remaining 
> users after this patch, so it looks like a leftover cleanup item.

Gah, I intended to remove kvm_vcpu.ready, not sure how I didn't.  Thanks!