From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57D07C433FE for ; Wed, 30 Nov 2022 11:09:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5BDF76B0072; Wed, 30 Nov 2022 06:09:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 56D8F6B0073; Wed, 30 Nov 2022 06:09:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 435306B0074; Wed, 30 Nov 2022 06:09:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 352C36B0072 for ; Wed, 30 Nov 2022 06:09:35 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id ED9B914118F for ; Wed, 30 Nov 2022 11:09:34 +0000 (UTC) X-FDA: 80189837868.27.0EDB578 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf23.hostedemail.com (Postfix) with ESMTP id 2E8C2140004 for ; Wed, 30 Nov 2022 11:09:33 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1669806571; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MvqyMuu+fchlheOOfrdAvjlih/M5WR5M5RpN8mJB+yY=; b=ghOwL7RD9WNURgySY1WKVGLrOID94BHn6fpmocLRPbGRFOeKZHUVq9aB3J1ZZ4L8o49VMm 24ntzPWQ6niPefDsaISX4bF33A92fQvUKU4TXvr4rNVsp991VMrux0YnGJ6Mmsis+jquoG h5GvWPk8ZtIsMPgnrFpQaVF+H9vC0xQ6Je6HUmAmeBSEnKstrc7b+ollPuW/kqp1SNZ+V8 yLBdGqp7SCtsGYvEj+oRBDkMWjh4tj5nPPGm7hx2ojLzWhCUFXqRhNhFlRfhOEgfe8atSS oEYpEjYQH6ppvFVmb5vUf+5dAAdcBunc4bvvatyZw2e++1NG5+Nf5X21cyB9kg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1669806571; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MvqyMuu+fchlheOOfrdAvjlih/M5WR5M5RpN8mJB+yY=; b=gkI0qz9pbuppHopjt8ePUjiZ2Blkq12mTQAdsyRelbVT7N6T7rH4i8xfXoDnNLOoiGQhyZ HIkO9iflOdyoMiCQ== To: Dave Hansen , Peter Zijlstra Cc: Kai Huang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, seanjc@google.com, pbonzini@redhat.com, dan.j.williams@intel.com, rafael.j.wysocki@intel.com, kirill.shutemov@linux.intel.com, ying.huang@intel.com, reinette.chatre@intel.com, len.brown@intel.com, tony.luck@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com Subject: Re: [PATCH v7 06/20] x86/virt/tdx: Shut down TDX module in case of error In-Reply-To: References: <48505089b645019a734d85c2c29f3c8ae2dbd6bd.1668988357.git.kai.huang@intel.com> <52b2be9b-defd-63ce-4cb2-96cd624a95a6@intel.com> Date: Wed, 30 Nov 2022 12:09:31 +0100 Message-ID: <87h6ygu2ac.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669806574; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=MvqyMuu+fchlheOOfrdAvjlih/M5WR5M5RpN8mJB+yY=; b=5U69MOLcPgcF5x/oW9mLBxapk+WOwk9XGb/aPrz5qAsD3mpLRHZxR34WGaswd6wIIsnCeY tg495skTzc6Zhxvd5M5/WW2fBDErro65UbaiXvwbghoHFULFkaGNWHqCTNkLSVEwe/nvP+ vHwRzNNopuN0wdO3DxEWYNDjhrdTnOA= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=ghOwL7RD; dkim=pass header.d=linutronix.de header.s=2020e header.b=gkI0qz9p; spf=pass (imf23.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669806574; a=rsa-sha256; cv=none; b=pbQl3gQMUaY+w0Z/3saot8emMEMkpIu2Z/Da4LmMkEs77QbifMxhxAB/qyynGyNSJSzRdk EJVF3Ot9RkioOC9cMrr5iGbIi/oXtJVQT1JjRoz2ftHnO09XjJYn9sei5Mo3CmsNFTGyJv LfOdHm3+Wff04Mhuz+yoyPoDYMxiIKQ= X-Stat-Signature: 6ejf3jf1ypyk8ozp3tfyhkrxmup3scgy X-Rspamd-Queue-Id: 2E8C2140004 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=ghOwL7RD; dkim=pass header.d=linutronix.de header.s=2020e header.b=gkI0qz9p; spf=pass (imf23.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de X-Rspamd-Server: rspam06 X-Rspam-User: X-HE-Tag: 1669806573-328088 X-Bogosity: Ham, tests=bogofilter, spamicity=0.056706, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 29 2022 at 13:40, Dave Hansen wrote: > On 11/22/22 11:33, Peter Zijlstra wrote: >> Can we get this limitiation removed and simply let the module throw a >> wobbly (error) when someone tries and use TDX without that logical CPU >> having been properly initialized? > > It sounds like we can at least punt the limitation away from the OS's > purview. > > There's actually a multi-step process to get a "real" TDX module loaded. > There's a fancy ACM (Authenticated Code Module) that's invoked via > GETSEC[ENTERACCS] and an intermediate module loader. That dance used to > be done in the kernel, but we talked the BIOS guys into doing it instead. > > I believe these per-logical-CPU checks _can_ also be punted out of the > TDX module itself and delegated to one of these earlier module loading > phases that the BIOS drives. > > I'm still a _bit_ skeptical that the checks are needed in the first > place. But, as long as they're hidden from the OS, I don't see a need > to be too cranky about it. Right. > In the end, we could just plain stop doing the TDH.SYS.LP.INIT code in > the kernel. Which in turn makes all the problems we discussed go away. > Unless someone screams, I'll ask the BIOS and TDX module folks to look > into this. Yes, please. Thanks, tglx