linux-kernel - Re: [PATCH 3/3] KVM: LAPIC: Fix lapic timer injection delay

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 2 Jul 2017 09:56:16 +0800
From:   Wanpeng Li <kernellwp@...il.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        kvm <kvm@...r.kernel.org>, Radim Krcmar <rkrcmar@...hat.com>,
        Wanpeng Li <wanpeng.li@...mail.com>
Subject: Re: [PATCH 3/3] KVM: LAPIC: Fix lapic timer injection delay

2017-07-02 9:35 GMT+08:00 Wanpeng Li <kernellwp@...il.com>:
> 2017-06-30 0:58 GMT+08:00 Paolo Bonzini <pbonzini@...hat.com>:
>> From: Wanpeng Li <wanpeng.li@...mail.com>
>>
>> If the TSC deadline timer is programmed really close to the deadline or
>> even in the past, the computation in vmx_set_hv_timer will program the
>> absolute target tsc value to vmcs preemption timer field w/ delta == 0.
>> The next vmentry results in an immediate vmx preemption timer vmexit
>> and the lapic timer injection is delayed due to this duration.  Actually
>> the lapic timer which is emulated by hrtimer can handle this correctly.
>>
>> This patch fixes it by firing the lapic timer and injecting a timer interrupt
>> immediately during the next vmentry if the TSC deadline timer is programmed
>> really close to the deadline or even in the past. This saves ~1200 cycles on
>> the tscdeadline_immed test of vmexit.flat.
>>
>> Cc: Paolo Bonzini <pbonzini@...hat.com>
>> Cc: Radim Krčmář <rkrcmar@...hat.com>
>> Signed-off-by: Wanpeng Li <wanpeng.li@...mail.com>
>> [Rebased on top of previous patch. - Paolo]
>> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
>> ---
>>  arch/x86/kvm/lapic.c | 5 ++++-
>>  arch/x86/kvm/vmx.c   | 3 ++-
>>  2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
>> index a80e5a5d6f2f..2819d4c123eb 100644
>> --- a/arch/x86/kvm/lapic.c
>> +++ b/arch/x86/kvm/lapic.c
>> @@ -1525,8 +1525,11 @@ static bool start_hv_timer(struct kvm_lapic *apic)
>>          * the window.  For periodic timer, leave the hv timer running for
>>          * simplicity, and the deadline will be recomputed on the next vmexit.
>>          */
>> -       if (!apic_lvtt_period(apic) && atomic_read(&ktimer->pending))
>> +       if (!apic_lvtt_period(apic) && (r || atomic_read(&ktimer->pending))) {
>> +               if (r)
>> +                       apic_timer_expired(apic);
>>                 return false;
>> +       }
>
> This logic is not the same as in my v4
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1434040.html
> . You return false for the expired timer and actually it will switch
> to sw timer.

Ah, I miss read it, the rebase is correct.

Regards,
Wanpeng Li

>
>>
>>         trace_kvm_hv_timer_state(apic->vcpu->vcpu_id, true);
>>         return true;
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index e8b61ad84a8e..92ddea08f999 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -11147,7 +11147,8 @@ static int vmx_set_hv_timer(struct kvm_vcpu *vcpu, u64 guest_deadline_tsc)
>>         vmx->hv_deadline_tsc = tscl + delta_tsc;
>>         vmcs_set_bits(PIN_BASED_VM_EXEC_CONTROL,
>>                         PIN_BASED_VMX_PREEMPTION_TIMER);
>> -       return 0;
>> +
>> +       return delta_tsc == 0;
>>  }
>>
>>  static void vmx_cancel_hv_timer(struct kvm_vcpu *vcpu)
>> --
>> 1.8.3.1
>>