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
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
