Re: [PATCH] KVM: X86: set vcpu preempted only if it is preempted

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

 



On Wed, Jan 12, 2022, Peter Zijlstra wrote:
> On Wed, Jan 12, 2022 at 08:02:01PM +0800, Li RongQing wrote:
> > vcpu can schedule out when run halt instruction, and set itself
> > to INTERRUPTIBLE and switch to idle thread, vcpu should not be
> > set preempted for this condition
> 
> Uhhmm, why not? Who says the vcpu will run the moment it becomes
> runnable again? Another task could be woken up meanwhile occupying the
> real cpu.

Hrm, but when emulating HLT, e.g. for an idling vCPU, KVM will voluntarily schedule
out the vCPU and mark it as preempted from the guest's perspective.  The vast majority,
probably all, usage of steal_time.preempted expects it to truly mean "preempted" as
opposed to "not running".

The lack of a vcpu->preempted check has confused me for a long time.  I assumed
that was intended behavior, but looking at the original commit, I'm not so sure.
The changelog is somewhat contradictory, as the the last sentence says "is running
or not", but I suspect that's just imprecise language.

 commit 0b9f6c4615c993d2b552e0d2bd1ade49b56e5beb
 Author: Pan Xinhui <xinhui.pan@xxxxxxxxxxxxxxxxxx>
 Date:   Wed Nov 2 05:08:35 2016 -0400

    x86/kvm: Support the vCPU preemption check

    Support the vcpu_is_preempted() functionality under KVM. This will
    enhance lock performance on overcommitted hosts (more runnable vCPUs
    than physical CPUs in the system) as doing busy waits for preempted
    vCPUs will hurt system performance far worse than early yielding.

    Use struct kvm_steal_time::preempted to indicate that if a vCPU
    is running or not.

vcpu->preempted will be set if KVM schedules out the vCPU to service _TIF_NEED_RESCHED,
but not in the HLT case because KVM will mark the vCPU as TASK_INTERRUPTIBLE.  The
flag also won't be set if KVM puts the vCPU when exiting to userspace to handle I/O
or whatever, which is also desirable from the guest's perspective.

There might be potential for false negatives, but any damage there is likely
far outweighed by getting false positives, especially in the HLT case.

So somewhat tentatively...

Reviewed-by: Sean Christopherson <seanjc@xxxxxxxxxx>

> > Signed-off-by: Li RongQing <lirongqing@xxxxxxxxx>
> > Signed-off-by: Wang GuangJu <wangguangju@xxxxxxxxx>
> > ---
> >  arch/x86/kvm/x86.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 9f5dbf7..10d76bf 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -4407,6 +4407,9 @@ static void kvm_steal_time_set_preempted(struct kvm_vcpu *vcpu)
> >  	if (vcpu->arch.st.preempted)
> >  		return;
> >  
> > +	if (!vcpu->preempted)
> > +		return;
> > +
> >  	/* This happens on process exit */
> >  	if (unlikely(current->mm != vcpu->kvm->mm))
> >  		return;
> > -- 
> > 2.9.4
> > 



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux