From: Joerg Roedel <joro@8bytes.org>
To: Avi Kivity <avi@redhat.com>
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: Sun, 26 Sep 2010 22:25:54 +0200 [thread overview]
Message-ID: <20100926202554.GN15338@8bytes.org> (raw)
In-Reply-To: <4C9F52A1.1060306@redhat.com>
On Sun, Sep 26, 2010 at 04:03:13PM +0200, Avi Kivity wrote:
> I don't expect drastic changes, but then, I still don't understand it well.
>
> Part of the review process is the maintainer becoming familiar (and, in
> some cases, comfortable) with the code. The nit-picking is often just
> me proving to myself that I understand what's happening.
Right, understanding is an important part. One thing I try to achieve
for nested-svm is to make it less likely that unrelated code changes
break it. One step will be accessor funtions to change intercept masks
and tsc_offset.
> 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.
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.
Joerg
next prev parent reply other threads:[~2010-09-26 20:25 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 [this message]
2010-09-27 8:36 ` Avi Kivity
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=20100926202554.GN15338@8bytes.org \
--to=joro@8bytes.org \
--cc=avi@redhat.com \
--cc=chrisw@redhat.com \
--cc=gleb@redhat.com \
--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