linux-kernel - Re: [RFC PATCH 03/21] x86/virt/tdx: Add SEAMCALL wrapper tdh_mem_page

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: <99f5585d759328db973403be0713f68e492b492a.camel@intel.com>
Date: Tue, 1 Jul 2025 21:15:36 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Zhao, Yan Y" <yan.y.zhao@...el.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "Li, Xiaoyao"
	<xiaoyao.li@...el.com>, "quic_eberman@...cinc.com"
	<quic_eberman@...cinc.com>, "Hansen, Dave" <dave.hansen@...el.com>,
	"david@...hat.com" <david@...hat.com>, "Li, Zhiquan1"
	<zhiquan1.li@...el.com>, "tabba@...gle.com" <tabba@...gle.com>,
	"vbabka@...e.cz" <vbabka@...e.cz>, "thomas.lendacky@....com"
	<thomas.lendacky@....com>, "michael.roth@....com" <michael.roth@....com>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "Weiny, Ira" <ira.weiny@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "ackerleytng@...gle.com"
	<ackerleytng@...gle.com>, "Yamahata, Isaku" <isaku.yamahata@...el.com>,
	"binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>, "Peng, Chao P"
	<chao.p.peng@...el.com>, "Du, Fan" <fan.du@...el.com>, "Annapurve, Vishal"
	<vannapurve@...gle.com>, "jroedel@...e.de" <jroedel@...e.de>, "Miao, Jun"
	<jun.miao@...el.com>, "Shutemov, Kirill" <kirill.shutemov@...el.com>,
	"pgonda@...gle.com" <pgonda@...gle.com>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: [RFC PATCH 03/21] x86/virt/tdx: Add SEAMCALL wrapper
 tdh_mem_page_demote()

On Thu, 2025-05-15 at 10:28 -0700, Rick Edgecombe wrote:
> > I did a brief test on my SPR, where the host was not busy :
> > tdh_mem_page_demote() was called 142 times, with each invocation taking
> > around
> > 10us.
> 
> 10us doesn't seem too bad? Makes me think to not loop and instead just do a
> single retry with interrupts disabled. We should definitely add the data based
> reasoning to the log.
> 
> The counter point is that the SEAMCALL must be supporting
> TDX_INTERRUPTED_RESTARTABLE for a reason. And the reason probably is that it
> sometimes takes longer than someone that was reasonable. Maybe we should ask
> TDX
> module folks if there is any history.

Circling back here. After some research/discussion it seems demote should not
take too long such that it should need the option to return
TDX_INTERRUPTED_RESTARTABLE. Even in the dynamic PAMT case. The details of how
to get this changed and documented are still ongoing, but for v2 I say we close
this by expecting it to never return TDX_INTERRUPTED_RESTARTABLE. For now it can
be a VM_BUG_ON() case, with the expectation that TDX module will update to make
the logic valid. Sound good?