[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c5c1357d-c36a-38bf-6148-8ffb89a0290b@redhat.com>
Date: Thu, 21 Dec 2017 15:32:14 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>
Cc: kvm@...r.kernel.org, x86@...nel.org,
Radim Krčmář <rkrcmar@...hat.com>,
"K. Y. Srinivasan" <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
"Michael Kelley (EOSG)" <Michael.H.Kelley@...rosoft.com>,
Mohammed Gamal <mmorsy@...hat.com>,
Cathy Avery <cavery@...hat.com>, Bandan Das <bsd@...hat.com>,
Roman Kagan <rkagan@...tuozzo.com>,
linux-kernel@...r.kernel.org, devel@...uxdriverproject.org
Subject: Re: [PATCH RFC 0/7] KVM: nVMX: enlightened VMCS initial
implementation
On 21/12/2017 13:50, Vitaly Kuznetsov wrote:
> I'm back with (somewhat frustrating) results (E5-2603):
v4 (that would be Broadwell)?
> 1) Windows on Hyper-V (no nesting): 1350 cycles
>
> 2) Windows on Hyper-V on Hyper-V: 8600
>
> 3) Windows on KVM (no nesting): 1150 cycles
>
> 4) Windows on Hyper-V on KVM (no enlightened VMCS): 18200
>
> 5) Windows on Hyper-V on KVM (enlightened VMCS): 17100
What version were you using for KVM? There are quite a few nested virt
optimizations in kvm/queue (which may make enlightened VMCS both more or
less efficient).
In particular, with latest kvm/queue you could try tracing vmread and
vmwrite vmexits, and see if you get any. If you do, that might be an
easy few hundred cycles savings.
Paolo
Powered by blists - more mailing lists