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: <aR0yXoXbqr39bnv7@yzhao56-desk.sh.intel.com>
Date: Wed, 19 Nov 2025 10:58:38 +0800
From: Yan Zhao <yan.y.zhao@...el.com>
To: "Huang, Kai" <kai.huang@...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, Nov 18, 2025 at 05:44:25PM +0800, Huang, Kai wrote:
> 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.
It's a good idea.
I think it's also better to mention in patch 23 that returning 2M in
tdx_gmem_private_max_mapping_level() doesn't mean TDX will AUG 2M.

So, maybe
  Always try to let KVM map at 2MB level, though KVM may still map the page at
  4KB (i.e., passing in PG_LEVEL_4K to AUG) due to
  - the backend folio is 4KB,
  - disallow_lpage restrictions:
    a) mixed private/shared pages in the 2MB range
    b) level alignment due to slot base_gfn, slot size, and ugfn
    c) guest_inhibit bit set due to guest accept level

  When there's accept level of 4KB from the guest, KVM will AUG the page at 4KB
  directly due to the guest_inhibit bit set. So guest is able to accept at 4KB
  successfully.

  When there's no accept level from the guest, and there're no other
  restrictions on the GFN range of a huge folio, KVM will AUG the page at 2MB
  first.

  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 and set the
  guest_inhibit bit. The guest then will be able to accept the 4K pages
  successfully.