From: Dave Hansen <dave.hansen@intel.com>
To: Yan Zhao <yan.y.zhao@intel.com>, Sean Christopherson <seanjc@google.com>
Cc: kas@kernel.org, dave.hansen@linux.intel.com, x86@kernel.org,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
linux-coco@lists.linux.dev, rick.p.edgecombe@intel.com,
pbonzini@redhat.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, kai.huang@intel.com, yilun.xu@linux.intel.com,
vannapurve@google.com, ackerleytng@google.com, sagis@google.com,
binbin.wu@linux.intel.com, xiaoyao.li@intel.com
Subject: Re: [PATCH] x86/virt/tdx: Warn on !4K level in tdh_mem_page_aug()
Date: Wed, 26 Aug 2026 06:13:21 -0700 [thread overview]
Message-ID: <1e77b1f6-0491-464b-b79f-ca756a73e7ea@intel.com> (raw)
In-Reply-To: <ao6UVdWNbhQaAFsm@yzhao56-desk.sh.intel.com>
On 8/26/26 00:23, Yan Zhao wrote:
> Do not extend the CLFLUSH coverage to make tdh_mem_page_aug() work with
> huge pages. Not only would this scatter huge page related changes across
> multiple series, but it also makes little sense to have tdh_mem_page_aug()
> alone work for huge pages without implementing its counterparts in the
> unmapping and splitting paths.
For me, it's all about simplicity. It's bad to add *complexity* for
future functionality because it might not ever get used. But in this
case, the (Sean-suggested) change is pretty simple. It's more
complicated to *not* fix the bug and *explain* why it's not being fixed
than to just fix the dang thing.
Also, it's just generally a good idea to carry a length along with a
pointer. <cough>strlen()<cough>
next prev parent reply other threads:[~2026-08-26 13:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 2:55 Yan Zhao
2026-08-25 13:31 ` Sean Christopherson
2026-08-26 7:23 ` Yan Zhao
2026-08-26 13:13 ` Dave Hansen [this message]
2026-08-26 13:36 ` Edgecombe, Rick P
2026-08-26 16:23 ` Edgecombe, Rick P
2026-08-27 3:02 ` Yan Zhao
2026-08-25 17:15 ` Edgecombe, Rick P
2026-08-25 17:48 ` Sean Christopherson
2026-08-25 18:19 ` Edgecombe, Rick P
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=1e77b1f6-0491-464b-b79f-ca756a73e7ea@intel.com \
--to=dave.hansen@intel.com \
--cc=ackerleytng@google.com \
--cc=binbin.wu@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=kai.huang@intel.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=sagis@google.com \
--cc=seanjc@google.com \
--cc=tglx@kernel.org \
--cc=vannapurve@google.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®