From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC3CF3D5666; Wed, 1 Apr 2026 09:26:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775035604; cv=none; b=rWqdRb5RC4Xl57quVLqmiqQMCbCinutvyL6JflGHyi+ve5CyBGci8/hN/vyhHuznL5enQZ+I9SO3ljue+CCssn6CWkeZP2ZBk+aAxQhaYhGDPxHDICmSHX+5/XS7351CLDebbEoNpXCSLOPr0b7fP7Cm2OkgUvDfMpjNj0NCLZM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775035604; c=relaxed/simple; bh=vQoKBDVUQCrnlg4i6bDknEFEH566QDHvDtOP+1cfVMg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IOV5KsbCMWK4FRgNJNAUC+Cbt3CaKb7m56EEKUJA8SoCKjwVVuN/yuPI4iy/a1F9d3FGiqSDLXa2SXBVQx4d1SFIvSDOtqgH4c8japxAWzEoeZ9xFSh3h13LvMIlgA2jSowP2DCYRF5PCaoGj+71+ERVhe6pD9iTXYoDH7HApGw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eR45Cdzx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eR45Cdzx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A197C2BCB3; Wed, 1 Apr 2026 09:26:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775035602; bh=vQoKBDVUQCrnlg4i6bDknEFEH566QDHvDtOP+1cfVMg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eR45CdzxqaI3lDQ63QkFzdtfXBmqNY89rHXpPWgx6IYd/FTqsAuqjVnYRkaYg354w mpKCbUWq8EBPaC7VG8xNk2kyqeSv+mLRoDfl+uaJlB0CKXQBYL4eIwUPPzeJ3WHI2p pPtUbf07viuu//7hVap18gAn5YuR6DwjNadGJjN1xaZuNKT5HBPVcVq9KnWdIwwEZC Z2XV9Ldz14b4vGzUWjf1JSxl7z4cMaFIRMup4/J8n+2w9YFUfBIBH3p2TSWdApDFof gDuqRIiO2oFy+n6HVFQab5JcL/veF62B/ujE17R7AtnjdQOReC2uM0Hkgvwy8eUMap 0gH1R1E9XO8LQ== Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfauth.phl.internal (Postfix) with ESMTP id 56C89F40079; Wed, 1 Apr 2026 05:26:41 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Wed, 01 Apr 2026 05:26:41 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgddvjeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epfffhvfevuffkfhggtggugfgjsehtkeertddttddunecuhfhrohhmpefmihhrhihlucfu hhhuthhsvghmrghuuceokhgrsheskhgvrhhnvghlrdhorhhgqeenucggtffrrghtthgvrh hnpeeludettdeigfefhffhhfelveeludeuleduvefhgefgueeitedtleffudegfffggfen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehkihhrih hllhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudeiudduiedvieehhedq vdekgeeggeejvdekqdhkrghspeepkhgvrhhnvghlrdhorhhgsehshhhuthgvmhhovhdrnh grmhgvpdhnsggprhgtphhtthhopedviedpmhhouggvpehsmhhtphhouhhtpdhrtghpthht oheprhhitghkrdhprdgvughgvggtohhmsggvsehinhhtvghlrdgtohhmpdhrtghpthhtoh epvhhishhhrghlrdhlrdhvvghrmhgrsehinhhtvghlrdgtohhmpdhrtghpthhtohepshgv rghnjhgtsehgohhoghhlvgdrtghomhdprhgtphhtthhopegsphesrghlihgvnhekrdguvg dprhgtphhtthhopeigkeeisehkvghrnhgvlhdrohhrghdprhgtphhtthhopehhphgrseii hihtohhrrdgtohhmpdhrtghpthhtohepmhhinhhgohesrhgvughhrghtrdgtohhmpdhrtg hpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhr tghpthhtohepuggrvhgvrdhhrghnshgvnheslhhinhhugidrihhnthgvlhdrtghomh X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 1 Apr 2026 05:26:40 -0400 (EDT) Date: Wed, 1 Apr 2026 10:26:39 +0100 From: Kiryl Shutsemau To: "Edgecombe, Rick P" Cc: "Verma, Vishal L" , "seanjc@google.com" , "bp@alien8.de" , "x86@kernel.org" , "hpa@zytor.com" , "mingo@redhat.com" , "linux-kernel@vger.kernel.org" , "dave.hansen@linux.intel.com" , "tglx@kernel.org" , "pbonzini@redhat.com" , "linux-coco@lists.linux.dev" , "kvm@vger.kernel.org" Subject: Re: [PATCH v2 3/5] x86/virt/tdx: Add SEAMCALL wrapper for TDH.SYS.DISABLE Message-ID: References: <20260323-fuller_tdx_kexec_support-v2-0-87a36409e051@intel.com> <20260323-fuller_tdx_kexec_support-v2-3-87a36409e051@intel.com> <944b3fe5fa8955319030a7dfc0ea164bb0266e68.camel@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <944b3fe5fa8955319030a7dfc0ea164bb0266e68.camel@intel.com> On Tue, Mar 31, 2026 at 09:36:03PM +0000, Edgecombe, Rick P wrote: > On Tue, 2026-03-31 at 18:22 +0000, Verma, Vishal L wrote: > > > > > > I guess the actual behaviour is dependant on the return code. It is > > > obviously going to be the case for TDX_SUCCESS. And from the discussion, > > > I guess that's true for TDX_SYS_BUSY and TDX_INTERRUPTED_RESUMABLE. > > > > > > What about other cases? The spec draft also lists TDX_SYS_NOT_READY and > > > TDX_SYS_SHUTDOWN. > > > > I think these are safe too - TDX_SYS_SHUTDOWN means the module has > > already been shutdown, which this seamcall would've done, so things > > should be in the same state either way. > > > > TDX_SYS_NOT_READY means the module hasn't been initialized yet. This > > seamcall should just exit, and the module is already blocking any > > seamcall that need the module to be initialized. The seamcalls to > > initialize the module will be allowed, as they are after a sys_disable > > call anyway. > > Should the seamcall return success in the case where it would return > TDX_SYS_NOT_READY? It is in basically a reset state right? The errors we care > about are actual errors (TDX_SW_ERROR), so it makes no difference to the code in > the patch. But it might be a nicer API for the seamcall? I am not sure. TDX_SYS_NOT_READY can be useful as might indicate mismatch of system state understanding between kernel and TDX module. > > > I wounder if it can affect the kernel. Consider the case when kexec > > > (crash kernel start) happens due to crash on TDX module. > > > > > > Will we be able to shutdown TDX module cleanly and make kexec safe? > > > > Hm  -are the semantics for what happens if there is a crash in the > > module defined? I meant kernel crash around/before TDX module initialization. Sorry for confusion. > > I think Linux should expect that sys_disable should > > either start doing its shutdown work, or exit with one of the other > > defined exit statuses. Anything else would be considered a module bug. > > We often have the question come up about how much we should to guard against > bugs in the TDX module. I tend to also think we should not do defensive > programming, same as we do for the kernel. If it's easy to handle something or > emit a warning it's nice, but otherwise the solution for such cases should be to > fix the TDX module bug. > > But for the kdump case, we don't actually need sys disable to succeed. The kdump > kernel will not load the TDX module. AFAIK, it is possible to start a normal kernel after kdump is done with kexec (requires memmap= tricks). And the normal kernel might want to use TDX again. Not sure if it is done in practice. I would rather go full reboot path after crash. > And as for the errata, this already needs a > special situation to be a problem. But even if it happens, I'd think better to > try to the kdump. Not sure what the fix would be for that scenario, even if we > allowed for a large complexity budget. So best effort seems good. > > Does it seem reasonable? I am probably too picky here. We want to start from make basic kexec functionality to work for start. Reviewed-by: Kiryl Shutsemau (Meta) -- Kiryl Shutsemau / Kirill A. Shutemov