linux-kernel - [PATCH v2 0/7] KVM: x86/mmu: Zap only obsolete roots on "reload"

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

Date:   Fri, 25 Feb 2022 18:22:41 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Janosch Frank <frankja@...ux.ibm.com>
Cc:     David Hildenbrand <david@...hat.com>,
        Claudio Imbrenda <imbrenda@...ux.ibm.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Ben Gardon <bgardon@...gle.com>,
        Lai Jiangshan <jiangshanlai@...il.com>
Subject: [PATCH v2 0/7] KVM: x86/mmu: Zap only obsolete roots on "reload"

For all intents and purposes, this is an x86/mmu series, but it touches
s390 and common KVM code because KVM_REQ_MMU_RELOAD is currently a generic
request despite its use being encapsulated entirely within arch code.

The meat of the series is to zap only obsolete (a.k.a. invalid) roots in
response to KVM marking a root obsolete/invalid due to it being zapped.
KVM currently drops/zaps all roots, which, aside from being a performance
hit if the guest is using multiple roots, complicates x86 KVM paths that
load a new root because it raises the question of what should be done if
there's a pending KVM_REQ_MMU_RELOAD, i.e. if the path _knows_ that any
root it loads will be obliterated.

Paolo, I'm hoping you can squash patch 01 with your patch it "fixes".

I'm also speculating that this will be applied after my patch to remove
KVM_REQ_GPC_INVALIDATE, otherwise the changelog in patch 06 will be
wrong.

v2:
 - Collect reviews. [Claudio, Janosch]
 - Rebase to latest kvm/queue.

v1: https://lore.kernel.org/all/20211209060552.2956723-1-seanjc@google.com

Sean Christopherson (7):
  KVM: x86: Remove spurious whitespaces from kvm_post_set_cr4()
  KVM: x86: Invoke kvm_mmu_unload() directly on CR4.PCIDE change
  KVM: Drop kvm_reload_remote_mmus(), open code request in x86 users
  KVM: x86/mmu: Zap only obsolete roots if a root shadow page is zapped
  KVM: s390: Replace KVM_REQ_MMU_RELOAD usage with arch specific request
  KVM: Drop KVM_REQ_MMU_RELOAD and update vcpu-requests.rst
    documentation
  KVM: WARN if is_unsync_root() is called on a root without a shadow
    page

 Documentation/virt/kvm/vcpu-requests.rst |  7 +-
 arch/s390/include/asm/kvm_host.h         |  2 +
 arch/s390/kvm/kvm-s390.c                 |  8 +--
 arch/s390/kvm/kvm-s390.h                 |  2 +-
 arch/x86/include/asm/kvm_host.h          |  2 +
 arch/x86/kvm/mmu.h                       |  1 +
 arch/x86/kvm/mmu/mmu.c                   | 83 ++++++++++++++++++++----
 arch/x86/kvm/x86.c                       | 10 +--
 include/linux/kvm_host.h                 |  4 +-
 virt/kvm/kvm_main.c                      |  5 --
 10 files changed, 90 insertions(+), 34 deletions(-)


base-commit: f4bc051fc91ab9f1d5225d94e52d369ef58bec58
-- 
2.35.1.574.g5d30c73bfb-goog