Message ID | 20240726235234.228822-7-seanjc@google.com |
---|---|
State | New |
Headers | show
Return-Path: <kvm-riscv-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org> X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=HvssRnXd; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=Zv2y5TGB; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.infradead.org (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org; envelope-from=kvm-riscv-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=patchwork.ozlabs.org) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4WW4Q02Y18z1ybY for <incoming@patchwork.ozlabs.org>; Sat, 27 Jul 2024 09:55:36 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:Reply-To:List-Subscribe:List-Help: List-Post:List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID :References:Mime-Version:In-Reply-To:Date:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=oQKlaP/EGN5W27RW+xtp+UBaEkf0xc3ADWEHA3YwZeQ=; b=HvssRnXd9p6Bi5 h3Hqxp486VK1ajeH5/60Rg6dDYH+a7pGFV6TT7YxuaMwtkkhPVDNF4u1+d4+eCm0sgHw4b0kRu3GU d+UC3wop6TMwQ4yBVAi5SmM1/q6Uxrg8p2gr2z1J1K8oSYKkabsOP+FTbtmjREVd9MpNDTGn5cMpD ytmNekwhfWt3eijyD0Bq7/7D20M6fa7HnYSdbE8GNIwauQt2pDhnzG9W0+6zV+1tIBWJ8JWcOlIcF ycK2n+cqf9Rd+N81LRjQrW7OKR4cYu3I/2ZWHe5jMSmBcH5GsauGJZLXDSrSdY3erw3yY5WmAuGoj 10kOcTa1/qg3jHiCycxw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sXUmc-00000005RZZ-2zHI; Fri, 26 Jul 2024 23:55:34 +0000 Received: from mail-yw1-x1149.google.com ([2607:f8b0:4864:20::1149]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sXUjz-00000005PEo-2p0v for kvm-riscv@lists.infradead.org; Fri, 26 Jul 2024 23:52:53 +0000 Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-650b621f4cdso5677737b3.1 for <kvm-riscv@lists.infradead.org>; Fri, 26 Jul 2024 16:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722037970; x=1722642770; darn=lists.infradead.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:from:to:cc:subject:date:message-id:reply-to; bh=VnEAHRC1zG591I39OowzIjQNXTqQsRDXyh/rUn6sicQ=; b=Zv2y5TGBu4jNjYjDqYMpQ7ctqA0RMqIRWZC1+t8BWrFI4iRKunriZE25YMEHTn5JN6 3Mp1PzUU2/0hJSPDCCgx4sx6PhAFzeCrSkf3hvV4Zaq78s0DPV7TJv34rhVCVpaHb62M r24KMJq7BXh0RbOeXcYCAAYdIwmgkOhouuTXfZM0vzugLZteTUFPOf1901Q17cSB2p+u qjVxn5ZS2KnY3PjEw2/oqb4IXElFT84/rvXh3DKfIDh/bwbck2zqTepCGKgY7XB6BZgJ pi85lCwbKL/Ajhlkj7OwnOyeCrqP10BMBchVSody8iZKmohVCSLhssfe9MTEC/YRdwor /Y1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722037970; x=1722642770; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:reply-to:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VnEAHRC1zG591I39OowzIjQNXTqQsRDXyh/rUn6sicQ=; b=CsFN7y7qk5g0YUdN4Pg3UB3qIPM8/8PP7wdi2owISr48Uv7jWBs9nOiAXq0K6HnzaM Bg3NX3x98rGmKT6srrQ1e2YS6AQvx0G8O9QqYpbDExsX8Cae7oaGoyMTsrEwxDi8jVps G0sYbvdlRFspN6uygwgygruddPja1ykQwTNHN38oz3PRC4yi+h/9QqdLoPu0JfRMTQdB +9jAPCm1kXWeVyhQn7qewK3syW8MSjd68Lgly3nB1CrMc9ONyUV9o5StNDFnTrAqtkur OVXAbz0DPH1iPNl1sxFII9hn4ZN/IZO0Td22OLq/zZatE1VUvqRxO6s0vzsjv8ggwTc3 I4Mg== X-Forwarded-Encrypted: i=1; AJvYcCWZpgm5R1dvHw/H9eUGgrog7d/No4b+Xgow1t1HV1wNtBDQsrepZvdXYNHdMJuc5wICNbzovcf9P/4cPc5ih7E1yVNOR0z+VideuLWLkA== X-Gm-Message-State: AOJu0YzpgtEvdDfUZEyNbper90WRdgvN1TMv5wuwWw4AdNYOoTYA1Mwn BFc2LqjPvY8d7SpWdAQ/4oUeWW82l2TiZASwx9MV3Bexuq0jMer/AjGH8hFpwoPtuh0oaAVAYbO 9kA== X-Google-Smtp-Source: AGHT+IFPOoUYsYyJmRjA25F0UYC9yeYKs61mDA/QqS/vgTcAgpqjjzQfUfGqPl0MU2c7vZElDBuLLOtKUts= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:690c:fc9:b0:648:afcb:a7ce with SMTP id 00721157ae682-67a05a9d90bmr269367b3.3.1722037969718; Fri, 26 Jul 2024 16:52:49 -0700 (PDT) Date: Fri, 26 Jul 2024 16:51:15 -0700 In-Reply-To: <20240726235234.228822-1-seanjc@google.com> Mime-Version: 1.0 References: <20240726235234.228822-1-seanjc@google.com> X-Mailer: git-send-email 2.46.0.rc1.232.g9752f9e123-goog Message-ID: <20240726235234.228822-7-seanjc@google.com> Subject: [PATCH v12 06/84] KVM: x86/mmu: Skip the "try unsync" path iff the old SPTE was a leaf SPTE From: Sean Christopherson <seanjc@google.com> To: Paolo Bonzini <pbonzini@redhat.com>, Marc Zyngier <maz@kernel.org>, Oliver Upton <oliver.upton@linux.dev>, Tianrui Zhao <zhaotianrui@loongson.cn>, Bibo Mao <maobibo@loongson.cn>, Huacai Chen <chenhuacai@kernel.org>, Michael Ellerman <mpe@ellerman.id.au>, Anup Patel <anup@brainfault.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Christian Borntraeger <borntraeger@linux.ibm.com>, Janosch Frank <frankja@linux.ibm.com>, Claudio Imbrenda <imbrenda@linux.ibm.com>, Sean Christopherson <seanjc@google.com> Cc: kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, David Matlack <dmatlack@google.com>, David Stevens <stevensd@chromium.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240726_165251_769563_793D355E X-CRM114-Status: GOOD ( 12.93 ) X-Spam-Score: -9.5 (---------) X-Spam-Report: Spam detection software, running on the system "bombadil.infradead.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Apply make_spte()'s optimization to skip trying to unsync shadow pages if and only if the old SPTE was a leaf SPTE, as non-leaf SPTEs in direct MMUs are always writable, i.e. could trigger a false pos [...] Content analysis details: (-9.5 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:1149 listed in] [list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record -7.5 USER_IN_DEF_DKIM_WL From: address is in the default DKIM welcome-list 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.0 DKIMWL_WL_MED DKIMwl.org - Medium trust sender X-BeenThere: kvm-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: <kvm-riscv.lists.infradead.org> List-Unsubscribe: <http://lists.infradead.org/mailman/options/kvm-riscv>, <mailto:kvm-riscv-request@lists.infradead.org?subject=unsubscribe> List-Archive: <http://lists.infradead.org/pipermail/kvm-riscv/> List-Post: <mailto:kvm-riscv@lists.infradead.org> List-Help: <mailto:kvm-riscv-request@lists.infradead.org?subject=help> List-Subscribe: <http://lists.infradead.org/mailman/listinfo/kvm-riscv>, <mailto:kvm-riscv-request@lists.infradead.org?subject=subscribe> Reply-To: Sean Christopherson <seanjc@google.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kvm-riscv" <kvm-riscv-bounces@lists.infradead.org> Errors-To: kvm-riscv-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org |
Series |
KVM: Stop grabbing references to PFNMAP'd pages
|
expand
|
diff --git a/arch/x86/kvm/mmu/spte.c b/arch/x86/kvm/mmu/spte.c index d4527965e48c..a3baf0cadbee 100644 --- a/arch/x86/kvm/mmu/spte.c +++ b/arch/x86/kvm/mmu/spte.c @@ -226,12 +226,20 @@ bool make_spte(struct kvm_vcpu *vcpu, struct kvm_mmu_page *sp, spte |= PT_WRITABLE_MASK | shadow_mmu_writable_mask; /* - * Optimization: for pte sync, if spte was writable the hash - * lookup is unnecessary (and expensive). Write protection - * is responsibility of kvm_mmu_get_page / kvm_mmu_sync_roots. - * Same reasoning can be applied to dirty page accounting. + * When overwriting an existing leaf SPTE, and the old SPTE was + * writable, skip trying to unsync shadow pages as any relevant + * shadow pages must already be unsync, i.e. the hash lookup is + * unnecessary (and expensive). + * + * The same reasoning applies to dirty page/folio accounting; + * KVM will mark the folio dirty using the old SPTE, thus + * there's no need to immediately mark the new SPTE as dirty. + * + * Note, both cases rely on KVM not changing PFNs without first + * zapping the old SPTE, which is guaranteed by both the shadow + * MMU and the TDP MMU. */ - if (is_writable_pte(old_spte)) + if (is_last_spte(old_spte, level) && is_writable_pte(old_spte)) goto out; /*
Apply make_spte()'s optimization to skip trying to unsync shadow pages if and only if the old SPTE was a leaf SPTE, as non-leaf SPTEs in direct MMUs are always writable, i.e. could trigger a false positive and incorrectly lead to KVM creating a SPTE without write-protecting or marking shadow pages unsync. This bug only affects the TDP MMU, as the shadow MMU only overwrites a shadow-present SPTE when synchronizing SPTEs (and only 4KiB SPTEs can be unsync). Specifically, mmu_set_spte() drops any non-leaf SPTEs *before* calling make_spte(), whereas the TDP MMU can do a direct replacement of a page table with the leaf SPTE. Opportunistically update the comment to explain why skipping the unsync stuff is safe, as opposed to simply saying "it's someone else's problem". Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> --- arch/x86/kvm/mmu/spte.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-)