All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Bernhard Kauer <bk@alpico.io>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: drop the kvm_has_noapic_vcpu optimization
Date: Fri, 1 Nov 2024 07:49:10 -0700	[thread overview]
Message-ID: <ZyTqZk88JbE3EcTk@google.com> (raw)
In-Reply-To: <ZySXgqcYKoHJ3jcf@mias.mediconcil.de>

On Fri, Nov 01, 2024, Bernhard Kauer wrote:
> On Thu, Oct 31, 2024 at 04:29:52PM -0700, Sean Christopherson wrote:
> > > > Unless your VM doesn't need a timer and doesn't need interrupts of
> > > > any kind, emulating the local APIC in userspace is going to be much
> > > > less performant.
> > > 
> > > Do you have any performance numbers?
> > 
> > Heh, nope.  I actually tried to grab some, mostly out of curiosity again, but
> > recent (last few years) versions of QEMU don't even support a userspace APIC.
> > 
> > A single EOI is a great example though.  On a remotely modern CPU, an in-kernel
> > APIC allows KVM to enable hardware acceleration so that the EOI is virtualized by
> > hardware, i.e. doesn't take a VM-Exit and so the latency is basically the same as
> > a native EOI (tens of cycles, maybe less).
> > 
> > With a userspace APIC, the roundtrip to userspace to emulate the EOI is measured
> > in tens of thousands of cycles.  IIRC, last I played around with userspace exits
> > the average turnaround time was ~50k cycles.
> 
> 
> That sound a lot so I did some quick benchmarking.  An exit is around 1400
> TSC cycles on my AMD laptop, instruction emulation takes 1200 and going
> to user-level needs at least 6200.  Not terribly slow but still room for
> optimizations.

Ah, I suspect my recollection of ~50k cycles is from measuring all exits to
userspace, i.e. included the reaaaaly slow paths.

  reply	other threads:[~2024-11-01 14:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-18 10:08 [PATCH] KVM: drop the kvm_has_noapic_vcpu optimization Bernhard Kauer
2024-10-21  7:43 ` Chao Gao
2024-10-22 17:32 ` Sean Christopherson
2024-10-22 19:08   ` Bernhard Kauer
2024-10-31 16:24     ` Sean Christopherson
2024-10-31 20:08       ` Bernhard Kauer
2024-10-31 23:29         ` Sean Christopherson
2024-11-01  8:55           ` Bernhard Kauer
2024-11-01 14:49             ` Sean Christopherson [this message]
2024-11-15  9:12               ` Bernhard Kauer

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=ZyTqZk88JbE3EcTk@google.com \
    --to=seanjc@google.com \
    --cc=bk@alpico.io \
    --cc=kvm@vger.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.