All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Li,Rongqing" <lirongqing@baidu.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
	"seanjc@google.com" <seanjc@google.com>,
	"wanpengli@tencent.com" <wanpengli@tencent.com>,
	"jmattson@google.com" <jmattson@google.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"bp@alien8.de" <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: 答复: [PATCH] KVM: Clear pv eoi pending bit only when it is set
Date: Wed, 20 Oct 2021 03:43:58 +0000	[thread overview]
Message-ID: <d2d3fca1cca7438e97a0641fdd6befac@baidu.com> (raw)
In-Reply-To: <87y26pwk96.fsf@vitty.brq.redhat.com>



> -----邮件原件-----
> 发件人: Vitaly Kuznetsov <vkuznets@redhat.com>
> 发送时间: 2021年10月19日 15:24
> 收件人: Li,Rongqing <lirongqing@baidu.com>
> 抄送: Li,Rongqing <lirongqing@baidu.com>; pbonzini@redhat.com;
> seanjc@google.com; wanpengli@tencent.com; jmattson@google.com;
> joro@8bytes.org; tglx@linutronix.de; mingo@redhat.com; bp@alien8.de;
> x86@kernel.org; hpa@zytor.com; kvm@vger.kernel.org
> 主题: Re: [PATCH] KVM: Clear pv eoi pending bit only when it is set
> 
> Li RongQing <lirongqing@baidu.com> writes:
> 
> > clear pv eoi pending bit only when it is set, to avoid calling
> > pv_eoi_put_user()
> >
> > and this can speed pv_eoi_clr_pending about 300 nsec on AMD EPYC most
> > of the time
> >
> > Signed-off-by: Li RongQing <lirongqing@baidu.com>
> > ---
> >  arch/x86/kvm/lapic.c |    7 ++++---
> >  1 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index
> > 76fb009..c434f70 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -694,9 +694,9 @@ static void pv_eoi_set_pending(struct kvm_vcpu
> *vcpu)
> >  	__set_bit(KVM_APIC_PV_EOI_PENDING, &vcpu->arch.apic_attention);  }
> >
> > -static void pv_eoi_clr_pending(struct kvm_vcpu *vcpu)
> > +static void pv_eoi_clr_pending(struct kvm_vcpu *vcpu, bool pending)
> 
> Nitpick (and probably a matter of personal taste): pv_eoi_clr_pending() has only
> one user and the change doesn't make its interface much nicer, I'd suggest we
> just inline in instead. (we can probably do the same to
> pv_eoi_get_pending()/pv_eoi_set_pending() too).
> 
> >  {
> > -	if (pv_eoi_put_user(vcpu, KVM_PV_EOI_DISABLED) < 0) {
> > +	if (pending && pv_eoi_put_user(vcpu, KVM_PV_EOI_DISABLED) < 0) {
> >  		printk(KERN_WARNING "Can't clear EOI MSR value: 0x%llx\n",
> >  			   (unsigned long long)vcpu->arch.pv_eoi.msr_val);
> >  		return;
> > @@ -2693,7 +2693,8 @@ static void apic_sync_pv_eoi_from_guest(struct
> kvm_vcpu *vcpu,
> >  	 * While this might not be ideal from performance point of view,
> >  	 * this makes sure pv eoi is only enabled when we know it's safe.
> >  	 */
> > -	pv_eoi_clr_pending(vcpu);
> > +	pv_eoi_clr_pending(vcpu, pending);
> > +
> >  	if (pending)
> >  		return;
> >  	vector = apic_set_eoi(apic);
> 
> Could you probably elaborate a bit (probably by enhancing the comment above
> pv_eoi_clr_pending()) why the race we have here (even before the
> patch) doesn't matter? As far as I understand it, the guest can change PV EOI
> status from a different CPU (it shouldn't do it but it still can) at any time: e.g.
> between pv_eoi_get_pending() and pv_eoi_clr_pending() but also right after we
> do pv_eoi_clr_pending() so the patch doesn't really change much in this regard.
> 

Is it reasonable that the guest change PV EOI status from a different CPU?  I think this can lead to guest error or stuck

And new function pv_eoi_test_and_clear_pending and kvm_test_and_clear_bit_guest_cached should be able to fix the race

I will send V2

Thanks

-Li



> --
> Vitaly


      parent reply	other threads:[~2021-10-20  3:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-19  2:05 [PATCH] KVM: Clear pv eoi pending bit only when it is set Li RongQing
2021-10-19  7:23 ` Vitaly Kuznetsov
2021-10-19  7:29   ` Paolo Bonzini
2021-10-20  3:36     ` 答复: " Li,Rongqing
2021-10-20 11:15     ` Li,Rongqing
2021-10-20  3:43   ` Li,Rongqing [this message]

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=d2d3fca1cca7438e97a0641fdd6befac@baidu.com \
    --to=lirongqing@baidu.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.