linux-kernel - Re: [RFC 0/6] Enlightened VMCS support for KVM on Hyper-V

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 16 Jan 2018 09:21:04 +0800
From:   Wanpeng Li <kernellwp@...il.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     kvm <kvm@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        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>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/6] Enlightened VMCS support for KVM on Hyper-V

2018-01-16 1:30 GMT+08:00 Vitaly Kuznetsov <vkuznets@...hat.com>:
> Early RFC. I'll refer to this patchset in my DevConf/FOSDEM
> presentations.
>
> When running nested KVM on Hyper-V it's possible to use so called
> 'Enlightened VMCS' and do normal memory reads/writes instead of
> doing VMWRITE/VMREAD instructions. Tests show that this speeds up
> tight CPUID loop almost 3 times:
>
> Before:
> ./cpuid_tight
> 20459
>
> After:
> ./cpuid_tight
> 7698

Maybe you can apply a similar idea to kvm nested on kvm.

Regards,
Wanpeng Li

>
> checkpatch.pl errors/warnings and possible 32bit brokenness are known
> things.
>
> Main RFC questions I have are:
> - Do we want to have this per L2 VM or per L1 host?
> - How can we achieve zero overhead for non-Hyper-V deployments? Use static
>   keys? But this will only work if we decide to do eVMCS per host.
> - Can we do better than a big switch in evmcs_read()/evmcs_write()? And
>   probably don't use 'case' defines which checkpatch.pl hates.
>
> I would really apreciate any feedback!
>
> Ladi Prosek (1):
>   x86/kvm: rename HV_X64_MSR_APIC_ASSIST_PAGE to
>     HV_X64_MSR_VP_ASSIST_PAGE
>
> Vitaly Kuznetsov (5):
>   x86/hyper-v: define virtual processor assist page structure
>   x86/hyper-v: allocate and use hv_vp_assist_pages
>   x86/hyper-v: define struct hv_enlightened_vmcs and clean field bits
>   x86/hyper-v: detect nested features
>   x86/kvm: use enlightened VMCS when running on Hyper-V
>
>  arch/x86/hyperv/hv_init.c          |  35 ++-
>  arch/x86/include/asm/mshyperv.h    |   3 +
>  arch/x86/include/uapi/asm/hyperv.h | 223 +++++++++++++-
>  arch/x86/kernel/cpu/mshyperv.c     |   3 +
>  arch/x86/kvm/hyperv.c              |   8 +-
>  arch/x86/kvm/lapic.h               |   2 +-
>  arch/x86/kvm/vmx.c                 | 595 ++++++++++++++++++++++++++++++++++++-
>  arch/x86/kvm/x86.c                 |   2 +-
>  8 files changed, 857 insertions(+), 14 deletions(-)
>
> --
> 2.14.3
>