linux-kernel - Re: [PATCH v4 12/16] x86/virt/tdx: Add helpers to allow for pre-allocating pages

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <a99ec2d41087c65e6b55ac53af8dc158ec5dc059.camel@intel.com>
Date: Tue, 20 Jan 2026 07:10:59 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>, "Edgecombe, Rick
 P" <rick.p.edgecombe@...el.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-coco@...ts.linux.dev"
	<linux-coco@...ts.linux.dev>, "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>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "mingo@...hat.com"
	<mingo@...hat.com>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "Yamahata, Isaku"
	<isaku.yamahata@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "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 12/16] x86/virt/tdx: Add helpers to allow for
 pre-allocating pages

On Thu, 2025-11-27 at 10:38 +0800, Binbin Wu wrote:
> 
> On 11/27/2025 6:33 AM, Edgecombe, Rick P wrote:
> > > >     
> > > >     static int tdx_topup_external_fault_cache(struct kvm_vcpu *vcpu, unsigned int cnt)
> > > >     {
> > > > -	struct vcpu_tdx *tdx = to_tdx(vcpu);
> > > > +	struct tdx_prealloc *prealloc = &to_tdx(vcpu)->prealloc;
> > > > +	int min_fault_cache_size;
> > > >     
> > > > -	return kvm_mmu_topup_memory_cache(&tdx->mmu_external_spt_cache, cnt);
> > > > +	/* External page tables */
> > > > +	min_fault_cache_size = cnt;
> > > > +	/* Dynamic PAMT pages (if enabled) */
> > > > +	min_fault_cache_size += tdx_dpamt_entry_pages() * PT64_ROOT_MAX_LEVEL;
> > > Is the value PT64_ROOT_MAX_LEVEL intended, since dynamic PAMT pages are only
> > > needed for 4KB level?
> > I'm not sure I follow. We need DPAMT backing for each S-EPT page table.
> Oh, right!
> 
> IIUIC,  PT64_ROOT_MAX_LEVEL is actually
> - PT64_ROOT_MAX_LEVEL - 1 for S-ETP pages since root page is not needed.
> - 1 for TD private memory page
> 
> It's better to add a comment about it.
> 

But theoretically we don't need a pair of DPAMT pages for one 4K S-EPT
page -- we only need a pair for a entire 2M range.  If these S-EPT pages
in the fault path are allocated from the same 2M range, we are actually
over allocating DPAMT pages.

And AFAICT unfortunately there's no way to resolve this, unless we use
tdx_alloc_page() for S-EPT pages.