kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).