All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Rick P Edgecombe <rick.p.edgecombe@intel.com>
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
	Kai Huang <kai.huang@intel.com>,
	 "binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>,
	Xiaoyao Li <xiaoyao.li@intel.com>,
	 Reinette Chatre <reinette.chatre@intel.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	 Yan Y Zhao <yan.y.zhao@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	 Isaku Yamahata <isaku.yamahata@intel.com>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	 "tony.lindgren@linux.intel.com" <tony.lindgren@linux.intel.com>
Subject: Re: [PATCH] KVM: x86/mmu: Embed direct bits into gpa for KVM_PRE_FAULT_MEMORY
Date: Wed, 11 Jun 2025 13:43:25 -0700	[thread overview]
Message-ID: <aEnqbfih0gE4CDM-@google.com> (raw)
In-Reply-To: <7de83a03f0071c79a63d5e143f1ab032fff1d867.camel@intel.com>

On Wed, Jun 11, 2025, Rick P Edgecombe wrote:
> On Wed, 2025-06-11 at 12:37 -0700, Sean Christopherson wrote:
> > Ugh, and the whole tdp_mmu_get_root_for_fault() handling is broken.
> > is_page_fault_stale() only looks at mmu->root.hpa, i.e. could theoretically blow
> > up if the shared root is somehow valid but the mirror root is not.  Probably can't
> > happen in practice, but it's ugly.
> 
> We had some discussion on this root valid/invalid pattern:
> https://lore.kernel.org/kvm/d33d00b88707961126a24b19f940de43ba6e6c56.camel@intel.com/
> 
> It's brittle though.

Hmm, yeah, the is_page_fault_stale() thing is definitely benign, just odd.

> > Oof, and I've no idea what kvm_tdp_mmu_fast_pf_get_last_sptep() is doing.  It
> > says:
> > 
> > 	/* Fast pf is not supported for mirrored roots  */
> > 
> > but I don't see anything that actually enforces that.
> 
> Functionally, page_fault_can_be_fast() should prevented this with the check of
> kvm->arch.has_private_mem.

No?  I see this:

	if (kvm->arch.has_private_mem &&
	    fault->is_private != kvm_mem_is_private(kvm, fault->gfn))
		return false;

I.e. a private fault can be fast, so long as the page is already in the correct
shared vs. private state.  I can imagine that it's impossible for TDX to generate
protection violations, but I think kvm_tdp_mmu_fast_pf_get_last_sptep() could be
reached with a mirror root if kvm_ad_enabled=false.

	if (!fault->present)
		return !kvm_ad_enabled;

	/*
	 * Note, instruction fetches and writes are mutually exclusive, ignore
	 * the "exec" flag.
	 */
	return fault->write;

> But, yea it's not correct for being readable. The mirror/external concepts
> only work if they make sense as independent concepts.  Otherwise it's just
> naming obfuscation.

  reply	other threads:[~2025-06-11 20:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-11  0:10 [PATCH] KVM: x86/mmu: Embed direct bits into gpa for KVM_PRE_FAULT_MEMORY Xiaoyao Li
2025-06-11 18:10 ` Sean Christopherson
2025-06-11 18:21   ` Paolo Bonzini
2025-06-11 19:37     ` Sean Christopherson
2025-06-11 20:25       ` Edgecombe, Rick P
2025-06-11 20:43         ` Sean Christopherson [this message]
2025-06-11 21:16           ` Edgecombe, Rick P
2025-06-12  7:19             ` Yan Zhao
2025-06-12 18:50               ` Edgecombe, Rick P
2025-06-13  1:14                 ` Yan Zhao
2025-06-12  6:58           ` Yan Zhao
2025-06-11 20:45   ` Edgecombe, Rick P
2025-06-11 21:09     ` Sean Christopherson
2025-06-12 12:20   ` Yan Zhao
2025-06-12 18:40     ` Edgecombe, Rick P
2025-06-13  0:09       ` Sean Christopherson
2025-06-13 16:12         ` Edgecombe, Rick P
2025-06-12  4:44 ` Paolo Bonzini

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=aEnqbfih0gE4CDM-@google.com \
    --to=seanjc@google.com \
    --cc=adrian.hunter@intel.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=isaku.yamahata@intel.com \
    --cc=kai.huang@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=reinette.chatre@intel.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=tony.lindgren@linux.intel.com \
    --cc=xiaoyao.li@intel.com \
    --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.