linux-kernel - Re: [PATCH v2] KVM: LAPIC: Per vCPU control over kvm_can_post_timer

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:   Thu, 16 Dec 2021 15:45:57 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Aili Yao <yaoaili126@...il.com>
Cc:     pbonzini@...hat.com, vkuznets@...hat.com, wanpengli@...cent.com,
        jmattson@...gle.com, joro@...tes.org, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
        x86@...nel.org, hpa@...or.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, yaoaili@...gsoft.com
Subject: Re: [PATCH v2] KVM: LAPIC: Per vCPU control over
 kvm_can_post_timer_interrupt

On Thu, Dec 16, 2021, Aili Yao wrote:
> On Tue, 7 Dec 2021 23:23:03 +0000
> Sean Christopherson <seanjc@...gle.com> wrote:
> > On Tue, Nov 23, 2021 at 10:00 PM Wanpeng Li <kernellwp@...il.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));
> >  }
> > 
> >  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);
> > 
> 
> It seems Sean and Wanpeng are busy with some other more important issues;
> So Please let me try to merge Sean, Wanpeng's ideas and suggestions together,also including my opinions
> into one possible approach and get it reviewed, Only if others are OK with this;
> 
> I will post a new patch for this later today or tomorrow.

Sorry, I was waiting for someone to say "this works", but never actually said as
much.

Does the above change address your use case?  If not, what's missing?