From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751701AbdF1MKS (ORCPT ); Wed, 28 Jun 2017 08:10:18 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33775 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751501AbdF1MKJ (ORCPT ); Wed, 28 Jun 2017 08:10:09 -0400 Subject: Re: [PATCH v3] KVM: LAPIC: Fix lapic timer injection delay To: Wanpeng Li , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Wanpeng Li References: <1498613352-4651-1-git-send-email-wanpeng.li@hotmail.com> From: Paolo Bonzini Message-ID: <68c0d7f8-683f-c7fa-b328-e90e8dd9a789@redhat.com> Date: Wed, 28 Jun 2017 14:10:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <1498613352-4651-1-git-send-email-wanpeng.li@hotmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28/06/2017 03:29, Wanpeng Li wrote: > u64 tscdeadline = apic->lapic_timer.tscdeadline; > + int ret = 0; > > if ((atomic_read(&apic->lapic_timer.pending) && > !apic_lvtt_period(apic)) || > - kvm_x86_ops->set_hv_timer(apic->vcpu, tscdeadline)) { > + (ret = kvm_x86_ops->set_hv_timer(apic->vcpu, tscdeadline))) { > if (apic->lapic_timer.hv_timer_in_use) > cancel_hv_timer(apic); > + if (ret == 1) { > + apic_timer_expired(apic); > + return true; > + } The preemption timer can also be used for modes other than TSC deadline. In periodic mode, your patch would miss a call to advance_periodic_target_expiration, which is only called by kvm_lapic_expired_hv_timer. You could use something like this: diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index d24c8742d9b0..15b751aa7625 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -1504,21 +1504,26 @@ static void cancel_hv_timer(struct kvm_lapic *apic) static bool start_hv_timer(struct kvm_lapic *apic) { u64 tscdeadline = apic->lapic_timer.tscdeadline; + bool need_cancel = apic->lapic_timer.hv_timer_in_use; + if (!atomic_read(&apic->lapic_timer.pending) || apic_lvtt_period(apic)) { + int r = kvm_x86_ops->set_hv_timer(apic->vcpu, tscdeadline); + if (r >= 0) { + need_cancel = false; + apic->lapic_timer.hv_timer_in_use = true; + hrtimer_cancel(&apic->lapic_timer.timer); - if ((atomic_read(&apic->lapic_timer.pending) && - !apic_lvtt_period(apic)) || - kvm_x86_ops->set_hv_timer(apic->vcpu, tscdeadline)) { - if (apic->lapic_timer.hv_timer_in_use) - cancel_hv_timer(apic); - } else { - apic->lapic_timer.hv_timer_in_use = true; - hrtimer_cancel(&apic->lapic_timer.timer); - - /* In case the sw timer triggered in the window */ - if (atomic_read(&apic->lapic_timer.pending) && - !apic_lvtt_period(apic)) - cancel_hv_timer(apic); + /* In case the sw timer triggered in the window */ + if (atomic_read(&apic->lapic_timer.pending) && + !apic_lvtt_period(apic)) + need_cancel = true; + else if (r) + kvm_lapic_expired_hv_timer(vcpu); + } } + + if (need_cancel) + cancel_hv_timer(apic); + trace_kvm_hv_timer_state(apic->vcpu->vcpu_id, apic->lapic_timer.hv_timer_in_use); return apic->lapic_timer.hv_timer_in_use; but I'm afraid of introducing a mutual recursion between start_hv_timer and kvm_lapic_expired_hv_timer. Paolo