From: Avi Kivity <avi@redhat.com>
To: "Mao, Junjie" <junjie.mao@intel.com>
Cc: "'kvm@vger.kernel.org'" <kvm@vger.kernel.org>
Subject: Re: [PATCH] KVM: x86: Implement PCID/INVPCID for guests with EPT
Date: Sun, 13 May 2012 13:02:55 +0300 [thread overview]
Message-ID: <4FAF86CF.1000207@redhat.com> (raw)
In-Reply-To: <EF5A1D57CFBD5A4BA5EB3ED985B6DC6E066912@SHSMSX101.ccr.corp.intel.com>
On 05/11/2012 08:58 AM, Mao, Junjie wrote:
> > >
> > > +static bool vmx_pcid_supported(void)
> > > +{
> > > + /* Enable PCID for non-ept guests may cause performance regression
> > > +*/
> >
> > Why is that?
>
> For guests using shadow page tables, every INVPCID must be intercepted so that changes in guest page tables can be reflected on the shadow ones, which brings about performance troubles. Without INVPCID, the PCID feature has little benefits. As a result, PCID/INVPCID is not exposed to non-ept guests. Sorry for being unclear in the comment.
Okay, please update the comment. btw, are there plans to add PCID
support to Linux in the OS role?
> > > +
> > > + vmx->invpcid_enabled = false;
> > > + if (vmx_pcid_supported()) {
> > > + exec_control = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
> > > + if (exec_control & SECONDARY_EXEC_ENABLE_INVPCID) {
> > > + best = kvm_find_cpuid_entry(vcpu, 0x1, 0);
> > > + if (best && (best->ecx & bit(X86_FEATURE_PCID)))
> > > + vmx->invpcid_enabled = true;
> > > + else {
> > > + exec_control &= ~SECONDARY_EXEC_ENABLE_INVPCID;
> > > + vmcs_write32(SECONDARY_VM_EXEC_CONTROL,
> > > + exec_control);
> > > + best = kvm_find_cpuid_entry(vcpu, 0x7, 0);
> > > + best->ecx &= ~bit(X86_FEATURE_INVPCID);
> > > + }
> > > + }
> > > + }
> > > }
> > >
> > >
> >
> > If we enter a nested guest (which is running without PCID), we need either to
> > handle INVPCID exits (and inject a #UD) or disable INVPCID in exec controls.
> > The first is faster since it doesn't involve VMWRITEs.
> > If we do that, we don't need this code (since it will work for non-nested guests
> > as well).
>
> I'm not that familiar with how nested guests work. So excuse me for a possibly silly question: if we choose to trigger INVPCID exits and inject #UD for both non-nested and nested guests without INVPCID, that means 'INVLPG exiting' should also be set (which is a must for triggering INVPCID exits). Can it cause performance problems for non-nested ept guests?
It can. It was my comment that was silly, the guest and the nested
guest use different vmcses, so all you need is to make sure the write
here goes to the non-nested vmcs (and "enable INVPCID" is kept as zero
for nested vmcses).
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2012-05-13 10:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-10 0:32 [PATCH] KVM: x86: Implement PCID/INVPCID for guests with EPT Mao, Junjie
2012-05-10 11:48 ` Avi Kivity
2012-05-11 5:58 ` Mao, Junjie
2012-05-13 10:02 ` Avi Kivity [this message]
2012-05-14 7:18 ` Mao, Junjie
2012-05-10 11:49 ` Avi Kivity
[not found] ` <CAG7+5M2XSOoHqqpbp0YbjgNNfa6DwrfP+88TwRUbhBDUDH6q6A@mail.gmail.com>
2012-05-14 7:15 ` Mao, Junjie
2012-05-15 2:20 ` Marcelo Tosatti
2012-05-15 3:28 ` Mao, Junjie
2012-05-15 3:27 ` Marcelo Tosatti
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=4FAF86CF.1000207@redhat.com \
--to=avi@redhat.com \
--cc=junjie.mao@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox