From: Avi Kivity <avi@redhat.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: Gleb Natapov <gleb@redhat.com>,
"Nadav Har'El" <nyh@math.technion.ac.il>,
Chris Wright <chrisw@redhat.com>,
kvm@vger.kernel.org
Subject: Re: KVM call minutes for Sept 21
Date: Mon, 27 Sep 2010 10:36:57 +0200 [thread overview]
Message-ID: <4CA057A9.7030800@redhat.com> (raw)
In-Reply-To: <20100926202554.GN15338@8bytes.org>
On 09/26/2010 10:25 PM, Joerg Roedel wrote:
> > btw, speaking of drastic changes to nsvm, one thing I'd like to see is
> > the replacement of those kmaps with something like put_user_try() and
> > put_user_catch(). It should be as fast (or faster) than kmaps, and not
> > affect preemptibility.
>
> Yes, I want to get rid of them too. I thought about using
> copy_from/to_user in the vmrun/vmexit path. I need to measure if this
> has any performance impact, though.
copy_to_user() is slow since it is very generic. put_user() generally
translates to one instruction (perhaps a range check as well). We can
avoid the range check if we do it once for the entire vmcb page.
Gleb had something along those lines, it's useful for kvmclock as well.
> But the vmrun/vmexit path in nested-svm will see some major changes in
> the near future anyway to improve performance and prepare it for
> clean-bits emulation. In this step I will also address the kmap
> problem. But first on the list for me is to make the instruction
> emulator aware of instruction intercepts. Security is more important
> then performance.
>
Amen.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-09-27 8:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-21 18:05 KVM call minutes for Sept 21 Chris Wright
2010-09-21 18:23 ` Anthony Liguori
2010-09-22 0:04 ` Nadav Har'El
2010-09-22 1:48 ` Chris Wright
2010-09-22 17:49 ` Nadav Har'El
2010-09-22 18:03 ` Anthony Liguori
2010-09-22 19:34 ` Joerg Roedel
2010-09-22 19:48 ` Joerg Roedel
2010-09-22 9:02 ` Gleb Natapov
2010-09-22 16:29 ` Nadav Har'El
2010-09-22 17:47 ` Gleb Natapov
2010-09-22 19:20 ` Joerg Roedel
2010-09-22 20:18 ` Gleb Natapov
2010-09-22 23:00 ` Nadav Har'El
2010-09-26 14:03 ` Avi Kivity
2010-09-26 20:25 ` Joerg Roedel
2010-09-27 8:36 ` Avi Kivity [this message]
2010-09-27 14:18 ` Gleb Natapov
2010-09-27 14:22 ` Avi Kivity
2010-09-26 13:27 ` Avi Kivity
2010-09-26 14:28 ` Nadav Har'El
2010-09-26 14:50 ` Avi Kivity
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=4CA057A9.7030800@redhat.com \
--to=avi@redhat.com \
--cc=chrisw@redhat.com \
--cc=gleb@redhat.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=nyh@math.technion.ac.il \
/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