From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B94BA331230 for ; Thu, 5 Feb 2026 23:06:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770332816; cv=none; b=QINWJ2yr8J2HSv2qAdRo4AnOCoFqKtUKdO4QgqIC80E+tn0dXugX61bV7VsmObVsr+ksTHcRAPcFXQHcFb7TII8zZJNk9XqcEYRkKpekR2ACSAAbj7dLwwuMgKOYsp2R456+9/1aZeMMu/P+3bNRxi95btIuGqogjTR+YJeDkLc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770332816; c=relaxed/simple; bh=aihXvScW7k3bgdhqYtkiUVksAxCiMXO+pCvT8/8TTSc=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=nkdlgq11zNdoE7HWZKgtp9g/XxtK6Hfslha9YJdnxnsQEoXFc7zCSZXjbaM9G+zSmMpg6Yd0Io3gd6cmVM720Y/Io61jnHR1BJCkBUaJ4Fh//7pOZ+nnmB35YALUEy7zXXSe2jfv0WPkwXRO4kzDhrlbpr/nPwB0nL7SLl/wgr8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=QjhdXP3e; arc=none smtp.client-ip=209.85.215.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="QjhdXP3e" Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-b5edecdf94eso3701380a12.2 for ; Thu, 05 Feb 2026 15:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770332816; x=1770937616; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=L8LUQCh61biJeu6NLvqdju68dTm4Qnz97N7lSr/nZdA=; b=QjhdXP3eqe7sXo7u+Tusbom4FZ/EQ8Ht+NG9CJ6At8miGgHk86bPsUPZ5F2mYgZiuz pHZVs5ffKRdd9CkFkfYtk+bSzEC+AgIjrmoY2owT9Icpd6/s61ZUwSz6e2g42mz/kuaA ehT0Fiia4TF0K9W1WZoIVSD85XSGM/aOvQzJ/2TcKteDp/1jFwgkwscC0EQdOQ4EJ5H8 L2XdTFloXe9wITiF2WTZA9aA2vbtXhOYWE5YPqZn09npCIybPXsx5L2saUFTNURRiFVg RHGAtL/2E0shXVihvCzLBBz3ujn6TxGglxGM3I6V/kW+IPyaISqYSS/pNYceqZGp/SAF 0Mnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770332816; x=1770937616; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=L8LUQCh61biJeu6NLvqdju68dTm4Qnz97N7lSr/nZdA=; b=NACLukwFSbLptp98bOwamc7YHDP9xgRw+3u7k4WSyJBCeujaNIpnaycoAvKd5SR+rc eTFCEDl4z8rJIbQGKVPA38Qt5pwxopdst3hC8f20vaB5ouGlDinXEBoqxZBR8KkLqsad mt5ZvCB5KTqIdCtYAkl9HfXNX3TsEqI7W0PpwjbLFXjBgzROj0U5awkztdOSauRVyt8O NTbPZIqcuv8zc4v1cga7AWd4dkZCyn78H4mSA5FDFiV566OS88PGAzL4MipH70Jgm/ol W2fSdftDc1NKHL6SC7YvBye5xcCO9ea4wUc84h0kkMJuDfxx2mjkh87Rfk8RCHS4Tonv NS5Q== X-Forwarded-Encrypted: i=1; AJvYcCVXYcvoxUZ5CJtSgyYOwcl6xVwS3T9GPhBfndMx+6bnqOeRMmeAZabrqdFnzDvitXagPuSumWxxoiK+ViU=@vger.kernel.org X-Gm-Message-State: AOJu0Yxkn/kpdSBscERR2M9LAe1dipX3I0sHAPFIQEHCqWOMyuDcQ7AD SJUVwphQJ5OVzZB+CczK4koYtPjAOgEGacn+mMduucHH0VAqhDuDNXExWD6Gf5/jSWicwxHvMgA sXyYXEA== X-Received: from pjok9.prod.google.com ([2002:a17:90a:9109:b0:353:e172:1e2c]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:497:b0:38d:fde5:249e with SMTP id adf61e73a8af0-393ad3ae21amr850191637.68.1770332815986; Thu, 05 Feb 2026 15:06:55 -0800 (PST) Date: Thu, 5 Feb 2026 15:06:53 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260129011517.3545883-1-seanjc@google.com> <20260129011517.3545883-7-seanjc@google.com> Message-ID: Subject: Re: [RFC PATCH v5 06/45] KVM: x86/mmu: Fold set_external_spte_present() into its sole caller From: Sean Christopherson To: Yan Zhao Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, Kiryl Shutsemau , Paolo Bonzini , linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, Kai Huang , Rick Edgecombe , Vishal Annapurve , Ackerley Tng , Sagi Shahar , Binbin Wu , Xiaoyao Li , Isaku Yamahata Content-Type: text/plain; charset="us-ascii" On Wed, Feb 04, 2026, Yan Zhao wrote: > On Wed, Jan 28, 2026 at 05:14:38PM -0800, Sean Christopherson wrote: > > @@ -626,6 +599,8 @@ static inline int __must_check __tdp_mmu_set_spte_atomic(struct kvm *kvm, > > struct tdp_iter *iter, > > u64 new_spte) > > { > > + u64 *raw_sptep = rcu_dereference(iter->sptep); > > + > > /* > > * The caller is responsible for ensuring the old SPTE is not a FROZEN > > * SPTE. KVM should never attempt to zap or manipulate a FROZEN SPTE, > > @@ -638,31 +613,46 @@ static inline int __must_check __tdp_mmu_set_spte_atomic(struct kvm *kvm, > > int ret; > > > > /* > > - * Users of atomic zapping don't operate on mirror roots, > > - * so don't handle it and bug the VM if it's seen. > > + * KVM doesn't currently support zapping or splitting mirror > > + * SPTEs while holding mmu_lock for read. > > */ > > - if (KVM_BUG_ON(!is_shadow_present_pte(new_spte), kvm)) > > + if (KVM_BUG_ON(is_shadow_present_pte(iter->old_spte), kvm) || > > + KVM_BUG_ON(!is_shadow_present_pte(new_spte), kvm)) > > return -EBUSY; > Should this be -EIO instead? Yeah, probably. > Though -EBUSY was introduced by commit 94faba8999b9 ('KVM: x86/tdp_mmu: > Propagate tearing down mirror page tables') > > > - ret = set_external_spte_present(kvm, iter->sptep, iter->gfn, > > - &iter->old_spte, new_spte, iter->level); > Add "lockdep_assert_held(&kvm->mmu_lock)" for this case? No, because I don't want to unnecessarily bleed TDX details into common MMU. Ah, but there was a pre-existing lockdep in set_external_spte_present(). So I guess that's arguably a functional change and should be called out in the changelog. But I still want to drop the assertion (or maybe move it to TDX in a prep patch), because ultimately the requirements around locking come from TDX, not from the TDP MMU.