From: Wanpeng Li <kernellwp@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
kvm <kvm@vger.kernel.org>, "Radim Krčmář" <rkrcmar@redhat.com>,
"Wanpeng Li" <wanpeng.li@hotmail.com>
Subject: Re: [PATCH v3] KVM: LAPIC: Fix lapic timer injection delay
Date: Thu, 29 Jun 2017 11:42:24 +0800 [thread overview]
Message-ID: <CANRm+CzcfwQg=0dJzGD8E4d+ay-eMZz+xTpVEZFSwugF-epNyA@mail.gmail.com> (raw)
In-Reply-To: <6fc8f133-15b8-3ee2-1483-614642deffa0@redhat.com>
2017-06-28 22:30 GMT+08:00 Paolo Bonzini <pbonzini@redhat.com>:
>
>
> On 28/06/2017 16:27, Wanpeng Li wrote:
>> 2017-06-28 20:10 GMT+08:00 Paolo Bonzini <pbonzini@redhat.com>:
>>>
>>>
>>> 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.
>>
>> We can just handle the apic timer oneshot/tscdeadline mode instead of
>> periodic mode just like which is emulated by hrtimer to avoid the
>> mutual recusion, what do you think?
>
> In that case, set_hv_timer should probably always enable the preemption
> timer. You can then cancel it if it returns 1 _and_ the APIC timer's
> mode is oneshot/tscdeadline.
>
> Paolo
So how about something like this?
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index d24c874..900ce86 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);
+
+ /* 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 && (apic_lvtt_oneshot(apic) ||
apic_lvtt_tscdeadline(apic)))
+ apic_timer_expired(apic);
+ }
+ }
- 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);
+ if (need_cancel)
+ cancel_hv_timer(apic);
- /* In case the sw timer triggered in the window */
- if (atomic_read(&apic->lapic_timer.pending) &&
- !apic_lvtt_period(apic))
- 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;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4f616db..0a0e696 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -11125,6 +11125,9 @@ static int vmx_set_hv_timer(struct kvm_vcpu
*vcpu, u64 guest_deadline_tsc)
u64 guest_tscl = kvm_read_l1_tsc(vcpu, tscl);
u64 delta_tsc = max(guest_deadline_tsc, guest_tscl) - guest_tscl;
+ if (delta_tsc == 0)
+ return 1;
+
/* Convert to host delta tsc if tsc scaling is enabled */
if (vcpu->arch.tsc_scaling_ratio != kvm_default_tsc_scaling_ratio &&
u64_shl_div_u64(delta_tsc,
next prev parent reply other threads:[~2017-06-29 3:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-28 1:29 [PATCH v3] KVM: LAPIC: Fix lapic timer injection delay Wanpeng Li
2017-06-28 12:10 ` Paolo Bonzini
2017-06-28 13:55 ` Wanpeng Li
2017-06-28 14:00 ` Paolo Bonzini
2017-06-28 14:05 ` Wanpeng Li
2017-06-28 14:27 ` Wanpeng Li
2017-06-28 14:30 ` Paolo Bonzini
2017-06-29 3:42 ` Wanpeng Li [this message]
2017-06-29 7:55 ` Paolo Bonzini
2017-06-29 8:17 ` Wanpeng Li
2017-06-29 8:44 ` Wanpeng Li
2017-06-29 11:43 ` Paolo Bonzini
2017-06-29 11:54 ` Wanpeng Li
2017-06-29 12:05 ` Wanpeng Li
2017-06-29 12:13 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANRm+CzcfwQg=0dJzGD8E4d+ay-eMZz+xTpVEZFSwugF-epNyA@mail.gmail.com' \
--to=kernellwp@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=wanpeng.li@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).