From: Paolo Bonzini <pbonzini@redhat.com>
To: Wanpeng Li <wanpeng.li@hotmail.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Bandan Das <bsd@redhat.com>,
Wincy Van <fanwenyi0529@gmail.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/5] KVM: nVMX: nested VPID emulation
Date: Fri, 16 Oct 2015 15:14:38 +0200 [thread overview]
Message-ID: <5620F83E.6000500@redhat.com> (raw)
In-Reply-To: <BLU436-SMTP2299992AA8FAFDA3C66B584803D0@phx.gbl>
On 16/10/2015 15:13, Wanpeng Li wrote:
> Ping, :-)
> On 10/14/15 12:12 AM, Wanpeng Li wrote:
>> v2 -> v3:
>> * separate nested_vmx_vpid_caps and move checks to patch 3/5,
>> only rejoin them when reading the MSR.
>>
>> v1 -> v2:
>> * set bit 32 of the VMX_EPT_VPID_CAP MSR
>> * check against the supported types in the implementation of
>> the INVVPID instruction
>> * the memory operand must always be read even if it isn't needed
>> (e.g., for type==global), similar to INVEPT
>> * for single-context invalidation to check that VPID != 0, though in
>> practice that doesn't matter because we don't want to support
>> single-context invalidation
>> * don't set msr's ept related bits if !enable_ept
>>
>>
>> VPID is used to tag address space and avoid a TLB flush. Currently L0 use
>> the same VPID to run L1 and all its guests. KVM flushes VPID when
>> switching
>> between L1 and L2.
>>
>> This patch advertises VPID to the L1 hypervisor, then address space of L1
>> and L2 can be separately treated and avoid TLB flush when swithing
>> between
>> L1 and L2. For each nested vmentry, if vpid12 is changed, reuse shadow
>> vpid
>> w/ an invvpid.
>>
>> Performance:
>>
>> run lmbench on L2 w/ 3.5 kernel.
>>
>> Context switching - times in microseconds - smaller is better
>> -------------------------------------------------------------------------
>> Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K
>> 16p/64K
>> ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
>> ctxsw
>> --------- ------------- ------ ------ ------ ------ ------ -------
>> -------
>> kernel Linux 3.5.0-1 1.2200 1.3700 1.4500 4.7800 2.3300 5.60000
>> 2.88000 nested VPID
>> kernel Linux 3.5.0-1 1.2600 1.4300 1.5600 12.7 12.9 3.49000
>> 7.46000 vanilla
>>
>> Wanpeng Li (5):
>> KVM: VMX: adjust interface to allocate/free_vpid
>> KVM: VMX: introduce __vmx_flush_tlb to handle specific vpid
>> KVM: nVMX: emulate the INVVPID instruction
>> KVM: nVMX: nested VPID emulation
>> KVM: nVMX: expose VPID capability to L1
>>
>> arch/x86/include/asm/vmx.h | 1 +
>> arch/x86/kvm/vmx.c | 151
>> ++++++++++++++++++++++++++++++++++++---------
>> 2 files changed, 123 insertions(+), 29 deletions(-)
>>
>
Under test, will be committed to kvm/next soon.
Paolo
prev parent reply other threads:[~2015-10-16 13:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 16:12 [PATCH v3 0/5] KVM: nVMX: nested VPID emulation Wanpeng Li
2015-10-16 13:13 ` Wanpeng Li
2015-10-16 13:14 ` Paolo Bonzini [this message]
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=5620F83E.6000500@redhat.com \
--to=pbonzini@redhat.com \
--cc=bsd@redhat.com \
--cc=fanwenyi0529@gmail.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wanpeng.li@hotmail.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;
as well as URLs for NNTP newsgroup(s).