linux-kernel - Re: [RFC PATCH v2 14/23] KVM: TDX: Split and inhibit huge mappings if a VMExit carries level info

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: <3866c2e32d51f87ac80cb46489f99ee09e3e3864.camel@intel.com>
Date: Tue, 18 Nov 2025 09:44:25 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "Zhao, Yan Y" <yan.y.zhao@...el.com>
CC: "Du, Fan" <fan.du@...el.com>, "Li, Xiaoyao" <xiaoyao.li@...el.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "Hansen, Dave"
	<dave.hansen@...el.com>, "david@...hat.com" <david@...hat.com>,
	"thomas.lendacky@....com" <thomas.lendacky@....com>, "vbabka@...e.cz"
	<vbabka@...e.cz>, "tabba@...gle.com" <tabba@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "binbin.wu@...ux.intel.com"
	<binbin.wu@...ux.intel.com>, "kas@...nel.org" <kas@...nel.org>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "ackerleytng@...gle.com"
	<ackerleytng@...gle.com>, "michael.roth@....com" <michael.roth@....com>,
	"Weiny, Ira" <ira.weiny@...el.com>, "Peng, Chao P" <chao.p.peng@...el.com>,
	"Yamahata, Isaku" <isaku.yamahata@...el.com>, "Annapurve, Vishal"
	<vannapurve@...gle.com>, "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
	"Miao, Jun" <jun.miao@...el.com>, "x86@...nel.org" <x86@...nel.org>,
	"pgonda@...gle.com" <pgonda@...gle.com>
Subject: Re: [RFC PATCH v2 14/23] KVM: TDX: Split and inhibit huge mappings if
 a VMExit carries level info

On Tue, 2025-11-18 at 10:20 +0800, Yan Zhao wrote:
> On Tue, Nov 18, 2025 at 09:04:20AM +0800, Huang, Kai wrote:
> > On Fri, 2025-11-14 at 15:22 +0800, Yan Zhao wrote:
> > > > Will 'level == PG_LEVEL_4K' in this case?  Or will this function return
> > > > early right after check the eeq_type?
> > > The function will return early right after check the eeq_type.
> > 
> > But for such case the fault handler will still return 2M and KVM will AUG 2M
> > page?  Then if guest accepts 4K page, a new exit to KVM would happen?
> > 
> > But this time KVM is able to find the info that guest is accepting 4K and KVM
> > will split the 2M to 4K pages so we are good to go?
> 
> If guest accesses a private memory without first accepting it (like non-Linux
> guests), the sequence is:
> 1. Guest accesses a private memory.
> 2. KVM finds it can map the GFN at 2MB. So, AUG 2MB pages.
> 3. Guest accepts the GFN at 4KB.
> 4. KVM receives a EPT violation with eeq_type of ACCEPT and level 4KB
> 5. KVM splits the 2MB mapping.
> 6. Guest accepts successfully and accesses the page.

Yeah looks good.

Btw, the change to make KVM AUG 2M when no accept level is specified is done in
patch 23.  I think you can add some text to explain in that patch?

E.g., something like:

  Always try to AUG 2M hugepage, even there's no accept level from the guest.
  If the guest later accepts at 4K page, the TDX module will exit to KVM with 
  the actual accept level info and KVM will split to 4K pages.  The guest then
  will be able to accept the 4K pages successfully.