Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1512592rwb; Tue, 29 Nov 2022 14:51:48 -0800 (PST) X-Google-Smtp-Source: AA0mqf67mN9e6q5Tz+UZqAQXQps4Z2aBR9+gxbLrSCZ5lknU2FjJe4lOek1MVv6o5gc/wcC1zhNA X-Received: by 2002:a17:902:7c0e:b0:189:907c:8390 with SMTP id x14-20020a1709027c0e00b00189907c8390mr10349674pll.126.1669762308111; Tue, 29 Nov 2022 14:51:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669762308; cv=none; d=google.com; s=arc-20160816; b=aVwjK1Csr2wN/eHx92TFgTlUXLEwi9yJhLCzJBXUbxAS1pX79gkNoLW+D0xAkJ+7Gb gTfWL8RNaNuxhhd6cWBfjFXts5nPdE7Y9JZdfkvKqG4K75dWmkkxzl/06D90nEgKpcnC hEuSJ4RVU2GJYf7IammYC3EZSaXNdCRHLZruYcVjYi3ruEgVD/UoFGwGttiFs9xypnJu 2VsDsSXZg/4exlMPsgDBAYVKeiKRrye4juylaNue6Jr7yzYqe5IaqDI5ekd4RBrbcQ0J 2Sw/nZEyxpeghh7i29Oo06IYAIY3Gf0jNNoJrvmY6aZ/wiNjLA0U0URK9CwpA3wSgV4U oGmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=AoiL/+sH237wd5cAPODtDaqXQh/u/za2cRkIoE8OAiY=; b=NPj3E6/dnrHIYS8ES4sHPtdt+dexmi6IevwMYiZx6AOBnK5VQQgS10iiy5oIlCLazh Z9AZvDHs6+4WssCYZJeM1w0o4sy2etfc6SjQf+2pcp2stk9CXg2Ru1xZJhpKjYMYLGj5 Oe/G++Qu14OpBnIe9uP+/ox7GTaiAloL5XNIncbGjcZA0UhCFUcUxqgiZ6hAML17TOsy 6rziYNtUo5Ki3JbDz0pTX6FfnIUTJdNe5arnrc58SO6+pQknJQWMRatrBP556LZFU5dt XV0KhFMWwc0MgO4lJSkoJTCbeYdhVQgMubow8nM9UEkE+3onsbvEkzLpujX58qJYuIjq wJig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=HmiGvt1g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x16-20020a63fe50000000b0046f4a36ae51si15069502pgj.710.2022.11.29.14.51.35; Tue, 29 Nov 2022 14:51:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=HmiGvt1g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236664AbiK2VlO (ORCPT + 84 others); Tue, 29 Nov 2022 16:41:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233312AbiK2VlL (ORCPT ); Tue, 29 Nov 2022 16:41:11 -0500 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E37F36153D; Tue, 29 Nov 2022 13:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669758069; x=1701294069; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=H6tFVx8YFjtrsgdtfWkCGSXF6RRdlIaHy4IaUji1afk=; b=HmiGvt1gimf6ExTwmEFjFmBYmeAkNnUMelYukCxCCT1odTfHQHWkdh+1 iq9VZn5UvpKZ3ItRwe2Mg2KtnbIDQHMjxPKcBk7zGlAe8ZcMU2vuoPfdA JO6r/SVLoA1PnLiaN380kxu/mBjYo36XNWegtvkNmx1lkxviys3JDKvW+ oATSNjk+ayk1rAY/S/b58W8bCg238m1KZcCMaYzhAUDNaGI/l+hbQVCce RTos1vI7fNgL1k2GIamdDRlcJeXs3GHE9K3Ro/aNFmG4Wu/sQMwFEV4ME +UxrG85Yxtk4GHpoDilSQ/EV85qu1f/ocjDuhuGpHpncRXGJhrtPmXVNh g==; X-IronPort-AV: E=McAfee;i="6500,9779,10546"; a="379521175" X-IronPort-AV: E=Sophos;i="5.96,204,1665471600"; d="scan'208";a="379521175" 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 X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.