From: Avi Kivity <avi@redhat.com>
To: "Nadav Har'El" <nyh@math.technion.ac.il>
Cc: kvm@vger.kernel.org, mtosatti@redhat.com
Subject: Re: Why exit on MSR_STAR and friends?
Date: Thu, 17 Feb 2011 11:22:04 +0200 [thread overview]
Message-ID: <4D5CE8BC.8020306@redhat.com> (raw)
In-Reply-To: <20110216151706.GA21823@fermat.math.technion.ac.il>
On 02/16/2011 05:17 PM, Nadav Har'El wrote:
> Hi, In the recent KVM forum, Marcelo Tosatti presented some KVM performance
> improvements. One of them (page 17 of the presentation) was about the MSRs
> used by SYSCALL: MSR_STAR, MSR_LSTAR, MSR_CSTAR (and also MSR_SYSCALL_MASK).
>
> He said that "Guests have direct access to these MSRs", and this is why KVM
> needs to restore their original host value when returning to user space
> (they aren't used in the kernel, so there's no reason to restore them earlier).
>
> I was suprised, then, to discover that KVM doesn't add these MSRs to the
> MSR bitmap, so when the guest changes these MSR values, or even reads them,
> we cause an exit - both on read and on write of these MSRs.
>
> I was wondering why these exits are needed.
> I can maybe guess why an exit is needed on write - just to save the guest
> value so we don't need to read it when going back to user space. Is this
> a good optimization because we assume that the guest very rarely changes
> these MSRs?
Exactly.
> Or is there another explanation as to why these exits are
> needed?
No.
> But I can't even guess why an exit is needed on read...
It isn't needed. The code doesn't distinguish between the read and
write bitmaps, and so far no guest issues rdmsr for these msrs with any
frequency (kvm as a guest will write those msrs, but it shouldn't read
them on Intel). Do you see frequent reads on some guest?
> If you're curious why I noticed these exits - I was running a nested KVM
> (L0's guest L1 is KVM, that itself has a guest L2). Whenever L2 does something
> that L1 needs to handle in user space (e.g., PIO), L1 does all these MSR
> reads and writes, and we get exits for each of them - many of those exits
> for each L2 PIO :(
It shouldn't be doing MSR reads. The only MSR read I can see is for
SYSENTER_ESP when a vcpu is migrated (easily avoided). But maybe I'm
missing something.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2011-02-17 10:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-16 15:17 Why exit on MSR_STAR and friends? Nadav Har'El
2011-02-17 9:22 ` Avi Kivity [this message]
2011-02-17 10:29 ` Nadav Har'El
2011-02-17 10:39 ` 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=4D5CE8BC.8020306@redhat.com \
--to=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--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