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 4DFF5C4321E for ; Tue, 29 Nov 2022 21:41:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF06C6B0073; Tue, 29 Nov 2022 16:41:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CA0386B0074; Tue, 29 Nov 2022 16:41:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B8F4C6B0075; Tue, 29 Nov 2022 16:41:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id AA8356B0073 for ; Tue, 29 Nov 2022 16:41:11 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 704931C6925 for ; Tue, 29 Nov 2022 21:41:11 +0000 (UTC) X-FDA: 80187800742.03.C8618B0 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf09.hostedemail.com (Postfix) with ESMTP id 7EA8C140010 for ; Tue, 29 Nov 2022 21:41:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669758070; x=1701294070; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=H6tFVx8YFjtrsgdtfWkCGSXF6RRdlIaHy4IaUji1afk=; b=YQKqEkxAp65O7R3HWl+OxTIR+KC6W7jvYFhvSOwb3TjBmmf8V4axQ//y CXjku1ri9FLzwNgvimEt+nb6R9ivTUrUPAkXfWitmNQKeCV5wJegsoCgr 8Gj4v5H45n0C5ZXBEGrDBJH7n0cekssox02J+vVNOPzsXUCSfTKLwyfXy itVaOi7JpiBiX0IHxPsr2ESdAptpHdbVMfC6reCLpxBHKUEs/7xHTIdDB Ianz7GpL5mBei+GcqAa5I2T0frNK6Jp3V87YCAOn0TN7LftqyahNcFYbC bGJWMFJKKePamHF2K3jIdpVizEgM8al8Z1om2fNa27hv6Ibp90SdLSVWi g==; X-IronPort-AV: E=McAfee;i="6500,9779,10546"; a="379521177" X-IronPort-AV: E=Sophos;i="5.96,204,1665471600"; d="scan'208";a="379521177" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Nov 2022 13:40:56 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10546"; a="637757920" X-IronPort-AV: E=Sophos;i="5.96,204,1665471600"; d="scan'208";a="637757920" Received: from wteng-mobl1.gar.corp.intel.com (HELO [10.209.83.194]) ([10.209.83.194]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Nov 2022 13:40:56 -0800 Message-ID: Date: Tue, 29 Nov 2022 13:40:55 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v7 06/20] x86/virt/tdx: Shut down TDX module in case of error Content-Language: en-US To: 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 References: <48505089b645019a734d85c2c29f3c8ae2dbd6bd.1668988357.git.kai.huang@intel.com> <52b2be9b-defd-63ce-4cb2-96cd624a95a6@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669758071; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=AoiL/+sH237wd5cAPODtDaqXQh/u/za2cRkIoE8OAiY=; b=NERXevdIxxLCjFdVPinBniHG5qyEqn7IHKk25Uqyg/PI5kYMah5Nzgfcs0JXtXcEbUMcUU XZ8d8GrioXnWwJMcGzgi3ru4yHTIPERl82xgKzsIJ55NLF741L3HjWwrxuwX6VnJI25Vjk 8HTP6lft6Ew0wF/oTxfiLmqW1Eh7P6w= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=YQKqEkxA; spf=pass (imf09.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669758071; a=rsa-sha256; cv=none; b=a8+qZ64ag7Sgw7y0KBuGOMQYvSRkWXc9GkUYO3aqET5aPOuabP3WFKLx0Ea4vSX2Q6D4k2 5ecm1WfWeRpJQ9QOwft+gUsZO/5slhU3cMcDWGurUhlta6ucel+ad4YLnZQ2Hf92XG7R2v fQtW8ifbjFtaJm4g8IhY/CPUErE/VQI= X-Stat-Signature: m3bctygrzwa33sdf6ckpjm9ugzeeyuk3 X-Rspamd-Queue-Id: 7EA8C140010 Authentication-Results: imf09.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=YQKqEkxA; spf=pass (imf09.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam06 X-Rspam-User: X-HE-Tag: 1669758070-759409 X-Bogosity: Ham, tests=bogofilter, spamicity=0.146929, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 11/22/22 11:33, Peter Zijlstra wrote: > On Tue, Nov 22, 2022 at 11:24:48AM -0800, Dave Hansen wrote: >>> Not intialize TDX on busy NOHZ_FULL cpus and hard-limit the cpumask of >>> all TDX using tasks. >> I don't think that works. As I mentioned to Thomas elsewhere, you don't >> just need to initialize TDX on the CPUs where it is used. Before the >> module will start working you need to initialize it on *all* the CPUs it >> knows about. The module itself has a little counter where it tracks >> this and will refuse to start being useful until it gets called >> thoroughly enough. > That's bloody terrible, that is. How are we going to make that work with > the SMT mitigation crud that forces the SMT sibilng offline? > > Then the counters don't match and TDX won't work. > > 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. In the end, we could just plain stop doing the TDH.SYS.LP.INIT code in the kernel. Unless someone screams, I'll ask the BIOS and TDX module folks to look into this.