From: Nadav Har'El <nyh@math.technion.ac.il>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: "Mao, Junjie" <junjie.mao@intel.com>,
"'kvm@vger.kernel.org'" <kvm@vger.kernel.org>
Subject: Re: [PATCH v2] KVM: x86: Implement PCID/INVPCID for guests with EPT
Date: Tue, 15 May 2012 08:50:09 +0300 [thread overview]
Message-ID: <20120515055009.GA20705@fermat.math.technion.ac.il> (raw)
In-Reply-To: <20120515024212.GA17358@amt.cnet>
On Mon, May 14, 2012, Marcelo Tosatti wrote about "Re: [PATCH v2] KVM: x86: Implement PCID/INVPCID for guests with EPT":
> > + * Enable INVPCID for non-ept guests may cause performance regression,
> > + * and without INVPCID, PCID has little benefits. So disable them all
> > + * for non-ept guests.
> > + *
> > + * PCID is not supported for nested guests yet.
> > + */
> > + return enable_ept && (boot_cpu_data.x86_capability[4] & bit(X86_FEATURE_PCID)) && !cpu_has_hypervisor;
> > +}
>
> The comment Avi made was regarding running a nested guest, not running
> _as_ a nested guest (which is what cpu_has_hypervisor is about).
>
> You can disable INVPCID exec control (which #UDs), if its in Level-2
> guest mode (see if_guest_mode()), and restore the Level-1 value when
> leaving nested mode.
I also don't understand the !cpu_has_hypervisor thing. Regarding
running a nested guest - the code in prepare_vmcs02() sets (among other
things) secondary exec controls used to run the L2 guest. It mostly
"or"s the bits requested by KVM (L0) and the guest (L1). So:
1. If you think L0 mustn't run L2 with a certain bit, despite running L1
with it (I didn't follow the reasoning why this is the case), you can
specificially turn it off in that function (like we already do for
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES).
2. The other thing that could theoretically happen is that L1 will ask
to turn on this bit for L2 (I think this is the case you wanted to
avoid). This *won't* happen, because we tell L1 via MSR which bits
it is allowed to set on secondary controls (see
nested_vmx_secondary_ctls_high), and currently this only includes
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES and
SECONDARY_EXEC_ENABLE_EPT (the latter only for nested EPT), and enforce
that L1 doesn't try to turn on more bits.
--
Nadav Har'El | Tuesday, May 15 2012,
nyh@math.technion.ac.il |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |A bird in the hand is safer than one
http://nadav.harel.org.il |overhead.
next prev parent reply other threads:[~2012-05-15 5:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-14 6:25 [PATCH v2] KVM: x86: Implement PCID/INVPCID for guests with EPT Mao, Junjie
2012-05-15 2:42 ` Marcelo Tosatti
2012-05-15 5:50 ` Nadav Har'El [this message]
2012-05-17 1:22 ` Mao, Junjie
2012-05-17 2:37 ` Mao, Junjie
2012-05-17 14:46 ` Marcelo Tosatti
2012-05-17 2:54 ` 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=20120515055009.GA20705@fermat.math.technion.ac.il \
--to=nyh@math.technion.ac.il \
--cc=junjie.mao@intel.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
/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