From: Sean Christopherson <seanjc@google.com>
To: Rick P Edgecombe <rick.p.edgecombe@intel.com>
Cc: Xiaoyao Li <xiaoyao.li@intel.com>,
Kai Huang <kai.huang@intel.com>,
"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>,
Reinette Chatre <reinette.chatre@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Yan Y Zhao <yan.y.zhao@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
Isaku Yamahata <isaku.yamahata@intel.com>,
"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 14:09:41 -0700 [thread overview]
Message-ID: <aEnwlQtenIEUczVX@google.com> (raw)
In-Reply-To: <32ff838c57f88fd4b092326afcb68b6a40f24ba0.camel@intel.com>
On Wed, Jun 11, 2025, Rick P Edgecombe wrote:
> On Wed, 2025-06-11 at 11:10 -0700, Sean Christopherson wrote:
> > Back to the main topic, KVM needs to have a single source of truth when it comes
> > to whether a fault is private and thus mirrored (or not). Common KVM needs to be
> > aware of aliased GFN bits, but absolute nothing outside of TDX (including common
> > VMX code) should be aware the mirror vs. "direct" (I hate that terminology; KVM
> > has far, far too much history and baggage with "direct") is tied to the existence
> > and polarity of aliased GFN bits.
> >
> > What we have now does work *today* (see this bug), and it will be a complete
> > trainwreck if we ever want to steal GFN bits for other reasons.
>
> KVM XO's time has come and gone. Out of curiosity is there anything else?
Not that I know of.
> Readability is the main objection here, right?
Maintainability first and foremost, but definitely readability too (which obviously
plays into maintainability). E.g. if we properly encapsulate TDX, then it'll be
harder to pile on hacks and whatnot simply because common code won't have access
to state that lets it misbehave.
But yes, you're correct in that I don't have a specific use case in mind.
next prev parent reply other threads:[~2025-06-11 21:09 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
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 [this message]
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=aEnwlQtenIEUczVX@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox