From: Rick Edgecombe <rick.p.edgecombe@intel.com>
To: pbonzini@redhat.com, dave.hansen@intel.com, seanjc@google.com,
x86@kernel.org, kas@kernel.org, adrian.hunter@intel.com,
yan.y.zhao@intel.com, binbin.wu@intel.com, xiaoyao.li@intel.com,
chao.gao@intel.com, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, nik.borisov@suse.com,
yilun.xu@linux.intel.com, tony.lindgren@linux.intel.com
Cc: rick.p.edgecombe@intel.com
Subject: [PATCH v2 0/2] Drop unneeded cache flushing
Date: Thu, 15 Oct 2026 12:17:08 -0700 [thread overview]
Message-ID: <20261015191710.3632302-1-rick.p.edgecombe@intel.com> (raw)
Hi TDX developers,
Can I get another round of review before we ask Dave and Sean to look at
it? I'd like to pick up a few more RB tags.
-- Summary --
In the early days of TDX it was assumed the HW would need some cache
flushing help around transitioning memory between KeyIDs, and so TDX arch
was designed to specify how the VMM needed to help the module perform
this. But it turned out the HW was able to handle these issues without SW
help. For some reason the TDX arch around performing the flushes remained.
Now the TDX arch is getting fixed and Linux can remove the code that was
helping perform this unneeded cache flushing. The changes will appear in
a future documentation update.
As some more context, while this is nice cleanup as is, merging these
patches will let us drop 2 patches out of the TDX huge pages series. Then
that series doesn't need to modify these flushes to work with TDX huge
pages. It also addresses Kiryl's comment about the cache flushing in
tdh_mem_page_aug() not respecting the 'level' arg, or warning that non-4KB
sizes are not supported.[0]
-- Changes since v1 --
Yilun asked if we could also remove the WBINVD calls around kexec and TDX
setup error paths. It seems the answer is likely yes, but not confirmed
enough for me yet. So I left that change for the future. Besides, it
doesn't have the same TDX huge page intersection.
Yilun's comment about cleaning up the TDR reclaim after the changes in
patch 2 was a bit bigger that I expected. I really debated whether to
split that out. But it wasn't very feasible to do it as a prep patch, so I
left it as one big bigger. Really debated doing that, or an follow up
cleanup patch. Opinions requested.
Based on v7.3-rc7.
Thanks,
Rick
Rick Edgecombe (2):
x86/virt/tdx: Drop tdx_clflush_*()
x86/virt/tdx: Drop tdh_phymem_page_wbinvd_*()
arch/x86/include/asm/tdx.h | 2 --
arch/x86/kvm/vmx/tdx.c | 40 +++++-------------------------
arch/x86/virt/vmx/tdx/tdx.c | 49 -------------------------------------
arch/x86/virt/vmx/tdx/tdx.h | 1 -
4 files changed, 6 insertions(+), 86 deletions(-)
--
2.55.0
next reply other threads:[~2026-10-15 19:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 19:17 Rick Edgecombe [this message]
2026-10-15 19:17 ` [PATCH v2 1/2] x86/virt/tdx: Drop tdx_clflush_*() Rick Edgecombe
2026-10-15 19:17 ` [PATCH v2 2/2] x86/virt/tdx: Drop tdh_phymem_page_wbinvd_*() Rick Edgecombe
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=20261015191710.3632302-1-rick.p.edgecombe@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=adrian.hunter@intel.com \
--cc=binbin.wu@intel.com \
--cc=chao.gao@intel.com \
--cc=dave.hansen@intel.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nik.borisov@suse.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tony.lindgren@linux.intel.com \
--cc=x86@kernel.org \
--cc=xiaoyao.li@intel.com \
--cc=yan.y.zhao@intel.com \
--cc=yilun.xu@linux.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
all inboxes | Powered by JetHome®