On Mon, 24 Sep 2012 09:16:12 +0200 Gleb Natapov <gleb@xxxxxxxxxx> wrote: > Yes, for guests that do not enable steal time KVM_REQ_STEAL_UPDATE > should be never set, but currently it is. The patch (not tested) should > fix this. Thinking a bit more about KVM_REQ_STEAL_UPDATE... > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 901ad00..01572f5 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -1544,6 +1544,8 @@ static void accumulate_steal_time(struct kvm_vcpu *vcpu) > delta = current->sched_info.run_delay - vcpu->arch.st.last_steal; > vcpu->arch.st.last_steal = current->sched_info.run_delay; > vcpu->arch.st.accum_steal = delta; > + > + kvm_make_request(KVM_REQ_STEAL_UPDATE, vcpu); > } Even without this flag, we know when we should record the steal time: that's when vcpu->arch.st.accum_steal != 0. > > static void record_steal_time(struct kvm_vcpu *vcpu) So we can live without KVM_REQ_STEAL_UPDATE and make record_steal_time() do the job when vcpu->arch.st.accum_steal != 0 so that it can be called unconditionally in vcpu_enter_guest(). Why didn't we do that? The only reason I can think of is we wanted to eliminate that check for the zero-requests case. But does such a micro-optimization really help us? Thanks, Takuya -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
