kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Aili Yao <yaoaili126@gmail.com>
To: Sean Christopherson <seanjc@google.com>
Cc: pbonzini@redhat.com, vkuznets@redhat.com, wanpengli@tencent.com,
	jmattson@google.com, joro@8bytes.org, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	x86@kernel.org, hpa@zytor.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, yaoaili@kingsoft.com
Subject: Re: [PATCH v2] KVM: LAPIC: Per vCPU control over kvm_can_post_timer_interrupt
Date: Wed, 8 Dec 2021 11:36:09 +0800	[thread overview]
Message-ID: <20211208113609.483d5f1a@gmail.com> (raw)
In-Reply-To: <Ya/s17QDlGZi9COR@google.com>

On Tue, 7 Dec 2021 23:23:03 +0000
Sean Christopherson <seanjc@google.com> wrote:

> On Wed, Nov 24, 2021, Aili Yao wrote:
> > When cpu-pm is successfully enabled, and hlt_in_guest is true and
> > mwait_in_guest is false, the guest cant't use Monitor/Mwait instruction
> > for idle operation, instead, the guest may use halt for that purpose, as
> > we have enable the cpu-pm feature and hlt_in_guest is true, we will also
> > minimize the guest exit; For such a scenario, Monitor/Mwait instruction
> > support is totally disabled, the guest has no way to use Mwait to exit from
> > non-root mode;
> > 
> > For cpu-pm feature, hlt_in_guest and others except mwait_in_guest will
> > be a good hint for it. So replace it with hlt_in_guest.  
> 
> This should be a separate patch from the housekeeping_cpu() check, if we add
> the housekeeping check.
> 
> > Signed-off-by: Aili Yao <yaoaili@kingsoft.com>
> > ---
> >  arch/x86/kvm/lapic.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index 759952dd1222..42aef1accd6b 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -34,6 +34,7 @@
> >  #include <asm/delay.h>
> >  #include <linux/atomic.h>
> >  #include <linux/jump_label.h>
> > +#include <linux/sched/isolation.h>
> >  #include "kvm_cache_regs.h"
> >  #include "irq.h"
> >  #include "ioapic.h"
> > @@ -113,13 +114,14 @@ static inline u32 kvm_x2apic_id(struct kvm_lapic *apic)
> >  
> >  static bool kvm_can_post_timer_interrupt(struct kvm_vcpu *vcpu)
> >  {
> > -	return pi_inject_timer && kvm_vcpu_apicv_active(vcpu);
> > +	return pi_inject_timer && kvm_vcpu_apicv_active(vcpu) &&
> > +		!housekeeping_cpu(vcpu->cpu, HK_FLAG_TIMER);  
> 
> Why not check kvm_{hlt,mwait}_in_guest()?  IIUC, non-housekeeping CPUs don't _have_
> to be associated 1:1 with a vCPU, in which case posting the timer is unlikely
> to be a performance win even though the target isn't a housekeeping CPU.

Yes, non-housekeeping CPUs can be assigned to multi vCPUs, I don't think it's a common configuration;
But this can happen.

> And wouldn't exposing HLT/MWAIT to a vCPU that's on a housekeeping CPU be a bogus
> configuration?

Agree, it's a bogus configuration and not suppose to like this, but this can happen;

It seems we can't cover all the abnormal cases in a single line. So I think just checking for
most right configurations is needed.

> >  }
> >  
> >  bool kvm_can_use_hv_timer(struct kvm_vcpu *vcpu)
> >  {
> >  	return kvm_x86_ops.set_hv_timer
> > -	       && !(kvm_mwait_in_guest(vcpu->kvm) ||
> > +	       && !(kvm_hlt_in_guest(vcpu->kvm) ||  
> 
> This is incorrect, the HLT vs. MWAIT isn't purely a posting interrupts thing.  The
> VMX preemption timer counts down in C0, C1, and C2, but not deeper sleep states.
> HLT is always C1, thus it's safe to use the VMX preemption timer even if the guest
> can execute HLT without exiting.
> The timer isn't compatible with MWAIT because it stops counting in C3 (or lower),
> i.e. the guest can cause the timer to stop counting.

Thanks for your pointer, now i know this.

> 
> >  		    kvm_can_post_timer_interrupt(vcpu));
> >  }
> >  EXPORT_SYMBOL_GPL(kvm_can_use_hv_timer);
> > --   
> 
> Splicing in Wanpeng's version to try and merge the two threads:
> 
> On Tue, Nov 23, 2021 at 10:00 PM Wanpeng Li <kernellwp@gmail.com> wrote:
> > ---
> >  arch/x86/kvm/lapic.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index 759952dd1222..8257566d44c7 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -113,14 +113,13 @@ static inline u32 kvm_x2apic_id(struct kvm_lapic *apic)
> >
> >  static bool kvm_can_post_timer_interrupt(struct kvm_vcpu *vcpu)
> >  {
> > -       return pi_inject_timer && kvm_vcpu_apicv_active(vcpu);
> > +       return pi_inject_timer && kvm_mwait_in_guest(vcpu->kvm) && kvm_vcpu_apicv_active(vcpu);  
> 
> As Aili's changelog pointed out, MWAIT may not be advertised to the guest. 
> 
> So I think we want this?  With a non-functional, opinionated refactoring of
> kvm_can_use_hv_timer() because I'm terrible at reading !(a || b).
> 
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 40270d7bc597..c77cb386d03d 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -113,14 +113,25 @@ static inline u32 kvm_x2apic_id(struct kvm_lapic *apic)
> 
>  static bool kvm_can_post_timer_interrupt(struct kvm_vcpu *vcpu)
>  {
> -       return pi_inject_timer && kvm_vcpu_apicv_active(vcpu);
> +       return pi_inject_timer && kvm_vcpu_apicv_active(vcpu) &&
> +              (kvm_mwait_in_guest(vcpu) || kvm_hlt_in_guest(vcpu));
>  }

I think only kvm_hlt_in_guest() check is enough here, as for current code, if kvm_mwait_in_guest() is true,
kvm_hlt_in_guest must be ture, if kvm_mwait_in_guest() is false, kvm_hlt_in_guest() could also
be true.

>  bool kvm_can_use_hv_timer(struct kvm_vcpu *vcpu)
>  {
> -       return kvm_x86_ops.set_hv_timer
> -              && !(kvm_mwait_in_guest(vcpu->kvm) ||
> -                   kvm_can_post_timer_interrupt(vcpu));
> +       /*
> +        * Don't use the hypervisor timer, a.k.a. VMX Preemption Timer, if the
> +        * guest can execute MWAIT without exiting as the timer will stop
> +        * counting if the core enters C3 or lower.  HLT in the guest is ok as
> +        * HLT is effectively C1 and the timer counts in C0, C1, and C2.
> +        *
> +        * Don't use the hypervisor timer if KVM can post a timer interrupt to
> +        * the guest since posted the timer avoids taking an extra a VM-Exit
> +        * when the timer expires.
> +        */
> +       return kvm_x86_ops.set_hv_timer &&
> +              !kvm_mwait_in_guest(vcpu->kvm) &&
> +              !kvm_can_post_timer_interrupt(vcpu));
>  }
>  EXPORT_SYMBOL_GPL(kvm_can_use_hv_timer);
> 

I think this modification covers most used configurations and it's right.
Thanks!

--Aili Yao
 

  reply	other threads:[~2021-12-08  3:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-24  4:54 [PATCH v2] KVM: LAPIC: Per vCPU control over kvm_can_post_timer_interrupt Aili Yao
2021-12-07 23:23 ` Sean Christopherson
2021-12-08  3:36   ` Aili Yao [this message]
2021-12-08 10:21   ` Aili Yao
2021-12-09 18:20     ` Sean Christopherson
2021-12-10  3:47       ` Aili Yao
2021-12-16  8:23   ` Aili Yao
2021-12-16 15:45     ` Sean Christopherson
2021-12-17  2:22       ` Aili Yao

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=20211208113609.483d5f1a@gmail.com \
    --to=yaoaili126@gmail.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    --cc=yaoaili@kingsoft.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).