linux-kernel - Re: [PATCH v2 2/3] KVM: LAPIC: lapic timer interrupt is injected by posted interrupt

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]

Message-ID: <CANRm+Cy4wBMZLVEHY3v+eAe859a8yR+cJ3ZFDor0nWZdufC0Zg@mail.gmail.com>
Date:   Tue, 11 Jun 2019 16:18:47 +0800
From:   Wanpeng Li <kernellwp@...il.com>
To:     Radim Krčmář <rkrcmar@...hat.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, kvm <kvm@...r.kernel.org>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH v2 2/3] KVM: LAPIC: lapic timer interrupt is injected by
 posted interrupt

On Tue, 11 Jun 2019 at 00:51, Radim Krčmář <rkrcmar@...hat.com> wrote:
>
> 2019-06-06 13:31+0800, Wanpeng Li:
> > From: Wanpeng Li <wanpengli@...cent.com>
> >
> > Dedicated instances are currently disturbed by unnecessary jitter due
> > to the emulated lapic timers fire on the same pCPUs which vCPUs resident.
> > There is no hardware virtual timer on Intel for guest like ARM. Both
> > programming timer in guest and the emulated timer fires incur vmexits.
> > This patch tries to avoid vmexit which is incurred by the emulated
> > timer fires in dedicated instance scenario.
> >
> > When nohz_full is enabled in dedicated instances scenario, the emulated
> > timers can be offload to the nearest busy housekeeping cpus since APICv
> > is really common in recent years. The guest timer interrupt is injected
> > by posted-interrupt which is delivered by housekeeping cpu once the emulated
> > timer fires.
> >
> > 3%~5% redis performance benefit can be observed on Skylake server.
> >
> > Signed-off-by: Wanpeng Li <wanpengli@...cent.com>
> > ---
> >  arch/x86/kvm/lapic.c | 32 +++++++++++++++++++++++++-------
> >  arch/x86/kvm/x86.h   |  5 +++++
> >  2 files changed, 30 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index 09b7387..c08e5a8 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -133,6 +133,12 @@ static inline bool posted_interrupt_inject_timer_enabled(struct kvm_vcpu *vcpu)
> >               kvm_mwait_in_guest(vcpu->kvm);
> >  }
> >
> > +static inline bool can_posted_interrupt_inject_timer(struct kvm_vcpu *vcpu)
> > +{
> > +     return posted_interrupt_inject_timer_enabled(vcpu) &&
> > +             !vcpu_halt_in_guest(vcpu);
>
> It would make more sense to have a condition for general blocking in
> KVM, but keep in mind that we're not running on the same cpu anymore, so
> any code like that has to be properly protected against VM entries under
> our hands.  (The VCPU could appear halted here, but before we get make
> the timer pending, the VCPU would enter and potentially never check the
> interrupt.)
>
> I think we should be able to simply do
>
>   if (posted_interrupt_inject_timer_enabled(vcpu))
>         kvm_inject_apic_timer_irqs();
>
> directly in the apic_timer_expired() as the injection will wake up the
> target if necessary.  It's going to be a bit slow for timer callback in
> those (too slow to warrant special handling?), but there hopefully
> aren't any context restrictions in place.

The vCPU halt status is used to handle non-PV apf notification aware
guest which is pointed out by Paolo.
https://lkml.org/lkml/2019/6/5/436 The vCPU will not re-vmentry w/
timer interrupt even if there is a kick since vcpu->arch.apf.halted is
true and it can't escape from kvm_vcpu_check_block().

Regards,
Wanpeng Li