From: "Huang, Kai" <kai.huang@intel.com>
To: "pbonzini@redhat.com" <pbonzini@redhat.com>,
"seanjc@google.com" <seanjc@google.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"jthoughton@google.com" <jthoughton@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] KVM: x86/mmu: Use CMPXCHG when clearing Accessed bit in TDP MMU
Date: Wed, 29 Jul 2026 11:07:33 +0000 [thread overview]
Message-ID: <7722f65f2f60b411fbdafe53406461a1e6d8fc7d.camel@intel.com> (raw)
In-Reply-To: <20260728002236.869865-2-seanjc@google.com>
On Mon, 2026-07-27 at 17:22 -0700, Sean Christopherson wrote:
> Use LOCK CMPXCHG instead of LOCK AND to clear the Accessed bit when aging
> SPTEs in the TDP MMU, as doing a LOCK AND can corrupt a FROZEN SPTE and
> allow a third CPU to effectively overwrite the FROZEN SPTE. As pointed
> out by AI of some kind, because the magic FROZEN_SPTE value is a "full"
> SPTE, not a single bit, and includes the Accessed bit, clearing the
> Accessed bit in a FROZEN SPTE will result in is_frozen_spte() getting a
> false negative.
>
> E.g. if CPU0 freezes an SPTE, and CPU1 clears the Accessed bitin the frozen
^
bit in
> SPTE, then CPU2 could come along and overwrite the frozen SPTE with a
> shadow-present SPTE.
>
> Thankfully, the false negative is largely benign, because outside of TDX,
> which doesn't support aging, KVM only freezes leaf SPTEs when removing an
> upper level shadow page. So while KVM could clobber a frozen SPTE back to
> a shadow-present SPTE, and could even use the new SPTE, the subsequent TLB
> flush will make the orphaned, shadow-present SPTE unreachable. Failure to
> ever zap the orphaned leaf SPTE would show up in KVM's stats, but otherwise
> is benign (because KVM no longer keeps an elevated refcount for leaf SPTEs).
>
> Opportunistically add a comment to warn future developers away from using
> kvm_tdp_mmu_write_spte_atomic() and tdp_mmu_clear_spte_bits_atomic(), as
> they are generally unsafe. Keep the helpers, e.g. instead of open-coding
> the atomic64_fetch_and() in tdp_mmu_clear_spte_bits(), as scary warnings
> usually are more effective deterrent against recidivism than removal of the
> dangerous code.
>
> Alternatively, KVM could use different bits for the magic FROZEN_SPTE value,
> e.g. setting the Dirty bits (with effective IPAT and Global aliases) would
> likely be "ok", as IPAT/Global are extremely unlikely to be cleared without
> doing a full SPTE write, and KVM's clearing of Dirty bits shares logic with
> Write-Protection, which must do a full SPTE write (via cmpxchg64() in the
> TDP MMU) to ensure KVM isn't clobbering state. But there is zero reason to
> carry that risk (beyond stubbornness in wanting to preserve a "cute" idea),
> as the cost of LOCK CMPXCHG and LOCK AND are within 1-2 uops of each other
> on modern hardware.
>
> Fixes: b146a9b34aed ("KVM: x86/mmu: Age TDP MMU SPTEs without holding mmu_lock")
> Cc: stable@vger.kernel.org
> Signed-off-by: Sean Christopherson <seanjc@google.com>
>
Reviewed-by: Kai Huang <kai.huang@intel.com>
next prev parent reply other threads:[~2026-07-29 11:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 0:22 [PATCH 0/2] KVM: x86/mmu: Use LOCK CMPXCHG to clear Accessed bits Sean Christopherson
2026-07-28 0:22 ` [PATCH 1/2] KVM: x86/mmu: Use CMPXCHG when clearing Accessed bit in TDP MMU Sean Christopherson
2026-07-28 0:31 ` James Houghton
2026-07-29 11:07 ` Huang, Kai [this message]
2026-07-28 0:22 ` [PATCH 2/2] KVM: x86/mmu: Use CMPXCHG when clearing Accessed bit in the shadow MMU Sean Christopherson
2026-07-28 0:34 ` James Houghton
2026-07-29 11:10 ` Huang, Kai
2026-07-29 11:12 ` [PATCH 0/2] KVM: x86/mmu: Use LOCK CMPXCHG to clear Accessed bits Huang, Kai
2026-07-29 13:33 ` Sean Christopherson
2026-07-29 22:04 ` Huang, Kai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7722f65f2f60b411fbdafe53406461a1e6d8fc7d.camel@intel.com \
--to=kai.huang@intel.com \
--cc=jthoughton@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.