All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Yan Zhao <yan.y.zhao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	 Kai Huang <kai.huang@intel.com>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	 Sashiko Bot <sashiko-bot@kernel.org>
Subject: Re: [PATCH 2/4] KVM: x86/mmu: Harden "map private PFN" against unexpected root invalidation
Date: Mon, 17 Aug 2026 06:37:39 -0700	[thread overview]
Message-ID: <aoMOo--zGYqmgwtT@google.com> (raw)
In-Reply-To: <aoK4szIBYjaJ6RS7@yzhao56-desk.sh.intel.com>

On Mon, Aug 17, 2026, Yan Zhao wrote:
> On Tue, Aug 11, 2026 at 10:07:41AM -0700, Sean Christopherson wrote:
> > On Tue, Aug 11, 2026, Yan Zhao wrote:
> > > On Thu, Aug 06, 2026 at 02:40:48PM -0700, Sean Christopherson wrote:
> > > > Move kvm_tdp_mmu_map_private_pfn()'s reload of the MMU into its tight loop
> > > > so that an unexpected root invalidation has a better chance of being
> > > > handled gracefully, even though it should be impossible for the vCPU's root
> > > > to be invalidated after the initial reload.  As is, encountering an invalid
> > > > root is *guaranteed* to put the task into an infinite loop (albeit a
> > > > breakable loop that honors NEED_RESCHED).
> > > Note: without the newly added is_page_fault_stale() check in patch 4, an invalid
> > > root would not put the task into an infinite loop :) 
> > > 
> > > BTW: As noted in [1], is_page_fault_stale() only checks !mirror roots, and
> > > kvm_mmu_reload() reloads mirror roots only when !mirror roots are also invalid,
> > > since an invalid mirror root was considered impossible. (up to now, no?)
> > > 
> > > [1] https://lore.kernel.org/all/anrD8nI8RfYoNvbf@yzhao56-desk.sh.intel.com
> > 
> > > > Add a WARN to try and detect bugs that break KVM's expectations, along with
> > > > a comment to explain why it should be impossible for the root to be
> > > > invalidated.
> > > And there's already a warning in kvm_tdp_mmu_map():
> > > "KVM_MMU_WARN_ON(!root || root->role.invalid);".
> > > So the warning also seems redundant.
> > 
> > No, KVM_REQ_MMU_FREE_OBSOLETE_ROOTS can be pending even if the current root is
> > valid.  And once the is_page_fault_stale() check comes along, the WARN in
> > kvm_tdp_mmu_map() is effectively unreachable.  The patch ordering is weird, but
> > there wasn't a great solution because adding is_page_fault_stale() first would
> > create an obvious infinite loop.
> Ok. When KVM_REQ_MMU_FREE_OBSOLETE_ROOTS is pending, it is only for direct roots.

No?  KVM_REQ_MMU_FREE_OBSOLETE_ROOTS is also used by the shadow MMU, in
__kvm_mmu_prepare_zap_page() and in FNAME(fetch).  Or did I misunderstand the
question?

> This patch still holds that assumption true, right?
> 
> If so, since mirror roots cannot be invalid after the first reload, any
> subsequent kvm_mmu_reload() calls triggered later in the loop would only reload
> direct roots.
> 
> Is this necessary for kvm_tdp_mmu_map_private_pfn(), which only maps private pfn?
> Or is the purpose of this patch simply to avoid the potential infinite loop
> after patch 4?

Yes, though I would still want this change even without patch 4, as there are no
guarantees that KVM won't gain an equivalent check in kvm_tdp_mmu_map() in the
future, e.g. as hardening.

  reply	other threads:[~2026-08-17 13:37 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-06 21:40 [PATCH 0/4] KVM: x86/mmu: Fix pre-fault and map private loops Sean Christopherson
2026-08-06 21:40 ` [PATCH 1/4] KVM: x86/mmu: Reload MMU on *every* page pre-fault attempt/iteration Sean Christopherson
2026-08-07  8:58   ` Huang, Kai
2026-08-07 19:04   ` Edgecombe, Rick P
2026-08-07 19:11     ` Sean Christopherson
2026-08-06 21:40 ` [PATCH 2/4] KVM: x86/mmu: Harden "map private PFN" against unexpected root invalidation Sean Christopherson
2026-08-06 22:14   ` sashiko-bot
2026-08-06 22:21     ` Sean Christopherson
2026-08-07 20:26   ` Edgecombe, Rick P
2026-08-07 22:18     ` Sean Christopherson
2026-08-10 20:01       ` Edgecombe, Rick P
2026-08-11  7:01   ` Yan Zhao
2026-08-11 17:07     ` Sean Christopherson
2026-08-17  7:30       ` Yan Zhao
2026-08-17 13:37         ` Sean Christopherson [this message]
2026-08-06 21:40 ` [PATCH 3/4] KVM: x86/mmu: Top-up memory caches when retrying "map private PFN" Sean Christopherson
2026-08-06 21:56   ` sashiko-bot
2026-08-06 22:07     ` Sean Christopherson
2026-08-07 20:38   ` Edgecombe, Rick P
2026-08-07 22:13     ` Sean Christopherson
2026-08-10 20:37       ` Edgecombe, Rick P
2026-08-10 20:43         ` Sean Christopherson
2026-08-06 21:40 ` [PATCH 4/4] KVM: x86/mmu: Add sanity check to detect stale page faults in " Sean Christopherson
2026-08-06 21:54   ` sashiko-bot
2026-08-06 22:12     ` Sean Christopherson
2026-08-11  0:25   ` Yan Zhao
2026-08-11  6:40     ` Yan Zhao
2026-08-11 17:12     ` Sean Christopherson
2026-08-17  6:53       ` Yan Zhao
2026-08-17 13:43         ` Sean Christopherson

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=aoMOo--zGYqmgwtT@google.com \
    --to=seanjc@google.com \
    --cc=kai.huang@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=sashiko-bot@kernel.org \
    --cc=yan.y.zhao@intel.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.