Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753185AbdLUPIo (ORCPT ); Thu, 21 Dec 2017 10:08:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47244 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753069AbdLUPIi (ORCPT ); Thu, 21 Dec 2017 10:08:38 -0500 From: Vitaly Kuznetsov To: Paolo Bonzini Cc: kvm@vger.kernel.org, x86@kernel.org, Radim =?utf-8?B?S3LEjW3DocWZ?= , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , "Michael Kelley \(EOSG\)" , Mohammed Gamal , Cathy Avery , Bandan Das , Roman Kagan , linux-kernel@vger.kernel.org, devel@linuxdriverproject.org Subject: Re: [PATCH RFC 0/7] KVM: nVMX: enlightened VMCS initial implementation References: <20171218171742.5765-1-vkuznets@redhat.com> <87po7alupo.fsf@vitty.brq.redhat.com> <87vah0w8h9.fsf@vitty.brq.redhat.com> Date: Thu, 21 Dec 2017 16:08:30 +0100 In-Reply-To: (Paolo Bonzini's message of "Thu, 21 Dec 2017 15:32:14 +0100") Message-ID: <87lghww235.fsf@vitty.brq.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 21 Dec 2017 15:08:38 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 985 Lines: 35 Paolo Bonzini writes: > On 21/12/2017 13:50, Vitaly Kuznetsov wrote: >> I'm back with (somewhat frustrating) results (E5-2603): > > v4 (that would be Broadwell)? > Sorry, v3, actually. Haswell. (the first one supporting vmcs shadowing afaiu). >> 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). This is kvm/queue and I rebased enlightened VMCS patches to it. > > 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. Will do. -- Vitaly