From: Sean Christopherson <seanjc@google.com>
To: Rick P Edgecombe <rick.p.edgecombe@intel.com>
Cc: "kas@kernel.org" <kas@kernel.org>,
Yan Y Zhao <yan.y.zhao@intel.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Xiaoyao Li <xiaoyao.li@intel.com>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
Kai Huang <kai.huang@intel.com>,
Dave Hansen <dave.hansen@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>,
"ackerleytng@google.com" <ackerleytng@google.com>,
"sagis@google.com" <sagis@google.com>,
Vishal Annapurve <vannapurve@google.com>,
"bp@alien8.de" <bp@alien8.de>,
"tglx@kernel.org" <tglx@kernel.org>,
"yilun.xu@linux.intel.com" <yilun.xu@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH] x86/virt/tdx: Warn on !4K level in tdh_mem_page_aug()
Date: Tue, 25 Aug 2026 10:48:41 -0700 [thread overview]
Message-ID: <ao3VebUyMVlK_qGA@google.com> (raw)
In-Reply-To: <1f12e12f1d5e7baed6630fd15cea5420c40ada68.camel@intel.com>
On Tue, Aug 25, 2026, Rick P Edgecombe wrote:
> On Tue, 2026-08-25 at 10:55 +0800, Yan Zhao wrote:
> > Do not drop the "level" parameter instead, as it will be needed once huge
> > page support is added.
>
> TDX and coco has so many plans for the future. An abnormal amount of concurrent
> thinking. I think everyone agrees we need to wrangle it by doing things
> iteratively, and cheating when it comes to uABI.
>
> Since we have TDX huge pages coming so soon, it seems ok to leave it. But I just
> wanted to say having the level arg here originally was wrong. So this should not
> be precedent for pre-enabling of things years in the future.
Eh, I would argue that in this particular case, including @level was ok from a
process perspective, the main issue is the implementation was buggy. Which is
very arguably _because_ there was no user to validate the code, but given all the
pre-existing KVM MMU code at play, at some point we'd have to insert code to say
"hugepages aren't supported". E.g. in this specific case, assuming PG_LEVEL_4K
could have been just as bad as having a partially-dead @level.
But nitpicking aside, +1 to not building out unused, untestable infrastructure.
next prev parent reply other threads:[~2026-08-25 17:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 2:55 [PATCH] x86/virt/tdx: Warn on !4K level in tdh_mem_page_aug() Yan Zhao
2026-08-25 13:31 ` Sean Christopherson
2026-08-26 7:23 ` Yan Zhao
2026-08-26 13:13 ` Dave Hansen
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 [this message]
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=ao3VebUyMVlK_qGA@google.com \
--to=seanjc@google.com \
--cc=ackerleytng@google.com \
--cc=binbin.wu@linux.intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--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=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 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.