linux-kernel - [PATCH RFC 00/19] KVM: x86: hyper-v: Fine-grained TLB flush + Direct TLB flush feature

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 for Android: free password hash cracker in your pocket

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

Date:   Mon,  7 Mar 2022 15:50:04 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     kvm@...r.kernel.org
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        linux-hyperv@...r.kernel.org,
        Siddharth Chandrasekaran <sidcha@...zon.de>,
        linux-kernel@...r.kernel.org
Subject: [PATCH RFC 00/19] KVM: x86: hyper-v: Fine-grained TLB flush + Direct TLB flush feature

Currently, KVM handles HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST{,EX} requests
by flushing the whole VPID and this is sub-optimal. This series introduces
the required mechanism to make handling of these requests more 
fine-grained by flushing individual GVAs only (when requested). On this
foundation, "Direct Virtual Flush" Hyper-V feature is implemented. The 
feature allows L0 to handle Hyper-V TLB flush hypercalls directly at
L0 without the need to reflect the exit to L1. This has at least two
benefits: reflecting vmexit and the consequent vmenter are avoided + L0
has precise information whether the target vCPU is actually running (and
thus requires a kick).

RFC part:
- The series is poorly tested. I've only smoke-tested WS2019 and Win11+WSL2
on VMX and AMD harware to the point that no immediate issues are observed
on boot. We certainly need something added to selftests/kvm-unit-tests.

Vitaly Kuznetsov (19):
  KVM: x86: hyper-v: Resurrect dedicated KVM_REQ_HV_TLB_FLUSH flag
  KVM: x86: hyper-v: Introduce TLB flush ring
  KVM: x86: hyper-v: Handle HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST{,EX} calls
    gently
  KVM: x86: hyper-v: Expose support for extended gva ranges for flush
    hypercalls
  KVM: x86: Prepare kvm_hv_flush_tlb() to handle L2's GPAs
  KVM: x86: hyper-v: Don't use sparse_set_to_vcpu_mask() in
    kvm_hv_send_ipi()
  KVM: x86: hyper-v: Create a separate ring for Direct TLB flush
  KVM: x86: hyper-v: Use preallocated buffer in 'struct kvm_vcpu_hv'
    instead of on-stack 'sparse_banks'
  KVM: nVMX: Keep track of hv_vm_id/hv_vp_id when eVMCS is in use
  KVM: nSVM: Keep track of Hyper-V hv_vm_id/hv_vp_id
  KVM: x86: Introduce .post_hv_direct_flush() nested hook
  KVM: x86: hyper-v: Introduce kvm_hv_is_tlb_flush_hcall()
  KVM: x86: hyper-v: Direct TLB flush
  KVM: x86: hyper-v: Introduce fast kvm_hv_direct_tlb_flush_exposed()
    check
  x86/hyperv: Fix 'struct hv_enlightened_vmcs' definition
  KVM: nVMX: hyper-v: Direct TLB flush
  KVM: x86: KVM_REQ_TLB_FLUSH_CURRENT is a superset of
    KVM_REQ_HV_TLB_FLUSH too
  KVM: nSVM: hyper-v: Direct TLB flush
  KVM: x86: Expose Hyper-V Direct TLB flush feature

 arch/x86/include/asm/hyperv-tlfs.h |   6 +-
 arch/x86/include/asm/kvm_host.h    |  30 +++
 arch/x86/kvm/Makefile              |   3 +-
 arch/x86/kvm/hyperv.c              | 305 ++++++++++++++++++++++++++---
 arch/x86/kvm/hyperv.h              |  55 ++++++
 arch/x86/kvm/svm/hyperv.c          |  18 ++
 arch/x86/kvm/svm/hyperv.h          |  37 ++++
 arch/x86/kvm/svm/nested.c          |  25 ++-
 arch/x86/kvm/trace.h               |  21 +-
 arch/x86/kvm/vmx/evmcs.c           |  24 +++
 arch/x86/kvm/vmx/evmcs.h           |   4 +
 arch/x86/kvm/vmx/nested.c          |  41 +++-
 arch/x86/kvm/x86.c                 |  15 +-
 arch/x86/kvm/x86.h                 |   1 +
 14 files changed, 539 insertions(+), 46 deletions(-)
 create mode 100644 arch/x86/kvm/svm/hyperv.c

-- 
2.35.1