linux-kernel - Re: [PATCH rebase/RFC 0/4] x86/kvm/nVMX: optimize MMU switch between L1 and L2

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: <4eb9e84b-c159-3e26-7a91-df2cecd72a9b@redhat.com>
Date:   Tue, 31 Jul 2018 18:52:28 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH rebase/RFC 0/4] x86/kvm/nVMX: optimize MMU switch between
 L1 and L2

On 31/07/2018 17:58, Vitaly Kuznetsov wrote:
> Thank you for the rebase,
> 
> it seems that with multi-root caching this series should just ignore CR3
> changes for both root_mmu and guest_mmu: we now have two separate
> 'prev_roots' caches and these work well. However, we still can optimize
> MMU re-initialization on L1->L2 and L2->L1 switches out using e.g. my
> 'scache' idea (which can be orthogonal to page_role check on CR3).

Indeed, though if possible the scache should be based on the role to
avoid duplicating code and data structures.

(Also I didn't quite have time to figure out _why_ without
root_mmu/guest_mmu there is still contention, it's probably something
trivial).

Paolo

> In my Hyper-V-on-KVM environment I'm seeing an additional 1000 CPU
> cycles win for a nested vmexit.
> 
> I'll pull things together and re-send the whole series.