linux-kernel - Re: [PATCH v4 11/16] KVM: TDX: Add x86 ops for external spt cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <69bc12acb3eaf740bff12e8bd0334cd327876a20.camel@intel.com>
Date: Wed, 21 Jan 2026 22:34:14 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "seanjc@...gle.com" <seanjc@...gle.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-coco@...ts.linux.dev"
	<linux-coco@...ts.linux.dev>, "Huang, Kai" <kai.huang@...el.com>, "Li,
 Xiaoyao" <xiaoyao.li@...el.com>, "Hansen, Dave" <dave.hansen@...el.com>,
	"Zhao, Yan Y" <yan.y.zhao@...el.com>, "Wu, Binbin" <binbin.wu@...el.com>,
	"kas@...nel.org" <kas@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "tglx@...utronix.de"
	<tglx@...utronix.de>, "Yamahata, Isaku" <isaku.yamahata@...el.com>,
	"Annapurve, Vishal" <vannapurve@...gle.com>, "bp@...en8.de" <bp@...en8.de>,
	"Gao, Chao" <chao.gao@...el.com>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v4 11/16] KVM: TDX: Add x86 ops for external spt cache

On Wed, 2026-01-21 at 14:12 -0800, Sean Christopherson wrote:
> IMO, it's largely irrelevant for this discussion.  Bluntly, the code proposed
> here is simply bad.
> 

FWIW, I wasn't ecstatic about it, but was starting to doubt we could find a
better solution after a string of failed POCs. Will take this feedback under
consideration for the future.

>   S-EPT hugepage support just makes it worse.
> 
> The core issue is that the ownership of the pre-allocation cache is split across
> KVM and the TDX subsystem (and within KVM, between tdx.c and the MMU), which makes
> it extremely difficult to understand who is responsible for what, which in turn
> leads to brittle code, and sets the hugepage series up to fail, e.g. by unnecessarily
> mixing S-EPT page allocation with PAMT maintenance.q

...or require more extensive changes with relevant huge page related
justification, right? We are not defining uABI I think.

> 
> That aside, I generally agree with Dave.  
> 

Ok.

> The only caveat I'll throw in is that
> I do think we need to _at least_ consider how things will likely play out when
> all is said and done, otherwise we'll probably paint ourselves into a corner.

Well this is the tricky part then.

> E.g. we don't need to know exactly how S-EPT hugepage support will interact with
> DPAMT, but IMO we do need to be aware that KVM will need to demote pages outside
> of vCPU context, and thus will need to pre-allocate pages for PAMT without having
> a loaded/running vCPU.  That knowledge doesn't require active support in the
> DPAMT series, but it most definitely influences design decisions.

I see what you are saying here though. It depends on how you look at it a bit.