Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp419420pxm; Fri, 25 Feb 2022 10:31:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJw2QVAiXf4FbJ2mgTH7LVtj1NvJmO//vM1JtJXHshWnN157hJt+Dw5SbW0sQSjpF+/zGeDg X-Received: by 2002:a17:90a:5915:b0:1bc:7c8e:4c93 with SMTP id k21-20020a17090a591500b001bc7c8e4c93mr4394421pji.152.1645813898674; Fri, 25 Feb 2022 10:31:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645813898; cv=none; d=google.com; s=arc-20160816; b=UbF6wq6uO22EbW0u3mb8b79/aCR110k7NEfUhIPQCev5ceguNKdRUX0nV/CuhvuFD4 tiDfIywUOlQsjiS9eDejSvWbsCSMsJF/lSE8JCN4n8l2x2h3Nscr5Qwfi+U/AYtdNM+y 9dCWLgrqFI3v8/7mgZZgDW351k2kcjjXpR7r8RThAugpUJIt6F7L/eDpRcoPpv+OoX4M HKVFAk3hmNjeRKomTdqKF/c00h8Jc92INioltHe7dr+0F/F/PQm21kzBESYpGcXnZxgZ 3LvdAKmVy/fOzP97omYBgS0vC6FehLu5160AJlnAUVF/aVAznMb1bKvG/f3PCFYWKAVq hWow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:mime-version:message-id:date :reply-to:dkim-signature; bh=x4Ku6YsMCKcusqhh1KEW7b8ua9qMmgZkvtpofAGbtVk=; b=Pe7h5QhxKwO9I+bNN3uNWo9+z9FkcyeBCeV11qrz7uAq74po1J9KvJp3GunSSReMr9 fe0mCkFyzcOZfObk4HzzCfdKQiQ1ejuht8uqTH3Bfd4sHpn5deA1i/MeOVRMEUDBurMU KJ+H9Dq/Ef9XXKhTV9GsQquusqbY7QeyyOssnnKhRiuuWCha22OIKo8RZR330LD+rr43 U3Bgw5SBUw1V6Ry05RxaiFiHv4wtx4OBkXAa8ZgwjWufVlI7cZPCQ9KOviil2SkhvJJd 9xJYPSbznwVRdvqhIkvH+eoXTB2CLxP1/855uNdmOzx8j6elrQ/vWBGvudR9P9vP8vWe 3D7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=RCy+rU96; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s7-20020a056a00178700b004f0f0f8529esi1166967pfg.72.2022.02.25.10.30.58; Fri, 25 Feb 2022 10:31:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=RCy+rU96; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232291AbiBYSX1 (ORCPT + 99 others); Fri, 25 Feb 2022 13:23:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38328 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231986AbiBYSXX (ORCPT ); Fri, 25 Feb 2022 13:23:23 -0500 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A2306E8CE for ; Fri, 25 Feb 2022 10:22:51 -0800 (PST) Received: by mail-pg1-x549.google.com with SMTP id o30-20020a634e5e000000b00373598b71d4so3034117pgl.21 for ; Fri, 25 Feb 2022 10:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=reply-to:date:message-id:mime-version:subject:from:to:cc; bh=x4Ku6YsMCKcusqhh1KEW7b8ua9qMmgZkvtpofAGbtVk=; b=RCy+rU96VujgIkYwHn+eJ5lO3hg6B5rvgAVjzyr0MvZ1ZAAaC6UXB+cPjHj469kxNY Dw/RtxHGBJYxtWSp0N+MA+FQg+U8eFE+C4uFNuV2LgxD+q84FNZsyaJANm2VwbaQlVFy gqjB10qjYVDsTOnCB+tre7f3ppLBqcZQMoQOO77NG0G9ZEAKYrAZsvPopKEjUHud6Eji j/4KlnmP+APgnEEeVFGEXmR+Jcxr3wj5lkdTlcY5lHXhtB4cvoq6WeNbwbMDKQRf7sFj AleA+MFbDA9x+F044WEpWtsjE+yir3y5MtRaHwORbGb+qEIqd3DdTJltzhXYaAsN6Yog hQAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:reply-to:date:message-id:mime-version:subject :from:to:cc; bh=x4Ku6YsMCKcusqhh1KEW7b8ua9qMmgZkvtpofAGbtVk=; b=DAukuLDrgxHDa4eeZxN1MUgS2lMfLzYxs9izLYOEer+7DbXYar5gIm2ViM56vIw6f6 orcIs3mVAzRiteuE6XEz1BVRmlcvTm/eEvzRq2JT/i4S6CO+jFpA08hVSzrX/cI9ojj4 mQhUGa3X2ypBs20CFTRTBajXRQAH13d/GZ15a/3PRk6VkvBQthLgcefzrM0snrVsVMVn UPeVF9MYdlp3fYw/p24ALLqip16QIXZBNf/1BwkFsUpXLhR7cyU84N1aRHI/o41zZpuB aO9EOV341qVSV76fDa5nYY7GyNpHXXFvl6KnPys/NN4QuHrjGHl2EkNrPphOnt36//o3 Lyyw== X-Gm-Message-State: AOAM5313t1bntaTBIqpp/PQ/1HeflRW9MuMe8+LjGHwKB+/SeIBMn0X1 9U4V7pMx9mXkiRgLc91hZRejtQL/pj8= X-Received: from seanjc.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:3e5]) (user=seanjc job=sendgmr) by 2002:a17:90b:4f43:b0:1bc:7e5c:e024 with SMTP id pj3-20020a17090b4f4300b001bc7e5ce024mr26588pjb.0.1645813370236; Fri, 25 Feb 2022 10:22:50 -0800 (PST) Reply-To: Sean Christopherson Date: Fri, 25 Feb 2022 18:22:41 +0000 Message-Id: <20220225182248.3812651-1-seanjc@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.35.1.574.g5d30c73bfb-goog Subject: [PATCH v2 0/7] KVM: x86/mmu: Zap only obsolete roots on "reload" From: Sean Christopherson To: Paolo Bonzini , Christian Borntraeger , Janosch Frank Cc: David Hildenbrand , Claudio Imbrenda , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Ben Gardon , Lai Jiangshan Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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