Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp5962931rwd; Mon, 5 Jun 2023 10:52:37 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6xjoXXt9D1D7GzgViE33rd7wHFuRLTt+Gq5VjRpRKuZ6P6i6GiDOAcFj+bg/nnqFkrBGKI X-Received: by 2002:a05:6a00:1354:b0:64d:46b2:9a58 with SMTP id k20-20020a056a00135400b0064d46b29a58mr496316pfu.26.1685987557599; Mon, 05 Jun 2023 10:52:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685987557; cv=none; d=google.com; s=arc-20160816; b=DhDoD7zvnLq8rP4tfqvUQxk4XSbPH2+WRPghaWYoPcgljglG0183DTLYO/1McRgBaP Ii6auv11GoHDpY0eiab7z4mlbTNCVfdJxhL8M2HbrSTd1K9lGWVB1eKPisi/S8pRrzbn mMWLlhBlp8dTHPb3Yam7/OU6U1d60OsNJrxpE0yyvTS1ALcvmu0j8YAgOnjZmr7k/djs rPUEGsWNxqttwgxvMj0BRlcaKZkICiQiwsPgPqv+IjBmu2QGEuuqYbQQJlqgzAwoSEVX nvlERAb0GhNAt7FWPIXTlm1y/AvU5jXoO2QccoooqZgVkzx3jrEhf9pbikZwnXRL0xe9 CWXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=PW3P1vIM2WDTsRDVeenwIcNSQa/MZz4KHGZSoIx2p84=; b=XWYHRZTrWFM8aRCp58CI7adNkzg2r42jO3HegOqj2jU4IJHeq+0ruQfO5PZ20vXsNU TM8CxLgMeRR9GNiH6XuWj3OByepPy0pqCnfTb+px9ne1X6w3F3VSzRYK0CKmErffEVvq 7W2PtH8UR4fwrthSXC2ME/0Mtz4B9nojfLU3MQIjaBYxyShVhykzAnQceIDdVqwhLX95 xXGhQeEYr/aPy0Vnxt0mhHng/yzFCyS89+RaZBAfaOQqCRUEaaGMZcS8CobcH7O8YwwR uJajTRiPlfaYC0Gf5S5YpFgv6DWcYbM8oe/SlKPk3D9bfBVICQuneZ21fLZck8pL4XGy laGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=1klBAYVV; 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 g2-20020aa796a2000000b0065dba8cc3a6si938556pfk.376.2023.06.05.10.52.19; Mon, 05 Jun 2023 10:52:37 -0700 (PDT) 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=20221208 header.b=1klBAYVV; 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 S234931AbjFERRn (ORCPT + 99 others); Mon, 5 Jun 2023 13:17:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42714 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234541AbjFERRl (ORCPT ); Mon, 5 Jun 2023 13:17:41 -0400 Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ECB10A6 for ; Mon, 5 Jun 2023 10:17:39 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id d75a77b69052e-3f98276f89cso7511cf.1 for ; Mon, 05 Jun 2023 10:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1685985459; x=1688577459; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PW3P1vIM2WDTsRDVeenwIcNSQa/MZz4KHGZSoIx2p84=; b=1klBAYVVSmnvd11O+TpDJXrRcQnLLHSmd9MixU4CSWvozFm9aWcwlRRSCgOVtUXY5E 1i8h/a8gA0km1btECjApb90WEM1GeISM5/eRt/OMBwg+seF+TDmzaZ+MPRj57G8ihvTP TYlPgB+ZKcywuhQdwZJnuGcozC6tnAUvHlK0LwPijfDV7wWxeIkfM5CDyKDxFxbFhJ1O tgNTxPnl0CIN2mfWySwjXh5azIs4zL8CWDArg1MHlY1djlec5894mdHKhFq/nFFEnl/u YQ6xIew+ANpcjREwWueUOLpU2XpMboZNLXeIOSw0ISr6f1ZMh9hImY1IxbedySxbmbPV JHzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685985459; x=1688577459; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PW3P1vIM2WDTsRDVeenwIcNSQa/MZz4KHGZSoIx2p84=; b=L6msueswQuIJHY1Juov3/UTTiKh0uX4m7K/J7Yl6iUBIMRGaMbKSV+3RbubC5qwF9w kEmpkwUz9OvhpfAZem1VoRBJpJGrcshqmhkVUxIAwEKUJROc1t0wh2w0y1eDuEw1GrjT DxcbqnunHkST6QCqsakEHsN1ANtfGXwHcgHsiw08BoVWTT48zou50tX2qtyYgwHd7/M6 JAS0CP7EyVZrXvKuKCQbkD/zMIxAgw5FKUWtgrpjnD38rtONvqyCChiZ77JsEn40s2VP BuW8l7I8/F7CWhKu24MBqA+z1QtTypcuefAfyPw9rqGbWbiZkwYFoCNpekYbH9gT4gSK 7wog== X-Gm-Message-State: AC+VfDzOYYGzNMXalwvU/qSnT4nAIoAiOqxkm2ZQJ684hS0DLktRSZBb +/Oeeae8si7VJsxD0gEMyeRMGGBTXaBOkFBImTLvxQ== X-Received: by 2002:ac8:58cf:0:b0:3f8:5b2:aeee with SMTP id u15-20020ac858cf000000b003f805b2aeeemr721497qta.22.1685985458926; Mon, 05 Jun 2023 10:17:38 -0700 (PDT) MIME-Version: 1.0 References: <20230605004334.1930091-1-mizhang@google.com> In-Reply-To: From: Ben Gardon Date: Mon, 5 Jun 2023 10:17:27 -0700 Message-ID: Subject: Re: [PATCH] KVM: x86/mmu: Remove KVM MMU write lock when accessing indirect_shadow_pages To: Jim Mattson Cc: Mingwei Zhang , Sean Christopherson , Paolo Bonzini , "H. Peter Anvin" , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_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 On Mon, Jun 5, 2023 at 9:55=E2=80=AFAM Jim Mattson wr= ote: > > On Sun, Jun 4, 2023 at 5:43=E2=80=AFPM Mingwei Zhang = wrote: > > > > Remove KVM MMU write lock when accessing indirect_shadow_pages counter = when > > page role is direct because this counter value is used as a coarse-grai= ned > > heuristics to check if there is nested guest active. Racing with this > > heuristics without mmu lock will be harmless because the corresponding > > indirect shadow sptes for the GPA will either be zapped by this thread = or > > some other thread who has previously zapped all indirect shadow pages a= nd > > makes the value to 0. > > > > Because of that, remove the KVM MMU write lock pair to potentially redu= ce > > the lock contension and improve the performance of nested VM. In additi= on > > opportunistically change the comment of 'direct mmu' to make the > > description consistent with other places. > > > > Reported-by: Jim Mattson > > Signed-off-by: Mingwei Zhang > > --- > > arch/x86/kvm/x86.c | 10 ++-------- > > 1 file changed, 2 insertions(+), 8 deletions(-) > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > index 5ad55ef71433..97cfa5a00ff2 100644 > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -8585,15 +8585,9 @@ static bool reexecute_instruction(struct kvm_vcp= u *vcpu, gpa_t cr2_or_gpa, > > > > kvm_release_pfn_clean(pfn); > > > > - /* The instructions are well-emulated on direct mmu. */ > > + /* The instructions are well-emulated on Direct MMUs. */ Nit: Internally within Google, on older kernels, we have the "Direct MMU" which was the precursor to the TDP MMU we all know and love. This comment however does not refer to the Direct MMU. Direct here just refers to the direct role bit being set. Since it's just descriptive, direct should not be capitalized in this comment, so no reason to change this line. > > if (vcpu->arch.mmu->root_role.direct) { > > - unsigned int indirect_shadow_pages; > > - > > - write_lock(&vcpu->kvm->mmu_lock); > > - indirect_shadow_pages =3D vcpu->kvm->arch.indirect_shad= ow_pages; > > - write_unlock(&vcpu->kvm->mmu_lock); > > - > > - if (indirect_shadow_pages) > > + if (READ_ONCE(vcpu->kvm->arch.indirect_shadow_pages)) > > I don't understand the need for READ_ONCE() here. That implies that > there is something tricky going on, and I don't think that's the case. Agree this doesn't need a READ_ONCE. Just a read is fine. kvm_mmu_unprotect_page starts by acquiring the MMU lock, so there's not much room to reorder anything anyway. Thanks for sending a patch to fix this. The critical section of the MMU lock here is small, but any lock acquisition in write mode can mess up performance of otherwise happy read-mode uses. > > > kvm_mmu_unprotect_page(vcpu->kvm, gpa_to_gfn(gp= a)); > > > > return true; > > > > base-commit: 31b4fc3bc64aadd660c5bfa5178c86a7ba61e0f7 > > -- > > 2.41.0.rc0.172.g3f132b7071-goog > >