linux-kernel - Re: [PATCH RFC 0/7] KVM: nVMX: enlightened VMCS initial implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87lghww235.fsf@vitty.brq.redhat.com>
Date:   Thu, 21 Dec 2017 16:08:30 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     Paolo Bonzini <pbonzini@...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

Paolo Bonzini <pbonzini@...hat.com> 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