linux-kernel - Re: [RFC PATCH 09/21] KVM: TDX: Enable 2MB mapping size after TD is RUNNABLE

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: <0020abc9-73ac-4dee-b643-b21e9283c26e@intel.com>
Date: Fri, 13 Jun 2025 14:08:14 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Yan Zhao <yan.y.zhao@...el.com>, Sean Christopherson <seanjc@...gle.com>,
 Kai Huang <kai.huang@...el.com>,
 Rick P Edgecombe <rick.p.edgecombe@...el.com>,
 Kirill Shutemov <kirill.shutemov@...el.com>, Fan Du <fan.du@...el.com>,
 Dave Hansen <dave.hansen@...el.com>, "david@...hat.com" <david@...hat.com>,
 Zhiquan Li <zhiquan1.li@...el.com>,
 "thomas.lendacky@....com" <thomas.lendacky@....com>,
 "tabba@...gle.com" <tabba@...gle.com>,
 "quic_eberman@...cinc.com" <quic_eberman@...cinc.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Ira Weiny <ira.weiny@...el.com>, "vbabka@...e.cz" <vbabka@...e.cz>,
 "pbonzini@...hat.com" <pbonzini@...hat.com>,
 Isaku Yamahata <isaku.yamahata@...el.com>,
 "michael.roth@....com" <michael.roth@....com>,
 "binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>,
 "ackerleytng@...gle.com" <ackerleytng@...gle.com>,
 Chao P Peng <chao.p.peng@...el.com>,
 "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
 Vishal Annapurve <vannapurve@...gle.com>, "jroedel@...e.de"
 <jroedel@...e.de>, Jun Miao <jun.miao@...el.com>,
 "pgonda@...gle.com" <pgonda@...gle.com>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: [RFC PATCH 09/21] KVM: TDX: Enable 2MB mapping size after TD is
 RUNNABLE

On 6/13/2025 1:35 PM, Yan Zhao wrote:
> To avoid confusion, here's the full new design:
> 
> 1.when an EPT violation carries an ACCEPT level info
>    (This occurs when TD performs ACCEPT before it accesses memory),
>    KVM maps the page at map level <= the specified level.
>    Guest's ACCEPT will succeed or return PAGE_SIZE_MATCH if map level < the
>    specified level.
> 
> 2.when an EPT violation does not carry ACCEPT level info
>    (This occurs when TD accesses memory before invoking ACCEPT),
> 
>    1) if the TD is configured to always accept VMM's map level,
>       KVM allows to map at 2MB.
>       TD's later 4KB ACCEPT will return PAGE_SIZE_MATCH.
>       TD can either retry with 2MB ACCEPT or explictly invoke a TDVMCALL for
>       demotion.
>    2) if the TD is not configured to always accept VMM's map level,
>       KVM always maps at 4KB.

Is it the decision derived from the discussion of this series to make 
the design simple and avoid the demotion on ACCEPT?

It looks like KVM's own design preference that if the TD doesn't opt-in 
the proposed new feature "always accept VMM's map level', the only way 
it can get the page mapped by EPT as hugepage is always trying to accept 
the page before first access and trying accept starting from biggest 
page size.

I'm OK with it.

>       TD's 2MB ACCEPT will return PAGE_SIZE_MATCH.
> 
> Please let me know if anything does not look right.