Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <1559799086-13912-1-git-send-email-wanpengli@tencent.com>
 <1559799086-13912-3-git-send-email-wanpengli@tencent.com> <20190610165127.GA8389@flask>
In-Reply-To: <20190610165127.GA8389@flask>
From:   Wanpeng Li <kernellwp@gmail.com>
Date:   Tue, 11 Jun 2019 16:18:47 +0800
Message-ID: <CANRm+Cy4wBMZLVEHY3v+eAe859a8yR+cJ3ZFDor0nWZdufC0Zg@mail.gmail.com>
Subject: Re: [PATCH v2 2/3] KVM: LAPIC: lapic timer interrupt is injected by
 posted interrupt
To:     =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>
Cc:     LKML <linux-kernel@vger.kernel.org>, kvm <kvm@vger.kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 11 Jun 2019 at 00:51, Radim Kr=C4=8Dm=C3=A1=C5=99 <rkrcmar@redhat.c=
om> wrote:
>
> 2019-06-06 13:31+0800, Wanpeng Li:
> > From: Wanpeng Li <wanpengli@tencent.com>
> >
> > Dedicated instances are currently disturbed by unnecessary jitter due
> > to the emulated lapic timers fire on the same pCPUs which vCPUs residen=
t.
> > 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 emu=
lated
> > timer fires.
> >
> > 3%~5% redis performance benefit can be observed on Skylake server.
> >
> > Signed-off-by: Wanpeng Li <wanpengli@tencent.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_e=
nabled(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