All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Sean Christopherson <seanjc@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Michael Tokarev <mjt@tls.msk.ru>,
	Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: [PATCH v3 3/9] KVM: x86: Defer tick-based accounting 'til after IRQ handling
Date: Wed, 21 Apr 2021 14:19:40 +0200	[thread overview]
Message-ID: <20210421121940.GD16580@lothringen> (raw)
In-Reply-To: <YH9jKpeviZtMKxt8@google.com>

On Tue, Apr 20, 2021 at 11:26:34PM +0000, Sean Christopherson wrote:
> On Wed, Apr 21, 2021, Frederic Weisbecker wrote:
> > On Thu, Apr 15, 2021 at 03:21:00PM -0700, Sean Christopherson wrote:
> > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > index 16fb39503296..e4d475df1d4a 100644
> > > --- a/arch/x86/kvm/x86.c
> > > +++ b/arch/x86/kvm/x86.c
> > > @@ -9230,6 +9230,14 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> > >  	local_irq_disable();
> > >  	kvm_after_interrupt(vcpu);
> > >  
> > > +	/*
> > > +	 * When using tick-based accounting, wait until after servicing IRQs to
> > > +	 * account guest time so that any ticks that occurred while running the
> > > +	 * guest are properly accounted to the guest.
> > > +	 */
> > > +	if (!vtime_accounting_enabled_this_cpu())
> > > +		vtime_account_guest_exit();
> > 
> > Can we rather have instead:
> > 
> > static inline void tick_account_guest_exit(void)
> > {
> > 	if (!vtime_accounting_enabled_this_cpu())
> > 		current->flags &= ~PF_VCPU;
> > }
> > 
> > It duplicates a bit of code but I think this will read less confusing.
> 
> Either way works for me.  I used vtime_account_guest_exit() to try to keep as
> many details as possible inside vtime, e.g. in case the implemenation is tweaked
> in the future.  But I agree that pretending KVM isn't already deeply intertwined
> with the details is a lie.

Ah I see, before 87fa7f3e98a131 the vtime was accounted after interrupts get
processed. So it used to work until then. I see that ARM64 waits for IRQs to
be enabled too.

PPC/book3s_hv, MIPS, s390 do it before IRQs get re-enabled (weird, how does that
work?)

And PPC/book3s_pr calls guest_exit() so I guess it has interrupts enabled.

The point is: does it matter to call vtime_account_guest_exit() before or
after interrupts? If it doesn't matter, we can simply call
vtime_account_guest_exit() once and for all once IRQs are re-enabled.

If it does matter because we don't want to account the host IRQs firing at the
end of vcpu exit, then probably we should standardize that behaviour and have
guest_exit_vtime() called before interrupts get enabled and guest_exit_tick()
called after interrupts get enabled. It's probably then beyond the scope of this
patchset but I would like to poke your opinion on that.

Thanks.

  parent reply	other threads:[~2021-04-21 12:19 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-15 22:20 [PATCH v3 0/9] KVM: Fix tick-based accounting for x86 guests Sean Christopherson
2021-04-15 22:20 ` [PATCH v3 1/9] context_tracking: Move guest exit context tracking to separate helpers Sean Christopherson
2021-04-20 18:48   ` Christian Borntraeger
2021-04-21 10:57   ` Frederic Weisbecker
2021-04-15 22:20 ` [PATCH v3 2/9] context_tracking: Move guest exit vtime accounting " Sean Christopherson
2021-04-20 18:48   ` Christian Borntraeger
2021-04-15 22:21 ` [PATCH v3 3/9] KVM: x86: Defer tick-based accounting 'til after IRQ handling Sean Christopherson
2021-04-20 23:14   ` Frederic Weisbecker
2021-04-20 23:26     ` Sean Christopherson
2021-04-21 10:11       ` Frederic Weisbecker
2021-04-21 12:19       ` Frederic Weisbecker [this message]
2021-04-28 22:38         ` Sean Christopherson
2021-04-21 10:07   ` Frederic Weisbecker
2021-04-15 22:21 ` [PATCH v3 4/9] sched/vtime: Move vtime accounting external declarations above inlines Sean Christopherson
2021-04-21  7:02   ` Christian Borntraeger
2021-04-15 22:21 ` [PATCH v3 5/9] sched/vtime: Move guest enter/exit vtime accounting to vtime.h Sean Christopherson
2021-04-15 22:21 ` [PATCH v3 6/9] context_tracking: Consolidate guest enter/exit wrappers Sean Christopherson
2021-04-15 22:21 ` [PATCH v3 7/9] context_tracking: KVM: Move guest enter/exit wrappers to KVM's domain Sean Christopherson
2021-04-21  7:10   ` Christian Borntraeger
2021-04-15 22:21 ` [PATCH v3 8/9] KVM: x86: Consolidate guest enter/exit logic to common helpers Sean Christopherson
2021-04-15 22:21 ` [PATCH v3 9/9] KVM: Move instrumentation-safe annotations for enter/exit to x86 code Sean Christopherson
2021-04-21  8:09   ` Christian Borntraeger
2021-04-22 14:38     ` Sven Schnelle
2021-04-23  9:32       ` Vasily Gorbik
2021-04-20 23:33 ` [PATCH v3 0/9] KVM: Fix tick-based accounting for x86 guests Frederic Weisbecker

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=20210421121940.GD16580@lothringen \
    --to=frederic@kernel.org \
    --cc=borntraeger@de.ibm.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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 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.