From patchwork Fri Jul 26 23:51:18 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 13743433 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E0E21C3DA49 for ; Fri, 26 Jul 2024 23:56:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Reply-To:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:Cc:To: From:Subject:Message-ID:References:Mime-Version:In-Reply-To:Date: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=fmU/HR7p0h2R7XRsIfqUXhH6E22vlxrvSMQX4VgE/mU=; b=a5UPjkGOgIjM9JC+ulhUcwPpw9 qVY6Jrx8714DYkQ4ImQ+8blu5M9lpBdqpzrxAVrcn9FdvUPyOnbhgEcC2werWZLA2owp5BihA+eAw VQvMegy0osG3etJgLschEiwTs82iFQ8EBw3Sk2DL5+e1VxkiXa87wz4BRwPmlmdHc8bZw3hee3Ntn LJCyjkvh+LbCoabOJeTuaqOVFoMC9CbADM5cPeMW5dMAThNGtSiMCXj/VWOrg26Y7Itl4qyd7FYuE jbc3BqN7MdoZfUC1SzoOst89UUVZoZOXWCqs5OHRvraayve/+oi6z0ZOxjJGf2/3prkSSipvJlg9d QS+CknqA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sXUnk-00000005S9v-3ibl; Fri, 26 Jul 2024 23:56:44 +0000 Received: from mail-yw1-x114a.google.com ([2607:f8b0:4864:20::114a]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sXUk5-00000005PJS-0wyf for linux-arm-kernel@lists.infradead.org; Fri, 26 Jul 2024 23:52:59 +0000 Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-66480c1a6b5so7085547b3.1 for ; Fri, 26 Jul 2024 16:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722037976; x=1722642776; 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=fmU/HR7p0h2R7XRsIfqUXhH6E22vlxrvSMQX4VgE/mU=; b=GVn8sOEUzxgznAvb9AiWU8gjhZyCq/rJ8VnBH0A8r009nlMVPGsiw9gETcgaWmhneM qa+UDOqXZ3G8wKRM8AHmFCZU7TCXKpyljFBP6TzS9csb8Vm2pWzcDa6mKqX8RZ+0K6En Sej/kQkfdSI36yBu3UsYXAHi53bm/yC5IEhmpZhA3D3VgRYDj2VoCbLCKQ9w5OBuTWr1 xd53j6HnYECQy3oirnWS0OhU/SfEVnHx4rl2WD/Hm6tSh3Y86JIge2aC7coOk57ne+xz pDqHP+I9Gao1yPIndBVu2Wi+C9zLKL6RrMw/UddMHq5whhSvd6QecVofVNacmbrFcHsR 9u3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722037976; x=1722642776; 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=fmU/HR7p0h2R7XRsIfqUXhH6E22vlxrvSMQX4VgE/mU=; b=jw5bm4+J9Nps38NBlVjTg5ZiovDjWOeAZ36FXUrqCjvjaKNBfADmDbuq3WyxK4u1bR S9oTBcYOPmsHPFGAWX8EzHKZsgu8dTZwqjQEE5/gzRFgEsuVmCrKNK+eq0qFRdb2cyh9 WGn8XC/2C0vwIEg+g5zvbXvmwYASaau+S3H6/SXK7voPo1ZViE1ESFxC1s9Mm+AfKagT Dai+XWEkrElGBObWxBKTGJG0Yc3dqwrj4dyXdaT3cfi0LotoS5EdP3hClmWP3KFMT5JI Pq+X3W3hmVltkOK7LxPRAeghFXwpZGoYVH0CAdtJUFSQGkx/Uw7NGg/TCCcS1lljQ8ca NVzw== X-Forwarded-Encrypted: i=1; AJvYcCVR0LDJ9HbaFf77NefD0aGBI3P9QlwPoGXoAHApvSdNzMT80JfCn9Ekl+oLI6oP7sn75v5eta4BqAG/5pLkV2yfGx/Umb26XpwyOlbc+GtDplJFs98= X-Gm-Message-State: AOJu0Yyd+5mEP9cfdI35QKixaO1fEAZsgU93C3YXXT2e+kQPaI5bf5uf RD47l3NuLazu53xq109H58Wt0O88HQwXFMjQJWiLQD6C+ivcpTT5Hpsy64LG4j9arHlY01yPHHz Rsw== X-Google-Smtp-Source: AGHT+IEZeCODu/YeM5d/iOhxGxPVHISuly+z8I6+5BlUeuWOyJE5t2wqwhMJ9ApQGl0yAUOujG/KjtPFVv0= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:ad14:0:b0:62f:f535:f41 with SMTP id 00721157ae682-67a0abd4d1fmr288247b3.9.1722037976008; Fri, 26 Jul 2024 16:52:56 -0700 (PDT) Date: Fri, 26 Jul 2024 16:51:18 -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-10-seanjc@google.com> Subject: [PATCH v12 09/84] KVM: x86/mmu: Don't force flush if SPTE update clears Accessed bit From: Sean Christopherson To: Paolo Bonzini , Marc Zyngier , Oliver Upton , Tianrui Zhao , Bibo Mao , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Sean Christopherson 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 , David Stevens X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240726_165257_472246_1A6D1678 X-CRM114-Status: GOOD ( 15.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Sean Christopherson Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Don't force a TLB flush if mmu_spte_update() clears Accessed bit, as access tracking tolerates false negatives, as evidenced by the mmu_notifier hooks that explicit test and age SPTEs without doing a TLB flush. In practice, this is very nearly a nop. spte_write_protect() and spte_clear_dirty() never clear the Accessed bit. make_spte() always sets the Accessed bit for !prefetch scenarios. FNAME(sync_spte) only sets SPTE if the protection bits are changing, i.e. if a flush will be needed regardless of the Accessed bits. And FNAME(pte_prefetch) sets SPTE if and only if the old SPTE is !PRESENT. That leaves kvm_arch_async_page_ready() as the one path that will generate a !ACCESSED SPTE *and* overwrite a PRESENT SPTE. And that's very arguably a bug, as clobbering a valid SPTE in that case is nonsensical. Signed-off-by: Sean Christopherson --- arch/x86/kvm/mmu/mmu.c | 31 +++++++++---------------------- 1 file changed, 9 insertions(+), 22 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 58b70328b20c..b7642f1f993f 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -518,37 +518,24 @@ static u64 mmu_spte_update_no_track(u64 *sptep, u64 new_spte) * TLBs must be flushed. Otherwise rmap_write_protect will find a read-only * spte, even though the writable spte might be cached on a CPU's TLB. * + * Remote TLBs also need to be flushed if the Dirty bit is cleared, as false + * negatives are not acceptable, e.g. if KVM is using D-bit based PML on VMX. + * + * Don't flush if the Accessed bit is cleared, as access tracking tolerates + * false negatives, and the one path that does care about TLB flushes, + * kvm_mmu_notifier_clear_flush_young(), uses mmu_spte_update_no_track(). + * * Returns true if the TLB needs to be flushed */ static bool mmu_spte_update(u64 *sptep, u64 new_spte) { - bool flush = false; u64 old_spte = mmu_spte_update_no_track(sptep, new_spte); if (!is_shadow_present_pte(old_spte)) return false; - /* - * For the spte updated out of mmu-lock is safe, since - * we always atomically update it, see the comments in - * spte_has_volatile_bits(). - */ - if (is_mmu_writable_spte(old_spte) && - !is_writable_pte(new_spte)) - flush = true; - - /* - * Flush TLB when accessed/dirty states are changed in the page tables, - * to guarantee consistency between TLB and page tables. - */ - - if (is_accessed_spte(old_spte) && !is_accessed_spte(new_spte)) - flush = true; - - if (is_dirty_spte(old_spte) && !is_dirty_spte(new_spte)) - flush = true; - - return flush; + return (is_mmu_writable_spte(old_spte) && !is_writable_pte(new_spte)) || + (is_dirty_spte(old_spte) && !is_dirty_spte(new_spte)); } /*