From patchwork Tue Oct 17 10:14:25 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154034 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4030429vqb; Tue, 17 Oct 2023 03:16:49 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHoU1nKbxbb/wi1BVC4DvMva1HoaKmJbWOh04XvRZczkWIO5ZRvHrhHZfj1W2ZuEpWUdJiS X-Received: by 2002:a05:6870:3c88:b0:1bf:9fa2:bfa3 with SMTP id gl8-20020a0568703c8800b001bf9fa2bfa3mr2030234oab.1.1697537809110; Tue, 17 Oct 2023 03:16:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537809; cv=none; d=google.com; s=arc-20160816; b=aSu8a55HwRgM1dkDuS197Huxg4vMfon6uxexP1fhE/upVlRN3SDr+xFXgpFNXc18EE dRQh0xbxzYKKXR/l1fhgJvTgDthUUz6yZaZcc5MDBqtB7QiqgORxKQUFTWCKJV0F9UVY etopz6ZuIzI1kSNDeMd4vtzQuQ6oEdFfD302qpLe1EJOvvuMVdyuPJ8z0qZvJGrdq3JJ XHOQMvK4M1PhE7Ym/OwQNP5sMsjIGc3m0HCqtqrUa4ckv/lItMqworgUKjqbW5aRbU6F 9oKsLZjXzK8oQbSyfflpVrLKUvMkn1Fm6cf9X+1KWqZIN8N78oIxa4xLmoLboBjWyvrB e/xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=1JjN4QSSmR5pNsvj01lSnDHTqOqiRjo2Y82VTOTR9wY=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=WPgzSD2SBmvpSjWEESFXHkw206kL9zPx+/zR/syG8QVc6za501zNReLCk4CK3XbU6e V/QokpM4VB0yXDIN17QIengytABAQoEwiM4b7B6aw7uj8skbei8/RN+xGgCdD3qNvgel oW4e78NsPVESuOacMYCdbwp26z43YjIQyI7fgwTNSK33kmOoHInFCDux5VcgnIwznnCt PCQmvqgcwSjQidip6ehMK5CJHRWdt3rntV+c5MLIk9BQB9s8Xtwf9wr9awpcuMPLlsIn GnitGQ3l9jJR6ZjqeVtq0B1HIUOUxoXO3KrqxkFTMm3X04aBgoi2yeRyw7I1Cz2x0Hoi Ehmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Wqp8AOXt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id j70-20020a638049000000b00573fc71f6d9si1513554pgd.64.2023.10.17.03.16.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:16:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Wqp8AOXt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 9EE75808725E; Tue, 17 Oct 2023 03:15:39 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234953AbjJQKPZ (ORCPT + 19 others); Tue, 17 Oct 2023 06:15:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234934AbjJQKPS (ORCPT ); Tue, 17 Oct 2023 06:15:18 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96905F9; Tue, 17 Oct 2023 03:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537710; x=1729073710; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=kVsmePzX+1CQEv8I/jGhrQ8MKt6j8PZKIuV1GGpP0v4=; b=Wqp8AOXtWEgAPTlcGGjYRLIX7pk0mTfu/K0CwzONeOpvmV/zhs6znZHP 550X5WvxRCuyB3Uj3K9XqGqFhZ/izIjHlNQaK3TUgTt9sCsKVdrghvKcK t9clgeMeb3+cjOb0dNNgkPQ8aPEkk85raBg4+jnya5NwldQ4fPBB8AF1t kxiWe/vxLO5z4zBcJMSS6+15G5/rCDNhucwsRMpoJQ98sxy2psLbeHiym HdtcXQJocEHtn3NXIUtP3+Vrgh+6A+5sQUamNZSADpUAoh68pt8LwyzGl lJ9Cs3IqLgImHg2RcMAjgHb8XVzOfgr5PB2SHB2MoLsOgSZfyS9SgV1zy g==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="452226684" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="452226684" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503268" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503268" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:04 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 01/23] x86/virt/tdx: Detect TDX during kernel boot Date: Tue, 17 Oct 2023 23:14:25 +1300 Message-ID: <121aab11b48b4e6550cfe6d23b4daab744ee2076.1697532085.git.kai.huang@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:15:39 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997405941679035 X-GMAIL-MSGID: 1779997405941679035 Intel Trust Domain Extensions (TDX) protects guest VMs from malicious host and certain physical attacks. A CPU-attested software module called 'the TDX module' runs inside a new isolated memory range as a trusted hypervisor to manage and run protected VMs. Pre-TDX Intel hardware has support for a memory encryption architecture called MKTME. The memory encryption hardware underpinning MKTME is also used for Intel TDX. TDX ends up "stealing" some of the physical address space from the MKTME architecture for crypto-protection to VMs. The BIOS is responsible for partitioning the "KeyID" space between legacy MKTME and TDX. The KeyIDs reserved for TDX are called 'TDX private KeyIDs' or 'TDX KeyIDs' for short. During machine boot, TDX microcode verifies that the BIOS programmed TDX private KeyIDs consistently and correctly programmed across all CPU packages. The MSRs are locked in this state after verification. This is why MSR_IA32_MKTME_KEYID_PARTITIONING gets used for TDX enumeration: it indicates not just that the hardware supports TDX, but that all the boot-time security checks passed. The TDX module is expected to be loaded by the BIOS when it enables TDX, but the kernel needs to properly initialize it before it can be used to create and run any TDX guests. The TDX module will be initialized by the KVM subsystem when KVM wants to use TDX. Add a new early_initcall(tdx_init) to detect the TDX by detecting TDX private KeyIDs. Also add a function to report whether TDX is enabled by the BIOS. Similar to AMD SME, kexec() will use it to determine whether cache flush is needed. The TDX module itself requires one TDX KeyID as the 'TDX global KeyID' to protect its metadata. Each TDX guest also needs a TDX KeyID for its own protection. Just use the first TDX KeyID as the global KeyID and leave the rest for TDX guests. If no TDX KeyID is left for TDX guests, disable TDX as initializing the TDX module alone is useless. Signed-off-by: Kai Huang Reviewed-by: Kirill A. Shutemov Reviewed-by: Isaku Yamahata Reviewed-by: David Hildenbrand Reviewed-by: Dave Hansen Reviewed-by: Kuppuswamy Sathyanarayanan --- v13 -> v14: - "tdx:" -> "virt/tdx:" (internal) - Add Dave's tag --- arch/x86/include/asm/msr-index.h | 3 ++ arch/x86/include/asm/tdx.h | 4 ++ arch/x86/virt/vmx/tdx/Makefile | 2 +- arch/x86/virt/vmx/tdx/tdx.c | 90 ++++++++++++++++++++++++++++++++ 4 files changed, 98 insertions(+), 1 deletion(-) create mode 100644 arch/x86/virt/vmx/tdx/tdx.c diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h index 1d111350197f..7a44cac70e9f 100644 --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -535,6 +535,9 @@ #define MSR_RELOAD_PMC0 0x000014c1 #define MSR_RELOAD_FIXED_CTR0 0x00001309 +/* KeyID partitioning between MKTME and TDX */ +#define MSR_IA32_MKTME_KEYID_PARTITIONING 0x00000087 + /* * AMD64 MSRs. Not complete. See the architecture manual for a more * complete list. diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h index adcbe3f1de30..a252328734c7 100644 --- a/arch/x86/include/asm/tdx.h +++ b/arch/x86/include/asm/tdx.h @@ -81,6 +81,10 @@ static inline long tdx_kvm_hypercall(unsigned int nr, unsigned long p1, u64 __seamcall(u64 fn, struct tdx_module_args *args); u64 __seamcall_ret(u64 fn, struct tdx_module_args *args); u64 __seamcall_saved_ret(u64 fn, struct tdx_module_args *args); + +bool platform_tdx_enabled(void); +#else +static inline bool platform_tdx_enabled(void) { return false; } #endif /* CONFIG_INTEL_TDX_HOST */ #endif /* !__ASSEMBLY__ */ diff --git a/arch/x86/virt/vmx/tdx/Makefile b/arch/x86/virt/vmx/tdx/Makefile index 46ef8f73aebb..90da47eb85ee 100644 --- a/arch/x86/virt/vmx/tdx/Makefile +++ b/arch/x86/virt/vmx/tdx/Makefile @@ -1,2 +1,2 @@ # SPDX-License-Identifier: GPL-2.0-only -obj-y += seamcall.o +obj-y += seamcall.o tdx.o diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c new file mode 100644 index 000000000000..13d22ea2e2d9 --- /dev/null +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -0,0 +1,90 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright(c) 2023 Intel Corporation. + * + * Intel Trusted Domain Extensions (TDX) support + */ + +#define pr_fmt(fmt) "virt/tdx: " fmt + +#include +#include +#include +#include +#include +#include +#include +#include + +static u32 tdx_global_keyid __ro_after_init; +static u32 tdx_guest_keyid_start __ro_after_init; +static u32 tdx_nr_guest_keyids __ro_after_init; + +static int __init record_keyid_partitioning(u32 *tdx_keyid_start, + u32 *nr_tdx_keyids) +{ + u32 _nr_mktme_keyids, _tdx_keyid_start, _nr_tdx_keyids; + int ret; + + /* + * IA32_MKTME_KEYID_PARTIONING: + * Bit [31:0]: Number of MKTME KeyIDs. + * Bit [63:32]: Number of TDX private KeyIDs. + */ + ret = rdmsr_safe(MSR_IA32_MKTME_KEYID_PARTITIONING, &_nr_mktme_keyids, + &_nr_tdx_keyids); + if (ret) + return -ENODEV; + + if (!_nr_tdx_keyids) + return -ENODEV; + + /* TDX KeyIDs start after the last MKTME KeyID. */ + _tdx_keyid_start = _nr_mktme_keyids + 1; + + *tdx_keyid_start = _tdx_keyid_start; + *nr_tdx_keyids = _nr_tdx_keyids; + + return 0; +} + +static int __init tdx_init(void) +{ + u32 tdx_keyid_start, nr_tdx_keyids; + int err; + + err = record_keyid_partitioning(&tdx_keyid_start, &nr_tdx_keyids); + if (err) + return err; + + pr_info("BIOS enabled: private KeyID range [%u, %u)\n", + tdx_keyid_start, tdx_keyid_start + nr_tdx_keyids); + + /* + * The TDX module itself requires one 'global KeyID' to protect + * its metadata. If there's only one TDX KeyID, there won't be + * any left for TDX guests thus there's no point to enable TDX + * at all. + */ + if (nr_tdx_keyids < 2) { + pr_err("initialization failed: too few private KeyIDs available.\n"); + return -ENODEV; + } + + /* + * Just use the first TDX KeyID as the 'global KeyID' and + * leave the rest for TDX guests. + */ + tdx_global_keyid = tdx_keyid_start; + tdx_guest_keyid_start = tdx_keyid_start + 1; + tdx_nr_guest_keyids = nr_tdx_keyids - 1; + + return 0; +} +early_initcall(tdx_init); + +/* Return whether the BIOS has enabled TDX */ +bool platform_tdx_enabled(void) +{ + return !!tdx_global_keyid; +} From patchwork Tue Oct 17 10:14:26 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154032 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4030290vqb; Tue, 17 Oct 2023 03:16:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF9NxHwRRc3kTJ3q68yt4r4x43ZQuWIgWZqx7TtGac08ktaY55So82C0qr9m6rpGBa6A1RI X-Received: by 2002:a05:6a21:819b:b0:163:ab09:195d with SMTP id pd27-20020a056a21819b00b00163ab09195dmr1748721pzb.0.1697537788839; Tue, 17 Oct 2023 03:16:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537788; cv=none; d=google.com; s=arc-20160816; b=UYRQZNSzBhodeuYgPnsHeY0ghgiEEM3zIWmJEmEx1FvFAi9ebNmFBDLDR3H6AwuFSw zdCCaXWO5+c61wL0zZKGdB2ZZsGzX62iwaEAJE+VzHuvDhu3LAAf0GF7tOw/VWwANS9A Y6YkhkG6ZQmt8NWiSFzc2NGBq3L5Q/zy9aKXaFZdqZSOGiNLygKV0spxFkP04MRVWnB3 TtGFAH5536RMTAqtvOQRnFRJGyOB4cu/dIPTu8wFkN351M3ioSbQP+0HuQRYEg79Ep3V 2l+UN4uUDP+bZ/nA5mF127RGYedRU2RtXUiy4FYS44klc6KK/0FUILIjU3Cqd0gEDo1x C1yw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=k5tDjQfBNxvLM5LZGQiqKMvLf1T2C3qfidGXJLyQvpY=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=FRAtU6peOlc/oRd0dwL7VwP6dLf/b2kSw4Y4siyZFkLkD31DBuS2n9DXTRQFDLJdIU vNEoIhcouBaEL88p0EwdkB7NvY8lovdLf+gsLR8pxgQHutxBO9PWb/1QCBIoMC6NHsoj TsGcLSKM3CPVC5JLRcxeEzhCUOTr7WgkXvLuLYQhukHvPRE8nwp3PSbVhYR40XVUnWzH IuYdrkO75anibuIdZ97g3TNS7OPgnU+f7L4dCecRqHd1hmuG8u2tSDFb/ywKqKobiCjo m1DQfwbMgZ9vROpT9YNExGz9qg/ow5TnteNb/t07+NsoD3x5x+kvUwfhe25mIBIfL0yf mi+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=PYsjRUDZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from pete.vger.email (pete.vger.email. [23.128.96.36]) by mx.google.com with ESMTPS id x9-20020a634a09000000b0059f0cebd054si1495107pga.731.2023.10.17.03.16.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:16:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=PYsjRUDZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id A292980811CF; Tue, 17 Oct 2023 03:16:26 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343650AbjJQKP3 (ORCPT + 19 others); Tue, 17 Oct 2023 06:15:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32866 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234961AbjJQKPU (ORCPT ); Tue, 17 Oct 2023 06:15:20 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77025110; Tue, 17 Oct 2023 03:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537717; x=1729073717; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=O346axwYIYjErdUjyjATGQeph23hs/98nSQYxN/B3uE=; b=PYsjRUDZ1pS7p6CcAg25apm/BW2xzPY0M+FSQxbOCRpm9OHFER468brE Fvj+HjnoYJI2Xxc107HUYX81tNmORh5hFNhhVJhubEeQ6ZN1IEdmF/yMP RSoROgnGPb9ZztImh1Yfw9PyeWo+Wj0UVz1AzCaPO3uGSsry//W4IMvgM X7mgB0T6sKPeOMpm/BXaTl3Jm0+127/zo330YfQ4aDj8y0nuvIahJfe1x LcaJGhHTGouaPdKcCR83Gek9epC/KUUEBOhMfgJV89H2h02Dakq/bR+qO dzPusNSs9dytbLrhw1EeQuSXi4pS2xOGH+//Gggx+ONop1BNJmDBtO0AY g==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="452226702" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="452226702" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503344" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503344" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:10 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 02/23] x86/tdx: Define TDX supported page sizes as macros Date: Tue, 17 Oct 2023 23:14:26 +1300 Message-ID: X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:16:26 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997384219668606 X-GMAIL-MSGID: 1779997384219668606 TDX supports 4K, 2M and 1G page sizes. The corresponding values are defined by the TDX module spec and used as TDX module ABI. Currently, they are used in try_accept_one() when the TDX guest tries to accept a page. However currently try_accept_one() uses hard-coded magic values. Define TDX supported page sizes as macros and get rid of the hard-coded values in try_accept_one(). TDX host support will need to use them too. Signed-off-by: Kai Huang Reviewed-by: Kirill A. Shutemov Reviewed-by: Dave Hansen Reviewed-by: David Hildenbrand --- arch/x86/coco/tdx/tdx-shared.c | 6 +++--- arch/x86/include/asm/shared/tdx.h | 5 +++++ 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/arch/x86/coco/tdx/tdx-shared.c b/arch/x86/coco/tdx/tdx-shared.c index 78e413269791..1655aa56a0a5 100644 --- a/arch/x86/coco/tdx/tdx-shared.c +++ b/arch/x86/coco/tdx/tdx-shared.c @@ -22,13 +22,13 @@ static unsigned long try_accept_one(phys_addr_t start, unsigned long len, */ switch (pg_level) { case PG_LEVEL_4K: - page_size = 0; + page_size = TDX_PS_4K; break; case PG_LEVEL_2M: - page_size = 1; + page_size = TDX_PS_2M; break; case PG_LEVEL_1G: - page_size = 2; + page_size = TDX_PS_1G; break; default: return 0; diff --git a/arch/x86/include/asm/shared/tdx.h b/arch/x86/include/asm/shared/tdx.h index f74695dea217..abcca86b5af3 100644 --- a/arch/x86/include/asm/shared/tdx.h +++ b/arch/x86/include/asm/shared/tdx.h @@ -54,6 +54,11 @@ (TDX_RDX | TDX_RBX | TDX_RSI | TDX_RDI | TDX_R8 | TDX_R9 | \ TDX_R10 | TDX_R11 | TDX_R12 | TDX_R13 | TDX_R14 | TDX_R15) +/* TDX supported page sizes from the TDX module ABI. */ +#define TDX_PS_4K 0 +#define TDX_PS_2M 1 +#define TDX_PS_1G 2 + #ifndef __ASSEMBLY__ #include From patchwork Tue Oct 17 10:14:27 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154029 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4030169vqb; Tue, 17 Oct 2023 03:16:14 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG1kWNzLa/31dOdgly8PBVObszlzGspF44UEYWZKKTyjEw12xKmBMdwtgM6dEuEGxCEV0NP X-Received: by 2002:a17:903:6c8:b0:1ca:273d:22f with SMTP id kj8-20020a17090306c800b001ca273d022fmr1874180plb.0.1697537774676; Tue, 17 Oct 2023 03:16:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537774; cv=none; d=google.com; s=arc-20160816; b=fE6L847PzpeYsHKLjQRDEKA8mWW+g9ec147buP119otQ2fc6kxyKOeSatSgMb8oBla ZYOdyb7fOgEVh3enO/uWv2kmY2MifWp33uPlKwrFkVN06davRraR4D/T5C7ZIMSo22yo sA3FjmIHvJB60IHNTVCg1G138e6ML6WUaZ6/9hd8Ocl5EgQ8Yg2KToatzLi4LkD+tzfo HwzQg0DGikSR67ODtjWth3F5yWUmYeKOx1AZ7wdar6nO+IB4howqqnbvsIlFS4x1opQw 33HEC//FG8Ch99sIyxosgNqhCwtqpUvYx7Nqb3AT4QIWDngFwczenvqDDI2nDokXzY+5 5SCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=AFwXXwTltxlKbip0e8MQ4zvuOXzx1OUft/+3dVD/KO8=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=DZ2nFERCmFuXGIpQ7exJItpkurr1x25243b7fSAJNNNWe+ItZKbWRyZQkblsna4YkD j3PaWqokNq3yqBM81xoQadVWdzOvlDjjOW20t9q4hj3GwySaT0gko73jNeN9WX+Raq5S Utu+/LV8B9MYihn4Jhrar3buHNIjAqP+gjHmccjjt+7c1pn+y6heR4CsgKJVSrXTMHC0 FP09sorFi4+TRDXIbvfJFbRGuo/QN+TUZjTGLqGgtQjz9Ri2hcyDcum06epOvQ1/+j9P VgduP0TPnZxBJZoirvOVc8zubmVm48zWvMfS9YpindMARXAXeG1EWiHrW+qVDCymlEOo EZUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="Fjk+Ygx/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id m9-20020a170902768900b001c9ad2bc71esi1383984pll.251.2023.10.17.03.16.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:16:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="Fjk+Ygx/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 7BACA8097E70; Tue, 17 Oct 2023 03:15:52 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235018AbjJQKPj (ORCPT + 19 others); Tue, 17 Oct 2023 06:15:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234978AbjJQKPZ (ORCPT ); Tue, 17 Oct 2023 06:15:25 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1481110C; Tue, 17 Oct 2023 03:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537723; x=1729073723; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=M13wjUUNn+5qp3WHcPzQPPn/BLcPZthn3SrCaY2RDNA=; b=Fjk+Ygx/sYurk/wjeCAYcQR8CIib5ZGA3xt/qK5nKjf2olL4nRjcZ5Gc EQz3p9iG/Wqrd63PWRbvVe7H18SJWDsv+Btb/phsrLYTcK5JEN0mXbk4P yudgSrErmU9Ra5aPdtCihBQoKNueBHyq3bmd9dNFQedT8p6ReRNzf2ZJJ sRa0dJMucJLiSTIJaCDIk4CT8h/J1oBtZ891vD21nBqWVr8fXqRJLbDdo oBV/0qk+YowHWnNFuZ6BoxXuEaMahKjBa8kNdE6FkvsUjXJ/m6mW2GjiF UPQgcGI9mOQIfTBzXXnS+0U45+pRO3UC2R/qwjSxlsP3v4vwjVSjKYI6D g==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="452226726" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="452226726" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503372" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503372" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:16 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 03/23] x86/virt/tdx: Make INTEL_TDX_HOST depend on X86_X2APIC Date: Tue, 17 Oct 2023 23:14:27 +1300 Message-ID: X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:15:52 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997369950518361 X-GMAIL-MSGID: 1779997369950518361 TDX capable platforms are locked to X2APIC mode and cannot fall back to the legacy xAPIC mode when TDX is enabled by the BIOS. TDX host support requires x2APIC. Make INTEL_TDX_HOST depend on X86_X2APIC. Link: https://lore.kernel.org/lkml/ba80b303-31bf-d44a-b05d-5c0f83038798@intel.com/ Signed-off-by: Kai Huang Reviewed-by: Dave Hansen Reviewed-by: David Hildenbrand Reviewed-by: Kirill A. Shutemov --- arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 3b3594f96330..a70f3f205969 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1944,6 +1944,7 @@ config INTEL_TDX_HOST depends on CPU_SUP_INTEL depends on X86_64 depends on KVM_INTEL + depends on X86_X2APIC help Intel Trust Domain Extensions (TDX) protects guest VMs from malicious host and certain physical attacks. This option enables necessary TDX From patchwork Tue Oct 17 10:14:28 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154031 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4030282vqb; Tue, 17 Oct 2023 03:16:28 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF3FM+Ypv052m1+JiT0ZrOUxTN2AMJc0YLqCVAVoyxztx7YnqQPvztOTY+ufFLbbM7bXOAX X-Received: by 2002:a05:6a00:180f:b0:68f:c8b3:3077 with SMTP id y15-20020a056a00180f00b0068fc8b33077mr1783046pfa.1.1697537788204; Tue, 17 Oct 2023 03:16:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537788; cv=none; d=google.com; s=arc-20160816; b=lJ8wYMbamBm6pMFWj6irOHYehY2us4aRZ265D6DFpFcZZT4yvsDbl6cbUuT9cOl1tf LnNnlIwF8Of93g28ylVJpxTPDBVGT/3DytxVBvlJe8GfoSqV59kvv4uPT5V4tnzATYsG Z228ZowdIQaZIZ75di0pr7woF6Rx4/IXvop8KFDnzfyyGRobW6bLoFuj8hETvLjgCfgf OgzHjv2O4BYneyvolqAvuVBUT8VE5rMqro2Sd46JrTYbxy+JrW6wdKQO20MyD1Bw0sdu dsufdOaBTHJJs89At5VQtT4JgP+V3ix1lAySzmkfsGZ6RWTQbXIwjrCDJ9mfJY0xHUGY BCDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=/Ao4h/YUgQc5L5lTwE59SI87Y1OOl24PQkCaQpx5enc=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=vDVqRVE3OtUtg3UZSTsGoHgMRzrl0/YKnMzSE5XCLUoYX9HS9D4M+Rz+xYcZCVhClf j9F6ShMZ7Xun7u7Cjn3Z9EZrmAkQ7vHOycj5PlDA66Wh/UIJ9otDUSGPHkd0oWWqPuQg /wjJjlE0rvg8XrtXxg5ChUsJai7fUGG9kwiwBpqZbgOr816eEgI4/haY0NcrnybZsBWR LoMSjdVCNpqB2qQNExr5q+ndJk0woXSGjmvTYzIZnswfewir2pyzEYq8QpGHXVkujmNB erBdHgG3JF6+XHidExePbo8Eugdc1v0b+S8ZwQaH8YJ7pbHpIelhwP0zUQ4iyos6fPpP hfYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=NtafQfAf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id t16-20020a056a00139000b0069343bdd500si1361122pfg.319.2023.10.17.03.16.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:16:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=NtafQfAf; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id A7A268092151; Tue, 17 Oct 2023 03:16:25 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234952AbjJQKPv (ORCPT + 19 others); Tue, 17 Oct 2023 06:15:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343669AbjJQKPg (ORCPT ); Tue, 17 Oct 2023 06:15:36 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F2B5A114; Tue, 17 Oct 2023 03:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537728; x=1729073728; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=9eWwv81lMEyDh8uBfXs//Bh+mi0iS4thcECNF/TDgtQ=; b=NtafQfAfZGAqe6Ija1JKZuWQDCm/ZlcB7TL2TqAzCbvlYiDhOIt/UYoz nsVmPGSKMIvZOu1OhxNzXcn7EKQsgVgqRX6CaXloS5QZdk59AuFouE0Do KxxCq7+tSqR5aw3c4wwj0IgyndYRhwugog8HOCoA1KecrhnVMYenKSFKn pExNWWhVDM1TJhGSR46zOonsvBTD20PM+4UUaCTUKLGmaVrZKc3JnJLlO aCysr7p8xBNd+sOxSAcouMK8py5DUx0e0o4eiKnm5k/C14jUziRe1Fe9X Ni9uni4sDX1CIrThdNEJ8sJzsVqm52vVlRBrrRhRvibTelx010w3GSmac Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="452226747" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="452226747" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503413" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503413" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:22 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 04/23] x86/cpu: Detect TDX partial write machine check erratum Date: Tue, 17 Oct 2023 23:14:28 +1300 Message-ID: <3191588b67c04bdac682e12dab67499f7bde0a3c.1697532085.git.kai.huang@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:16:25 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997384020974212 X-GMAIL-MSGID: 1779997384020974212 TDX memory has integrity and confidentiality protections. Violations of this integrity protection are supposed to only affect TDX operations and are never supposed to affect the host kernel itself. In other words, the host kernel should never, itself, see machine checks induced by the TDX integrity hardware. Alas, the first few generations of TDX hardware have an erratum. A partial write to a TDX private memory cacheline will silently "poison" the line. Subsequent reads will consume the poison and generate a machine check. According to the TDX hardware spec, neither of these things should have happened. Virtually all kernel memory accesses operations happen in full cachelines. In practice, writing a "byte" of memory usually reads a 64 byte cacheline of memory, modifies it, then writes the whole line back. Those operations do not trigger this problem. This problem is triggered by "partial" writes where a write transaction of less than cacheline lands at the memory controller. The CPU does these via non-temporal write instructions (like MOVNTI), or through UC/WC memory mappings. The issue can also be triggered away from the CPU by devices doing partial writes via DMA. With this erratum, there are additional things need to be done. To prepare for those changes, add a CPU bug bit to indicate this erratum. Note this bug reflects the hardware thus it is detected regardless of whether the kernel is built with TDX support or not. Signed-off-by: Kai Huang Reviewed-by: Kirill A. Shutemov Reviewed-by: David Hildenbrand Reviewed-by: Dave Hansen --- v13 -> v14: - Use "To prepare for ___, add ___" in changelog (Dave) - Added Dave's tag. v12 -> v13: - Added David's tag. v11 -> v12: - Added Kirill's tag - Changed to detect the erratum in early_init_intel() (Kirill) v10 -> v11: - New patch --- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kernel/cpu/intel.c | 17 +++++++++++++++++ 2 files changed, 18 insertions(+) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index 58cb9495e40f..f11cfc3cdf81 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -494,6 +494,7 @@ #define X86_BUG_EIBRS_PBRSB X86_BUG(28) /* EIBRS is vulnerable to Post Barrier RSB Predictions */ #define X86_BUG_SMT_RSB X86_BUG(29) /* CPU is vulnerable to Cross-Thread Return Address Predictions */ #define X86_BUG_GDS X86_BUG(30) /* CPU is affected by Gather Data Sampling */ +#define X86_BUG_TDX_PW_MCE X86_BUG(31) /* CPU may incur #MC if non-TD software does partial write to TDX private memory */ /* BUG word 2 */ #define X86_BUG_SRSO X86_BUG(1*32 + 0) /* AMD SRSO bug */ diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index be4045628fd3..4e229265e596 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -184,6 +184,21 @@ static bool bad_spectre_microcode(struct cpuinfo_x86 *c) return false; } +static void check_tdx_erratum(struct cpuinfo_x86 *c) +{ + /* + * These CPUs have an erratum. A partial write from non-TD + * software (e.g. via MOVNTI variants or UC/WC mapping) to TDX + * private memory poisons that memory, and a subsequent read of + * that memory triggers #MC. + */ + switch (c->x86_model) { + case INTEL_FAM6_SAPPHIRERAPIDS_X: + case INTEL_FAM6_EMERALDRAPIDS_X: + setup_force_cpu_bug(X86_BUG_TDX_PW_MCE); + } +} + static void early_init_intel(struct cpuinfo_x86 *c) { u64 misc_enable; @@ -335,6 +350,8 @@ static void early_init_intel(struct cpuinfo_x86 *c) */ if (detect_extended_topology_early(c) < 0) detect_ht_early(c); + + check_tdx_erratum(c); } static void bsp_init_intel(struct cpuinfo_x86 *c) From patchwork Tue Oct 17 10:14:29 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154030 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4030247vqb; Tue, 17 Oct 2023 03:16:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH0fWQoP9i/od1FN2D+bZ4RT6fLuyRIrxANqZDcHO9Q+qxthGEmCKLohYg691dryVReKmY1 X-Received: by 2002:a17:902:dace:b0:1ca:8e79:53ae with SMTP id q14-20020a170902dace00b001ca8e7953aemr1860450plx.1.1697537784533; Tue, 17 Oct 2023 03:16:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537784; cv=none; d=google.com; s=arc-20160816; b=LS2J3CFeYN0CdbKf9/PeDpW/boE27r3ZB//H2Uiz39YxyGJL39Nw0HxGBaEZf+riZ0 4AJnqSS0LFkDMkmj9GXUvNsv5ZHNJ0kUKoKqPEhm/LUqcoPWZn3fCI00XQWH1I5/pszt Z+1ggU4vxJd0Wiq/h+agplGujR8XWXPJXr4hW8vvP4EE+ydZTVW4M7ox2XQ/2+f8J4PE WXj9BY6n6Qy2NtxxVBG7wgWdOO0zWK5E4lIKQDgfDWURSfD72NJuVmSt88vDAaTOZqeu kYp5JcidpzFOFObBzp6nviTayFrJabcA3tfY7dOnnOAWPrKcTkb/ClRPfiqVMwOS402Q +Meg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Mg7U7K8X9XBdP+aGX7Gv+7tI8gITS8aUlLvwKaLfJXw=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=KgT8KaWFXI3yapF8qPZ1V+agoZv7bBgUQUoAASapurUkokB5hHQ+Tdfxe5lqvhMq3Q Dx3mauhnuIVxJ1TA3aSM2kooD9NjGZ+fKaaH8zzOesa+VB8mmCTazaFm9gG3L4xQR0V5 rCZMJG6kcUBPy8ZtLbRYSiYfOVd8uHfHdFdrpfmbRYjVBwUS1Hm7tjFjCM2hQ+fMni7P zrUjv/HG23XKM1BdKBawDrmlCcAfK6ulrjVQ4j8tnrvz21AOWCwjrfQFg4LkpFR6BOpm UDFTbnhZgWeVOXzkLQbqT1vUz5pxGqm3UYstbNhl8vElDoZqyedVFb9uES3gfu/sbWh3 zsUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=eDHNKpCg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id m9-20020a170902768900b001c9ad2bc71esi1384230pll.251.2023.10.17.03.16.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:16:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=eDHNKpCg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 93BC480AB59B; Tue, 17 Oct 2023 03:16:20 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234989AbjJQKP6 (ORCPT + 19 others); Tue, 17 Oct 2023 06:15:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235026AbjJQKPj (ORCPT ); Tue, 17 Oct 2023 06:15:39 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD9ED198; Tue, 17 Oct 2023 03:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537734; x=1729073734; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=n4UtbhKr/IDc9atorHG1N+zyvfajcN/QgBgjNTS8SHA=; b=eDHNKpCgLCO9jbK2aGOzDH+KuTobHFVZZK8q/SxonrEFIOAD/Sogyx+w EPbioNcrDvuBqKZCxln2XU6qGXxjXY5fxbIxj0yRErKGeRlRe90dcQMkU 85fAUkEu9S/uvDeXQ5JECDjTjQDSzFgInmAHrcb5FL5gROfmy/ud4LrY9 jFbx6/7sAXNlkRRRt77BGjhxSfjACzo1zYFsnWWBRgMMoMM2WA0t3qCFr e3IrwIUXet2GHCyOcy5tH2N5vwc7bCniScvdLmHJlFM04ii7JSSmaSlW4 YIObDL9Ejns9JL/mtJbBQOQH63TQczC4KN04pHY4x58OCFrX/WvyrOdm8 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="452226764" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="452226764" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503462" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503462" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:28 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 05/23] x86/virt/tdx: Handle SEAMCALL no entropy error in common code Date: Tue, 17 Oct 2023 23:14:29 +1300 Message-ID: X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:16:20 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997380156089246 X-GMAIL-MSGID: 1779997380156089246 Some SEAMCALLs use the RDRAND hardware and can fail for the same reasons as RDRAND. Use the kernel RDRAND retry logic for them. There are three __seamcall*() variants. Do the SEAMCALL retry in common code and add a wrapper for each of them. Signed-off-by: Kai Huang Reviewed-by: Kirill A. Shutemov Reviewed-by: Kuppuswamy Sathyanarayanan v14: - Use real function sc_retry() instead of using macros. (Dave) - Added Kirill's tag. v12 -> v13: - New implementation due to TDCALL assembly series. --- arch/x86/include/asm/tdx.h | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h index a252328734c7..d624aa25aab0 100644 --- a/arch/x86/include/asm/tdx.h +++ b/arch/x86/include/asm/tdx.h @@ -24,6 +24,11 @@ #define TDX_SEAMCALL_GP (TDX_SW_ERROR | X86_TRAP_GP) #define TDX_SEAMCALL_UD (TDX_SW_ERROR | X86_TRAP_UD) +/* + * TDX module SEAMCALL leaf function error codes + */ +#define TDX_RND_NO_ENTROPY 0x8000020300000000ULL + #ifndef __ASSEMBLY__ /* @@ -82,6 +87,27 @@ u64 __seamcall(u64 fn, struct tdx_module_args *args); u64 __seamcall_ret(u64 fn, struct tdx_module_args *args); u64 __seamcall_saved_ret(u64 fn, struct tdx_module_args *args); +#include + +typedef u64 (*sc_func_t)(u64 fn, struct tdx_module_args *args); + +static inline u64 sc_retry(sc_func_t func, u64 fn, + struct tdx_module_args *args) +{ + int retry = RDRAND_RETRY_LOOPS; + u64 ret; + + do { + ret = func(fn, args); + } while (ret == TDX_RND_NO_ENTROPY && --retry); + + return ret; +} + +#define seamcall(_fn, _args) sc_retry(__seamcall, (_fn), (_args)) +#define seamcall_ret(_fn, _args) sc_retry(__seamcall_ret, (_fn), (_args)) +#define seamcall_saved_ret(_fn, _args) sc_retry(__seamcall_saved_ret, (_fn), (_args)) + bool platform_tdx_enabled(void); #else static inline bool platform_tdx_enabled(void) { return false; } From patchwork Tue Oct 17 10:14:30 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154033 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4030305vqb; Tue, 17 Oct 2023 03:16:30 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG8pUMjZxNAkUt2eAUZ1LY85GktuDJOHxo2Anq2ZiGkpwZZdN0DHlSqKY1HRvTVxPy6qPVt X-Received: by 2002:a17:90b:4c8b:b0:27d:2762:2728 with SMTP id my11-20020a17090b4c8b00b0027d27622728mr1871989pjb.0.1697537790312; Tue, 17 Oct 2023 03:16:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537790; cv=none; d=google.com; s=arc-20160816; b=eqzF6rfbMyHGsVYzPM0AZkh5ffDUUpUe9v6i6dCRvglaoA0jgaE2gbxpBgNDGXQt7F mXpXB/fCMcMu89IOnelnmSMGi+EqLIw+FRu5QCYRu51bNfSs99efFNCVnzN6rX98qRP0 NjK3veypgAma+iflRrrYB2w3cSsKSbE0lZw8r7cB0Jjs2TaH/E7C1JwVshzhe67R8U3F /I5atNUDrfWPTc42badvgmI/Otw9Rajl5Ra2CnfrVErmLVrhrw3wbjCrkLIsruWbvI/H lX614L2IrGXPGcrwhyIIryuO4n34FR8QO1Tgci2ECV0X5L6ag+83kMSfVIqCEU1Cd12e 75Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ir6IOg5nw9wdGHduYG+/953r6kv8Z1oHOC+sAAWQLFo=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=wVBmOjxsHrmhDKOk9rqgLZ9mkBukbJ1HESBjpYrlHskcVAaex6MYL273V7GYLikoa+ SrJp5D3b37LA5h2tADADi99krzDe6fbvGHus32BJPmrn9IJ/NIjZAacE9hgr1qaX8wLu vIbkRznOs06vjJ0SarSlfFStRRfJt+wrVKSP0+yFigQnGTkxj9Ol+gu/lPlZ56exH41A QWFBLyF4i+/ysEjS+gWGJyNpW0wPvq3gB6woHeMWsVFkecWs6FTMwCy6imoJYUHNGGrE hfNSsO+wUoLP2agc4oG4b/SMjoZ4oPuqy/BxF2nQXcMHpD8bRhAUpM86Yt4xfvxh+wSJ eurw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YsOfCb25; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id ie9-20020a17090b400900b0027491203b43si7824161pjb.189.2023.10.17.03.16.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:16:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YsOfCb25; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 04FA5808293F; Tue, 17 Oct 2023 03:16:28 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343699AbjJQKQQ (ORCPT + 19 others); Tue, 17 Oct 2023 06:16:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51688 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343706AbjJQKPv (ORCPT ); Tue, 17 Oct 2023 06:15:51 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF85E1BF; Tue, 17 Oct 2023 03:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537741; x=1729073741; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=F2UWS68G23VMzstdN8nuzh/U2U/GfdW4IZaM6wZeN9U=; b=YsOfCb25uOwxNWt9WhU8ql35GGuel57An9euttg2sehdTkaGZ4zNUDb4 A1JAHFUniUkQNnv7IgrMqOPG9T/TbbXCOD3/+ooT46VRL9NSbuY3MDEvg 68h0BYsqnQv5/8ycP+2WmbefP7YDi3EPkKshpeQMmxgLHHJJ67/xAgum3 OTMZanis3qjSLvH8kM1NDwVlzg0UWabMh3OnqezqZchpmWcjdwG3/jwXk C1h8C2cJXPb6f1WaZB98Xz/7KH+sdFGCEm7Odcmgd9E44rrsigSfwwk9o ioMHCwJ0rMveqqbdxB7zCaZiWH3EMUWmtDq/ZEFsz153Awm4bbFsvI/ZI g==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="452226797" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="452226797" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503506" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503506" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:34 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 06/23] x86/virt/tdx: Add SEAMCALL error printing for module initialization Date: Tue, 17 Oct 2023 23:14:30 +1300 Message-ID: <58c44258cb5b1009f0ddfe6b07ac986b9614b8b3.1697532085.git.kai.huang@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:16:28 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997385714599800 X-GMAIL-MSGID: 1779997385714599800 The SEAMCALLs involved during the TDX module initialization are not expected to fail. In fact, they are not expected to return any non-zero code (except the "running out of entropy error", which can be handled internally already). Add yet another set of SEAMCALL wrappers, which treats all non-zero return code as error, to support printing SEAMCALL error upon failure for module initialization. Note the TDX module initialization doesn't use the _saved_ret() variant thus no wrapper is added for it. SEAMCALL assembly can also return kernel-defined error codes for three special cases: 1) TDX isn't enabled by the BIOS; 2) TDX module isn't loaded; 3) CPU isn't in VMX operation. Whether they can legally happen depends on the caller, so leave to the caller to print error message when desired. Also convert the SEAMCALL error codes to the kernel error codes in the new wrappers so that each SEAMCALL caller doesn't have to repeat the conversion. Signed-off-by: Kai Huang Reviewed-by: Kirill A. Shutemov Reviewed-by: Kuppuswamy Sathyanarayanan --- v13 -> v14: - Use real functions to replace macros. (Dave) - Moved printing error message for special error code to the caller (internal) - Added Kirill's tag v12 -> v13: - New implementation due to TDCALL assembly series. --- arch/x86/include/asm/tdx.h | 1 + arch/x86/virt/vmx/tdx/tdx.c | 52 +++++++++++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+) diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h index d624aa25aab0..984efd3114ed 100644 --- a/arch/x86/include/asm/tdx.h +++ b/arch/x86/include/asm/tdx.h @@ -27,6 +27,7 @@ /* * TDX module SEAMCALL leaf function error codes */ +#define TDX_SUCCESS 0ULL #define TDX_RND_NO_ENTROPY 0x8000020300000000ULL #ifndef __ASSEMBLY__ diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 13d22ea2e2d9..52fb14e0195f 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -20,6 +20,58 @@ static u32 tdx_global_keyid __ro_after_init; static u32 tdx_guest_keyid_start __ro_after_init; static u32 tdx_nr_guest_keyids __ro_after_init; +typedef void (*sc_err_func_t)(u64 fn, u64 err, struct tdx_module_args *args); + +static inline void seamcall_err(u64 fn, u64 err, struct tdx_module_args *args) +{ + pr_err("SEAMCALL (0x%llx) failed: 0x%llx\n", fn, err); +} + +static inline void seamcall_err_ret(u64 fn, u64 err, + struct tdx_module_args *args) +{ + seamcall_err(fn, err, args); + pr_err("RCX 0x%llx RDX 0x%llx R8 0x%llx R9 0x%llx R10 0x%llx R11 0x%llx\n", + args->rcx, args->rdx, args->r8, args->r9, + args->r10, args->r11); +} + +static inline void seamcall_err_saved_ret(u64 fn, u64 err, + struct tdx_module_args *args) +{ + seamcall_err_ret(fn, err, args); + pr_err("RBX 0x%llx RDI 0x%llx RSI 0x%llx R12 0x%llx R13 0x%llx R14 0x%llx R15 0x%llx\n", + args->rbx, args->rdi, args->rsi, args->r12, + args->r13, args->r14, args->r15); +} + +static inline int sc_retry_prerr(sc_func_t func, sc_err_func_t err_func, + u64 fn, struct tdx_module_args *args) +{ + u64 sret = sc_retry(func, fn, args); + + if (sret == TDX_SUCCESS) + return 0; + + if (sret == TDX_SEAMCALL_VMFAILINVALID) + return -ENODEV; + + if (sret == TDX_SEAMCALL_GP) + return -EOPNOTSUPP; + + if (sret == TDX_SEAMCALL_UD) + return -EACCES; + + err_func(fn, sret, args); + return -EIO; +} + +#define seamcall_prerr(__fn, __args) \ + sc_retry_prerr(__seamcall, seamcall_err, (__fn), (__args)) + +#define seamcall_prerr_ret(__fn, __args) \ + sc_retry_prerr(__seamcall_ret, seamcall_err_ret, (__fn), (__args)) + static int __init record_keyid_partitioning(u32 *tdx_keyid_start, u32 *nr_tdx_keyids) { From patchwork Tue Oct 17 10:14:31 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154035 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4030451vqb; Tue, 17 Oct 2023 03:16:52 -0700 (PDT) X-Google-Smtp-Source: AGHT+IERaf9N7CzIxcS+I4rhQfOWVvs+G3EUjILmCft8gbkcypniN0LY0X2ze4koHFHxlsp6v2Mh X-Received: by 2002:a05:6a00:1d9b:b0:692:ad93:e852 with SMTP id z27-20020a056a001d9b00b00692ad93e852mr1787019pfw.2.1697537811935; Tue, 17 Oct 2023 03:16:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537811; cv=none; d=google.com; s=arc-20160816; b=Rx2qmcVJ9xFHp0er70SYrI3egCHEyMCa4cOELpBwKpL3/+zZtc06sklyTD7xDB7POJ 1t6OKK0443kcSsYw+ADapoB1ko4LyZ0NrrpgiKPteA/GfWOYxoJBo3BR1GhUIcz3GW30 FqLFdbX2T4W8NRv9RQOlSIt/6DFeRf7ySm4IU6vyXieFWLez9cz7Au2l4BN56wZ+yolx xe7oTF0bdz7n1fxo31i3SnFfWRjRHu9/TVi2hMLVD0Y50+6emFeFCXKXvp7oACdtef/7 S3t0TGaTLSDkG5+Sf4GkaZObAYda0YR0rGffO8Bmgg46rxCBhXReHmDf5oJk5J4r/Ru9 +CIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=6YvHjFCkiiEnvft+0h56ExSBNwOQD1SGVKD6H6SyPas=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=GmBVhjYKxMLzHPzaQ0Pk9QozCWE7itFG9nG4sgmAMKkyRLsFBw9REXkOE/PauoDnq5 toVGMchimy+QfEw5onXWI1gN7hdNW9TO5kTvO0guz3P8aobflTwwSm2RU4x+HiE7lFVH +ywDluXjqoZ6jLzmkj63S9pA2IRAVmT9bd9pokeOtIFrfvXiLmqQF7qma/5YCljf7yHs v5MFpD2hLQCQHnysC7l2D3wQDPuML/WWv2r3UazU5HJ1BsP6KpXnpHU3Bb/iAAhzN/9G QwIaLX4luUIKMNqpED3NK04o17oizwQhMUYh/pBVLr6LJ/Z7uFn9d5obLeGH3frA05bL waig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=E7LcrnjY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id x4-20020a63db44000000b00573f7b6999csi1368434pgi.440.2023.10.17.03.16.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:16:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=E7LcrnjY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 4D301807C648; Tue, 17 Oct 2023 03:16:48 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235035AbjJQKQg (ORCPT + 19 others); Tue, 17 Oct 2023 06:16:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343651AbjJQKQM (ORCPT ); Tue, 17 Oct 2023 06:16:12 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB1C1D7B; Tue, 17 Oct 2023 03:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537748; x=1729073748; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=khH+PTzzUhnQaCIW8iP29HhJPCv6yM/74X8f573Y+/w=; b=E7LcrnjYuWRBnnHQlI7g6NICAqMhRyJSdh8nqh94hMJQB6nyQWZPfRAu 4X6ZkLsZFZzozJlfY2JR1AwpIFwuvRQF5MIPXJJPTrZ8EL3pn5+98mxmh HRqAbHN6pWYRvE4wehiwE4tStQvrOnSFIW4uXGHxv0P8Ew2W9fjVXuJzB cmH7vKLeOTiaS27BTTjYGGOC2lMq4T4EloHK+RR9DTEnCrnuyf9STFABq 81LLKBKtJuace7QpJ3sIJ4BKdWjiXnRWMlLu+U/9zd3xquhH/cjUZFlpE aEMzL+W2c/IQNFiDbRX9P/0QAJws9IyvIPcgZVJ8cLiU2I/PCA1rbiKNE Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="452226819" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="452226819" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503551" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503551" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:40 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 07/23] x86/virt/tdx: Add skeleton to enable TDX on demand Date: Tue, 17 Oct 2023 23:14:31 +1300 Message-ID: <4fd10771907ae276548140cf7f8746e2eb38821c.1697532085.git.kai.huang@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:16:48 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997408366632609 X-GMAIL-MSGID: 1779997408366632609 To enable TDX the kernel needs to initialize TDX from two perspectives: 1) Do a set of SEAMCALLs to initialize the TDX module to make it ready to create and run TDX guests; 2) Do the per-cpu initialization SEAMCALL on one logical cpu before the kernel wants to make any other SEAMCALLs on that cpu (including those involved during module initialization and running TDX guests). The TDX module can be initialized only once in its lifetime. Instead of always initializing it at boot time, this implementation chooses an "on demand" approach to initialize TDX until there is a real need (e.g when requested by KVM). This approach has below pros: 1) It avoids consuming the memory that must be allocated by kernel and given to the TDX module as metadata (~1/256th of the TDX-usable memory), and also saves the CPU cycles of initializing the TDX module (and the metadata) when TDX is not used at all. 2) The TDX module design allows it to be updated while the system is running. The update procedure shares quite a few steps with this "on demand" initialization mechanism. The hope is that much of "on demand" mechanism can be shared with a future "update" mechanism. A boot-time TDX module implementation would not be able to share much code with the update mechanism. 3) Making SEAMCALL requires VMX to be enabled. Currently, only the KVM code mucks with VMX enabling. If the TDX module were to be initialized separately from KVM (like at boot), the boot code would need to be taught how to muck with VMX enabling and KVM would need to be taught how to cope with that. Making KVM itself responsible for TDX initialization lets the rest of the kernel stay blissfully unaware of VMX. Similar to module initialization, also make the per-cpu initialization "on demand" as it also depends on VMX being enabled. Add two functions, tdx_enable() and tdx_cpu_enable(), to enable the TDX module and enable TDX on local cpu respectively. For now tdx_enable() is a placeholder. The TODO list will be pared down as functionality is added. Export both tdx_cpu_enable() and tdx_enable() for KVM use. In tdx_enable() use a state machine protected by mutex to make sure the initialization will only be done once, as tdx_enable() can be called multiple times (i.e. KVM module can be reloaded) and may be called concurrently by other kernel components in the future. The per-cpu initialization on each cpu can only be done once during the module's life time. Use a per-cpu variable to track its status to make sure it is only done once in tdx_cpu_enable(). Also, a SEAMCALL to do TDX module global initialization must be done once on any logical cpu before any per-cpu initialization SEAMCALL. Do it inside tdx_cpu_enable() too (if hasn't been done). tdx_enable() can potentially invoke SEAMCALLs on any online cpus. The per-cpu initialization must be done before those SEAMCALLs are invoked on some cpu. To keep things simple, in tdx_cpu_enable(), always do the per-cpu initialization regardless of whether the TDX module has been initialized or not. And in tdx_enable(), don't call tdx_cpu_enable() but assume the caller has disabled CPU hotplug, done VMXON and tdx_cpu_enable() on all online cpus before calling tdx_enable(). Signed-off-by: Kai Huang Reviewed-by: Kirill A. Shutemov Reviewed-by: Nikolay Borisov --- v13 -> v14: - Use lockdep_assert_irqs_off() in try_init_model_global() (Nikolay), but still keep the comment (Kirill). - Add code to print "module not loaded" in the first SEAMCALL. - If SYS.INIT fails, stop calling LP.INIT in other tdx_cpu_enable()s. - Added Kirill's tag v12 -> v13: - Made tdx_cpu_enable() always be called with IRQ disabled via IPI funciton call (Peter, Kirill). v11 -> v12: - Simplified TDX module global init and lp init status tracking (David). - Added comment around try_init_module_global() for using raw_spin_lock() (Dave). - Added one sentence to changelog to explain why to expose tdx_enable() and tdx_cpu_enable() (Dave). - Simplifed comments around tdx_enable() and tdx_cpu_enable() to use lockdep_assert_*() instead. (Dave) - Removed redundent "TDX" in error message (Dave). v10 -> v11: - Return -NODEV instead of -EINVAL when CONFIG_INTEL_TDX_HOST is off. - Return the actual error code for tdx_enable() instead of -EINVAL. - Added Isaku's Reviewed-by. v9 -> v10: - Merged the patch to handle per-cpu initialization to this patch to tell the story better. - Changed how to handle the per-cpu initialization to only provide a tdx_cpu_enable() function to let the user of TDX to do it when the user wants to run TDX code on a certain cpu. - Changed tdx_enable() to not call cpus_read_lock() explicitly, but call lockdep_assert_cpus_held() to assume the caller has done that. - Improved comments around tdx_enable() and tdx_cpu_enable(). - Improved changelog to tell the story better accordingly. v8 -> v9: - Removed detailed TODO list in the changelog (Dave). - Added back steps to do module global initialization and per-cpu initialization in the TODO list comment. - Moved the 'enum tdx_module_status_t' from tdx.c to local tdx.h v7 -> v8: - Refined changelog (Dave). - Removed "all BIOS-enabled cpus" related code (Peter/Thomas/Dave). - Add a "TODO list" comment in init_tdx_module() to list all steps of initializing the TDX Module to tell the story (Dave). - Made tdx_enable() unverisally return -EINVAL, and removed nonsense comments (Dave). - Simplified __tdx_enable() to only handle success or failure. - TDX_MODULE_SHUTDOWN -> TDX_MODULE_ERROR - Removed TDX_MODULE_NONE (not loaded) as it is not necessary. - Improved comments (Dave). - Pointed out 'tdx_module_status' is software thing (Dave). ... --- arch/x86/include/asm/tdx.h | 4 + arch/x86/virt/vmx/tdx/tdx.c | 167 ++++++++++++++++++++++++++++++++++++ arch/x86/virt/vmx/tdx/tdx.h | 30 +++++++ 3 files changed, 201 insertions(+) create mode 100644 arch/x86/virt/vmx/tdx/tdx.h diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h index 984efd3114ed..3cfd64f8a2b5 100644 --- a/arch/x86/include/asm/tdx.h +++ b/arch/x86/include/asm/tdx.h @@ -110,8 +110,12 @@ static inline u64 sc_retry(sc_func_t func, u64 fn, #define seamcall_saved_ret(_fn, _args) sc_retry(__seamcall_saved_ret, (_fn), (_args)) bool platform_tdx_enabled(void); +int tdx_cpu_enable(void); +int tdx_enable(void); #else static inline bool platform_tdx_enabled(void) { return false; } +static inline int tdx_cpu_enable(void) { return -ENODEV; } +static inline int tdx_enable(void) { return -ENODEV; } #endif /* CONFIG_INTEL_TDX_HOST */ #endif /* !__ASSEMBLY__ */ diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 52fb14e0195f..36db33133cd5 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -12,14 +12,24 @@ #include #include #include +#include +#include +#include +#include #include #include #include +#include "tdx.h" static u32 tdx_global_keyid __ro_after_init; static u32 tdx_guest_keyid_start __ro_after_init; static u32 tdx_nr_guest_keyids __ro_after_init; +static DEFINE_PER_CPU(bool, tdx_lp_initialized); + +static enum tdx_module_status_t tdx_module_status; +static DEFINE_MUTEX(tdx_module_lock); + typedef void (*sc_err_func_t)(u64 fn, u64 err, struct tdx_module_args *args); static inline void seamcall_err(u64 fn, u64 err, struct tdx_module_args *args) @@ -72,6 +82,163 @@ static inline int sc_retry_prerr(sc_func_t func, sc_err_func_t err_func, #define seamcall_prerr_ret(__fn, __args) \ sc_retry_prerr(__seamcall_ret, seamcall_err_ret, (__fn), (__args)) +/* + * Do the module global initialization once and return its result. + * It can be done on any cpu. It's always called with interrupts + * disabled. + */ +static int try_init_module_global(void) +{ + struct tdx_module_args args = {}; + static DEFINE_RAW_SPINLOCK(sysinit_lock); + static bool sysinit_done; + static int sysinit_ret; + + lockdep_assert_irqs_disabled(); + + raw_spin_lock(&sysinit_lock); + + if (sysinit_done) + goto out; + + /* RCX is module attributes and all bits are reserved */ + args.rcx = 0; + sysinit_ret = seamcall_prerr(TDH_SYS_INIT, &args); + + /* + * The first SEAMCALL also detects the TDX module, thus + * it can fail due to the TDX module is not loaded. + * Dump message to let the user know. + */ + if (sysinit_ret == -ENODEV) + pr_err("module not loaded\n"); + + sysinit_done = true; +out: + raw_spin_unlock(&sysinit_lock); + return sysinit_ret; +} + +/** + * tdx_cpu_enable - Enable TDX on local cpu + * + * Do one-time TDX module per-cpu initialization SEAMCALL (and TDX module + * global initialization SEAMCALL if not done) on local cpu to make this + * cpu be ready to run any other SEAMCALLs. + * + * Always call this function via IPI function calls. + * + * Return 0 on success, otherwise errors. + */ +int tdx_cpu_enable(void) +{ + struct tdx_module_args args = {}; + int ret; + + if (!platform_tdx_enabled()) + return -ENODEV; + + lockdep_assert_irqs_disabled(); + + if (__this_cpu_read(tdx_lp_initialized)) + return 0; + + /* + * The TDX module global initialization is the very first step + * to enable TDX. Need to do it first (if hasn't been done) + * before the per-cpu initialization. + */ + ret = try_init_module_global(); + if (ret) + return ret; + + ret = seamcall_prerr(TDH_SYS_LP_INIT, &args); + if (ret) + return ret; + + __this_cpu_write(tdx_lp_initialized, true); + + return 0; +} +EXPORT_SYMBOL_GPL(tdx_cpu_enable); + +static int init_tdx_module(void) +{ + /* + * TODO: + * + * - Get TDX module information and TDX-capable memory regions. + * - Build the list of TDX-usable memory regions. + * - Construct a list of "TD Memory Regions" (TDMRs) to cover + * all TDX-usable memory regions. + * - Configure the TDMRs and the global KeyID to the TDX module. + * - Configure the global KeyID on all packages. + * - Initialize all TDMRs. + * + * Return error before all steps are done. + */ + return -EINVAL; +} + +static int __tdx_enable(void) +{ + int ret; + + ret = init_tdx_module(); + if (ret) { + pr_err("module initialization failed (%d)\n", ret); + tdx_module_status = TDX_MODULE_ERROR; + return ret; + } + + pr_info("module initialized\n"); + tdx_module_status = TDX_MODULE_INITIALIZED; + + return 0; +} + +/** + * tdx_enable - Enable TDX module to make it ready to run TDX guests + * + * This function assumes the caller has: 1) held read lock of CPU hotplug + * lock to prevent any new cpu from becoming online; 2) done both VMXON + * and tdx_cpu_enable() on all online cpus. + * + * This function can be called in parallel by multiple callers. + * + * Return 0 if TDX is enabled successfully, otherwise error. + */ +int tdx_enable(void) +{ + int ret; + + if (!platform_tdx_enabled()) + return -ENODEV; + + lockdep_assert_cpus_held(); + + mutex_lock(&tdx_module_lock); + + switch (tdx_module_status) { + case TDX_MODULE_UNINITIALIZED: + ret = __tdx_enable(); + break; + case TDX_MODULE_INITIALIZED: + /* Already initialized, great, tell the caller. */ + ret = 0; + break; + default: + /* Failed to initialize in the previous attempts */ + ret = -EINVAL; + break; + } + + mutex_unlock(&tdx_module_lock); + + return ret; +} +EXPORT_SYMBOL_GPL(tdx_enable); + static int __init record_keyid_partitioning(u32 *tdx_keyid_start, u32 *nr_tdx_keyids) { diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h new file mode 100644 index 000000000000..a3c52270df5b --- /dev/null +++ b/arch/x86/virt/vmx/tdx/tdx.h @@ -0,0 +1,30 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _X86_VIRT_TDX_H +#define _X86_VIRT_TDX_H + +/* + * This file contains both macros and data structures defined by the TDX + * architecture and Linux defined software data structures and functions. + * The two should not be mixed together for better readability. The + * architectural definitions come first. + */ + +/* + * TDX module SEAMCALL leaf functions + */ +#define TDH_SYS_INIT 33 +#define TDH_SYS_LP_INIT 35 + +/* + * Do not put any hardware-defined TDX structure representations below + * this comment! + */ + +/* Kernel defined TDX module status during module initialization. */ +enum tdx_module_status_t { + TDX_MODULE_UNINITIALIZED, + TDX_MODULE_INITIALIZED, + TDX_MODULE_ERROR +}; + +#endif From patchwork Tue Oct 17 10:14:32 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154036 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4030751vqb; Tue, 17 Oct 2023 03:17:28 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFz+0ZGShhUjKvpvf5CCzTrdWx6c5mxJRUyWWZSLfOd71sR1IwXlOkjTGBMdwq9kBtyBHQw X-Received: by 2002:a05:6808:17a0:b0:3ae:108d:acee with SMTP id bg32-20020a05680817a000b003ae108daceemr2584244oib.1.1697537848576; Tue, 17 Oct 2023 03:17:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537848; cv=none; d=google.com; s=arc-20160816; b=uEq5axIVOFLDo/OF2CwMUkz+0OPgYPRd0pPbbRgCejcBMRpGbqYAEy9LDsAx/VqZJV zs8M4WyoR5+oKe5wWQE4A4/bhHLbXsuQbdCrsnmwf2AzfpFibRegGW5kZkrktnhpATzK i8ruBS7q1QA056/4J9nf5yOCFbBpu/RFYjKrV56pkwOD+454vzyk+zd1GlYR+kvQlI2H MhevJIbdiNcs60BwmfdibD5209bNlCJCkAmnsru7W8vtHln6N3HcKU/nKXq1YTAMTVM4 QGQNqaEh993iUQbkk/t+2Yf95aHm/fvPVnuYOawG1N3IB0JkHJYEFsX3d3/YzQzAxKrN p6jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=/ofV1RLcoE7l3gfyRa1cMb4hI+X0W+wiLlekmLI2srk=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=mZ1SBhAVj6fv1jWBZwCak+QL1jd6YIkPOick56OTeiOBloap7f0YaHCStJhzh43lyv kp7Y37v0bWmgsFfh+etC3E+Dx9nQNpLMh+qAi2xRQ5TwKr9vOcJlEX3dQ2N53X0ejLQ0 HXw0ZOqyfbFKEkp5S3bGmSwaeOhPoN5SKpfzHsLveV692TN6+C5mPMQ5fy/ZFYVtrHWR r2ljYpv9YbpSsGJuFeEnMIoTx7JaFWpdcpRef6PxwsB3xHFAL5o4B+dJRFM2mblHQD3D CThZdXqHyP0PZQTmZHZGaHzNhTYo5jmPUAtrBDw3vmSD6vxswJJ4+J8l/ad0ohnk9jve m8+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=d3J4BfEB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id u191-20020a6385c8000000b005b2d044af30si1389457pgd.480.2023.10.17.03.17.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:17:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=d3J4BfEB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 99E4880A1654; Tue, 17 Oct 2023 03:17:16 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343685AbjJQKQn (ORCPT + 19 others); Tue, 17 Oct 2023 06:16:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39906 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343702AbjJQKQQ (ORCPT ); Tue, 17 Oct 2023 06:16:16 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E38E129; Tue, 17 Oct 2023 03:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537754; x=1729073754; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=e1uTa2H5Z7R0c9eEVYABnYt1akVnOfTLvml2iXOGIs0=; b=d3J4BfEBJ2rKottUtWX5Wknnf47ouxu+11r3bxSLJCPwMrlq5skedZvc q6mWsT+usBWKRTfHABlkprDP2qxGTb/f+spH+Gdi5bEAEEUsWdd9FniL/ jVWb++TKiXh1L+dYWJfsrS/babJaO2s+RlVAMoO8CilApfrAy3WvfhdfE 3XtCsP4SvTVVzs8uOUrCfuTEzxnWXqoOk94FNU6aM0ZGAns07TsZEwuwv pHIwR5FfhWPR4i8joyEWeTsd9ItwlyBvEADvTyxOY4L/d2JBOTsCDUjVR 0bOxtWt4Z0j7xmyyR5ujRrwYbTgRTVEERpmJ3tNLlGzpZZIVGRLyHIyE2 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="452226840" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="452226840" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503578" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503578" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:47 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 08/23] x86/virt/tdx: Get information about TDX module and TDX-capable memory Date: Tue, 17 Oct 2023 23:14:32 +1300 Message-ID: <8c4f4f25ab24aa7267e3274b756a3cbc082f49d0.1697532085.git.kai.huang@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:17:16 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997447000768248 X-GMAIL-MSGID: 1779997447000768248 Start to transit out the "multi-steps" to initialize the TDX module. TDX provides increased levels of memory confidentiality and integrity. This requires special hardware support for features like memory encryption and storage of memory integrity checksums. Not all memory satisfies these requirements. As a result, TDX introduced the concept of a "Convertible Memory Region" (CMR). During boot, the firmware builds a list of all of the memory ranges which can provide the TDX security guarantees. CMRs tell the kernel which memory is TDX compatible. The kernel takes CMRs (plus a little more metadata) and constructs "TD Memory Regions" (TDMRs). TDMRs let the kernel grant TDX protections to some or all of the CMR areas. The TDX module also reports necessary information to let the kernel build TDMRs and run TDX guests in structure 'tdsysinfo_struct'. The list of CMRs, along with the TDX module information, is available to the kernel by querying the TDX module. As a preparation to construct TDMRs, get the TDX module information and the list of CMRs. Print out CMRs to help user to decode which memory regions are TDX convertible. The 'tdsysinfo_struct' is fairly large (1024 bytes) and contains a lot of info about the TDX module. Fully define the entire structure, but only use the fields necessary to build the TDMRs and pr_info() some basics about the module. The rest of the fields will get used by KVM. Signed-off-by: Kai Huang Reviewed-by: Isaku Yamahata Reviewed-by: Kirill A. Shutemov --- v13 -> v14: - Added Kirill's tag. v12 -> v13: - Allocate TDSYSINFO and CMR array separately. (Kirill) - Added comment around TDH.SYS.INFO. (Peter) v11 -> v12: - Changed to use dynamic allocation for TDSYSINFO_STRUCT and CMR array (Kirill). - Keep SEAMCALL leaf macro definitions in order (Kirill) - Removed is_cmr_empty() but open code directly (David) - 'atribute' -> 'attribute' (David) v10 -> v11: - No change. v9 -> v10: - Added back "start to transit out..." as now per-cpu init has been moved out from tdx_enable(). v8 -> v9: - Removed "start to trransit out ..." part in changelog since this patch is no longer the first step anymore. - Changed to declare 'tdsysinfo' and 'cmr_array' as local static, and changed changelog accordingly (Dave). - Improved changelog to explain why to declare 'tdsysinfo_struct' in full but only use a few members of them (Dave). v7 -> v8: (Dave) - Improved changelog to tell this is the first patch to transit out the "multi-steps" init_tdx_module(). - Removed all CMR check/trim code but to depend on later SEAMCALL. - Variable 'vertical alignment' in print TDX module information. - Added DECLARE_PADDED_STRUCT() for padded structure. - Made tdx_sysinfo and tdx_cmr_array[] to be function local variable (and rename them accordingly), and added -Wframe-larger-than=4096 flag to silence the build warning. ... --- arch/x86/virt/vmx/tdx/tdx.c | 94 ++++++++++++++++++++++++++++++++++++- arch/x86/virt/vmx/tdx/tdx.h | 64 +++++++++++++++++++++++++ 2 files changed, 156 insertions(+), 2 deletions(-) diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 36db33133cd5..b18f1e9c92dc 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -16,8 +16,11 @@ #include #include #include +#include +#include #include #include +#include #include #include "tdx.h" @@ -162,12 +165,91 @@ int tdx_cpu_enable(void) } EXPORT_SYMBOL_GPL(tdx_cpu_enable); +static void print_cmrs(struct cmr_info *cmr_array, int nr_cmrs) +{ + int i; + + for (i = 0; i < nr_cmrs; i++) { + struct cmr_info *cmr = &cmr_array[i]; + + /* + * The array of CMRs reported via TDH.SYS.INFO can + * contain tail empty CMRs. Don't print them. + */ + if (!cmr->size) + break; + + pr_info("CMR: [0x%llx, 0x%llx)\n", cmr->base, + cmr->base + cmr->size); + } +} + +static int get_tdx_sysinfo(struct tdsysinfo_struct *tdsysinfo, + struct cmr_info *cmr_array) +{ + struct tdx_module_args args = {}; + int ret; + + /* + * TDH.SYS.INFO writes the TDSYSINFO_STRUCT and the CMR array + * to the buffers provided by the kernel (via RCX and R8 + * respectively). The buffer size of the TDSYSINFO_STRUCT + * (via RDX) and the maximum entries of the CMR array (via R9) + * passed to this SEAMCALL must be at least the size of + * TDSYSINFO_STRUCT and MAX_CMRS respectively. + * + * Upon a successful return, R9 contains the actual entries + * written to the CMR array. + */ + args.rcx = __pa(tdsysinfo); + args.rdx = TDSYSINFO_STRUCT_SIZE; + args.r8 = __pa(cmr_array); + args.r9 = MAX_CMRS; + ret = seamcall_prerr_ret(TDH_SYS_INFO, &args); + if (ret) + return ret; + + pr_info("TDX module: attributes 0x%x, vendor_id 0x%x, major_version %u, minor_version %u, build_date %u, build_num %u", + tdsysinfo->attributes, tdsysinfo->vendor_id, + tdsysinfo->major_version, tdsysinfo->minor_version, + tdsysinfo->build_date, tdsysinfo->build_num); + + print_cmrs(cmr_array, args.r9); + + return 0; +} + static int init_tdx_module(void) { + struct tdsysinfo_struct *tdsysinfo; + struct cmr_info *cmr_array; + int tdsysinfo_size; + int cmr_array_size; + int ret; + + tdsysinfo_size = round_up(TDSYSINFO_STRUCT_SIZE, + TDSYSINFO_STRUCT_ALIGNMENT); + tdsysinfo = kzalloc(tdsysinfo_size, GFP_KERNEL); + if (!tdsysinfo) + return -ENOMEM; + + cmr_array_size = sizeof(struct cmr_info) * MAX_CMRS; + cmr_array_size = round_up(cmr_array_size, CMR_INFO_ARRAY_ALIGNMENT); + cmr_array = kzalloc(cmr_array_size, GFP_KERNEL); + if (!cmr_array) { + kfree(tdsysinfo); + return -ENOMEM; + } + + + /* Get the TDSYSINFO_STRUCT and CMRs from the TDX module. */ + ret = get_tdx_sysinfo(tdsysinfo, cmr_array); + if (ret) + goto out; + /* * TODO: * - * - Get TDX module information and TDX-capable memory regions. * - Build the list of TDX-usable memory regions. * - Construct a list of "TD Memory Regions" (TDMRs) to cover * all TDX-usable memory regions. @@ -177,7 +259,15 @@ static int init_tdx_module(void) * * Return error before all steps are done. */ - return -EINVAL; + ret = -EINVAL; +out: + /* + * For now both @sysinfo and @cmr_array are only used during + * module initialization, so always free them. + */ + kfree(tdsysinfo); + kfree(cmr_array); + return ret; } static int __tdx_enable(void) diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h index a3c52270df5b..fff36af71448 100644 --- a/arch/x86/virt/vmx/tdx/tdx.h +++ b/arch/x86/virt/vmx/tdx/tdx.h @@ -2,6 +2,10 @@ #ifndef _X86_VIRT_TDX_H #define _X86_VIRT_TDX_H +#include +#include +#include + /* * This file contains both macros and data structures defined by the TDX * architecture and Linux defined software data structures and functions. @@ -12,9 +16,69 @@ /* * TDX module SEAMCALL leaf functions */ +#define TDH_SYS_INFO 32 #define TDH_SYS_INIT 33 #define TDH_SYS_LP_INIT 35 +struct cmr_info { + u64 base; + u64 size; +} __packed; + +#define MAX_CMRS 32 +#define CMR_INFO_ARRAY_ALIGNMENT 512 + +struct cpuid_config { + u32 leaf; + u32 sub_leaf; + u32 eax; + u32 ebx; + u32 ecx; + u32 edx; +} __packed; + +#define TDSYSINFO_STRUCT_SIZE 1024 +#define TDSYSINFO_STRUCT_ALIGNMENT 1024 + +/* + * The size of this structure itself is flexible. The actual structure + * passed to TDH.SYS.INFO must be padded to TDSYSINFO_STRUCT_SIZE bytes + * and TDSYSINFO_STRUCT_ALIGNMENT bytes aligned. + */ +struct tdsysinfo_struct { + /* TDX-SEAM Module Info */ + u32 attributes; + u32 vendor_id; + u32 build_date; + u16 build_num; + u16 minor_version; + u16 major_version; + u8 reserved0[14]; + /* Memory Info */ + u16 max_tdmrs; + u16 max_reserved_per_tdmr; + u16 pamt_entry_size; + u8 reserved1[10]; + /* Control Struct Info */ + u16 tdcs_base_size; + u8 reserved2[2]; + u16 tdvps_base_size; + u8 tdvps_xfam_dependent_size; + u8 reserved3[9]; + /* TD Capabilities */ + u64 attributes_fixed0; + u64 attributes_fixed1; + u64 xfam_fixed0; + u64 xfam_fixed1; + u8 reserved4[32]; + u32 num_cpuid_config; + /* + * The actual number of CPUID_CONFIG depends on above + * 'num_cpuid_config'. + */ + DECLARE_FLEX_ARRAY(struct cpuid_config, cpuid_configs); +} __packed; + /* * Do not put any hardware-defined TDX structure representations below * this comment! From patchwork Tue Oct 17 10:14:33 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154037 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4030855vqb; Tue, 17 Oct 2023 03:17:46 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFXKqdSfdGkObAHStUKvUOLZGi6vW1h8wxKc6TJNT5oj0rZ4k6a66+QVgP9cIPtRrcYNZvd X-Received: by 2002:a05:6a21:3987:b0:133:6e3d:68cd with SMTP id ad7-20020a056a21398700b001336e3d68cdmr1680439pzc.3.1697537866022; Tue, 17 Oct 2023 03:17:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537866; cv=none; d=google.com; s=arc-20160816; b=DMsovYT6/txw472rpb5s3nrywY+l+ruaDjTPLeh7fLv/ozbufyXYu3ao2UuHnVwkzm SpXf3u/ai7X1kdnF6CCX+nh52VG3wOpqsRCIThTEa8gDZeHlFD/3S2b1gQ0X1HK6BVqZ rc/Az/GUgelYf0H2wbdpiVxJKRTPfu9ODfjHKM9lQ34tVG8LVMddRRKYi4d3rdC8GnGD XMcVcOq9lcQ546gP9jr/hddIAAypjO4QVn8CvNKXLXD2/yN5wWXk/GExTsyC4j0pz6nQ TC1KHgOyqcD3cKy7NanHT+cKYqw9/zrCASqHpWQOH/0km50UboCrerHHWHGAKpE4LzJ7 63HA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ym7un1jfAD7zAP1UqLuMpAwGyVr1SDt4mW0yNAXLrdU=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=RxZq2VVn5wMVcUvgzO643v2JDWd8dRb5cQuOTRp8iSyYCHGZysodLpjX2ZmSghZL26 9Eq5nlOWei/evdJtxoJZcGmUwa6OQUlv+QmAkb7sXO/Y1HEzv9nw4/ULXXWQZvCAgjE2 yu/TtWXoNwJcK0N+bGMagGLBIVy3wZ0HgI7xEZ7IiR12qOJ70Kk/ng+GyiQZjcbAGxln 7Ri+oJowLI+5mw/M90kemwKW8yVezvaoZdD0uk1bX6p3g2PBrP9lsIDiY37k0cLh0wIn yfGWR1Z6GLTcC15040gFvDt2P7SK5qcJ0BUW6xff1C0xiyrmrc7COvBI/IEilnUVPaGi sGxQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="M/ea0CFs"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from morse.vger.email (morse.vger.email. [23.128.96.31]) by mx.google.com with ESMTPS id p2-20020a170902eac200b001c9bdaa81e3si1354798pld.633.2023.10.17.03.17.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:17:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) client-ip=23.128.96.31; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="M/ea0CFs"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.31 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 37C6D801F3F6; Tue, 17 Oct 2023 03:17:43 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234961AbjJQKRA (ORCPT + 19 others); Tue, 17 Oct 2023 06:17:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234925AbjJQKQb (ORCPT ); Tue, 17 Oct 2023 06:16:31 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A8A4122; Tue, 17 Oct 2023 03:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537759; x=1729073759; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=HGoGtdA2yqqXIPVmC9BxO7besWuZxJn+JAFa5ialh18=; b=M/ea0CFsN7SvPu6fsjuU8fNceG+5hHHasV74NWZfr+AsBZhLBtqlAl82 FyDexgEKBbsljPxE4jc6pj3qqoEPftjpcrJCBC9y5Df6yqQWq6gu2iHAA qtBEkuLowkLG1rKS2kE65dTHw+VBO4212jXzocp207mNrTHDJRHXrnvtj fcmargwUgQCILU+uilyQWQNSvs+gBqDT/9lB7BLvoT+bFrkDliDDypVPh OGAZSLNIaxi+rv2WyuMIu7VnlF4YzJn8qeFrp6v1D4CiYfuPzC+AYOYKp E91LFordnsqFqzmV7owZhv1q0yqFpKrerJtiLC+JrYA88e1kUyk2fukow A==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="452226856" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="452226856" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503601" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503601" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:53 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 09/23] x86/virt/tdx: Use all system memory when initializing TDX module as TDX memory Date: Tue, 17 Oct 2023 23:14:33 +1300 Message-ID: X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:17:43 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997465325604722 X-GMAIL-MSGID: 1779997465325604722 As a step of initializing the TDX module, the kernel needs to tell the TDX module which memory regions can be used by the TDX module as TDX guest memory. TDX reports a list of "Convertible Memory Region" (CMR) to tell the kernel which memory is TDX compatible. The kernel needs to build a list of memory regions (out of CMRs) as "TDX-usable" memory and pass them to the TDX module. Once this is done, those "TDX-usable" memory regions are fixed during module's lifetime. To keep things simple, assume that all TDX-protected memory will come from the page allocator. Make sure all pages in the page allocator *are* TDX-usable memory. As TDX-usable memory is a fixed configuration, take a snapshot of the memory configuration from memblocks at the time of module initialization (memblocks are modified on memory hotplug). This snapshot is used to enable TDX support for *this* memory configuration only. Use a memory hotplug notifier to ensure that no other RAM can be added outside of this configuration. This approach requires all memblock memory regions at the time of module initialization to be TDX convertible memory to work, otherwise module initialization will fail in a later SEAMCALL when passing those regions to the module. This approach works when all boot-time "system RAM" is TDX convertible memory, and no non-TDX-convertible memory is hot-added to the core-mm before module initialization. For instance, on the first generation of TDX machines, both CXL memory and NVDIMM are not TDX convertible memory. Using kmem driver to hot-add any CXL memory or NVDIMM to the core-mm before module initialization will result in failure to initialize the module. The SEAMCALL error code will be available in the dmesg to help user to understand the failure. Signed-off-by: Kai Huang Reviewed-by: "Huang, Ying" Reviewed-by: Isaku Yamahata Reviewed-by: Dave Hansen Reviewed-by: Kirill A. Shutemov --- v13 -> v14: - No change v12 -> v13: - Avoided using " ? : " in tdx_memory_notifier(). (Peter) v11 -> v12: - Added tags from Dave/Kirill. v10 -> v11: - Added Isaku's Reviewed-by. v9 -> v10: - Moved empty @tdx_memlist check out of is_tdx_memory() to make the logic better. - Added Ying's Reviewed-by. v8 -> v9: - Replace "The initial support ..." with timeless sentence in both changelog and comments(Dave). - Fix run-on sentence in changelog, and senstence to explain why to stash off memblock (Dave). - Tried to improve why to choose this approach and how it work in changelog based on Dave's suggestion. - Many other comments enhancement (Dave). v7 -> v8: - Trimed down changelog (Dave). - Changed to use PHYS_PFN() and PFN_PHYS() throughout this series (Ying). - Moved memory hotplug handling from add_arch_memory() to memory_notifier (Dan/David). - Removed 'nid' from 'struct tdx_memblock' to later patch (Dave). - {build|free}_tdx_memory() -> {build|}free_tdx_memlist() (Dave). - Removed pfn_covered_by_cmr() check as no code to trim CMRs now. - Improve the comment around first 1MB (Dave). - Added a comment around reserve_real_mode() to point out TDX code relies on first 1MB being reserved (Ying). - Added comment to explain why the new online memory range cannot cross multiple TDX memory blocks (Dave). - Improved other comments (Dave). --- arch/x86/Kconfig | 1 + arch/x86/kernel/setup.c | 2 + arch/x86/virt/vmx/tdx/tdx.c | 162 +++++++++++++++++++++++++++++++++++- arch/x86/virt/vmx/tdx/tdx.h | 6 ++ 4 files changed, 170 insertions(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index a70f3f205969..864e43b008b1 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1945,6 +1945,7 @@ config INTEL_TDX_HOST depends on X86_64 depends on KVM_INTEL depends on X86_X2APIC + select ARCH_KEEP_MEMBLOCK help Intel Trust Domain Extensions (TDX) protects guest VMs from malicious host and certain physical attacks. This option enables necessary TDX diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index b9145a63da77..9027e758173d 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1162,6 +1162,8 @@ void __init setup_arch(char **cmdline_p) * * Moreover, on machines with SandyBridge graphics or in setups that use * crashkernel the entire 1M is reserved anyway. + * + * Note the host kernel TDX also requires the first 1MB being reserved. */ x86_platform.realmode_reserve(); diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index b18f1e9c92dc..24fa8020cc7a 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -18,6 +18,12 @@ #include #include #include +#include +#include +#include +#include +#include +#include #include #include #include @@ -33,6 +39,9 @@ static DEFINE_PER_CPU(bool, tdx_lp_initialized); static enum tdx_module_status_t tdx_module_status; static DEFINE_MUTEX(tdx_module_lock); +/* All TDX-usable memory regions. Protected by mem_hotplug_lock. */ +static LIST_HEAD(tdx_memlist); + typedef void (*sc_err_func_t)(u64 fn, u64 err, struct tdx_module_args *args); static inline void seamcall_err(u64 fn, u64 err, struct tdx_module_args *args) @@ -219,6 +228,79 @@ static int get_tdx_sysinfo(struct tdsysinfo_struct *tdsysinfo, return 0; } +/* + * Add a memory region as a TDX memory block. The caller must make sure + * all memory regions are added in address ascending order and don't + * overlap. + */ +static int add_tdx_memblock(struct list_head *tmb_list, unsigned long start_pfn, + unsigned long end_pfn) +{ + struct tdx_memblock *tmb; + + tmb = kmalloc(sizeof(*tmb), GFP_KERNEL); + if (!tmb) + return -ENOMEM; + + INIT_LIST_HEAD(&tmb->list); + tmb->start_pfn = start_pfn; + tmb->end_pfn = end_pfn; + + /* @tmb_list is protected by mem_hotplug_lock */ + list_add_tail(&tmb->list, tmb_list); + return 0; +} + +static void free_tdx_memlist(struct list_head *tmb_list) +{ + /* @tmb_list is protected by mem_hotplug_lock */ + while (!list_empty(tmb_list)) { + struct tdx_memblock *tmb = list_first_entry(tmb_list, + struct tdx_memblock, list); + + list_del(&tmb->list); + kfree(tmb); + } +} + +/* + * Ensure that all memblock memory regions are convertible to TDX + * memory. Once this has been established, stash the memblock + * ranges off in a secondary structure because memblock is modified + * in memory hotplug while TDX memory regions are fixed. + */ +static int build_tdx_memlist(struct list_head *tmb_list) +{ + unsigned long start_pfn, end_pfn; + int i, ret; + + for_each_mem_pfn_range(i, MAX_NUMNODES, &start_pfn, &end_pfn, NULL) { + /* + * The first 1MB is not reported as TDX convertible memory. + * Although the first 1MB is always reserved and won't end up + * to the page allocator, it is still in memblock's memory + * regions. Skip them manually to exclude them as TDX memory. + */ + start_pfn = max(start_pfn, PHYS_PFN(SZ_1M)); + if (start_pfn >= end_pfn) + continue; + + /* + * Add the memory regions as TDX memory. The regions in + * memblock has already guaranteed they are in address + * ascending order and don't overlap. + */ + ret = add_tdx_memblock(tmb_list, start_pfn, end_pfn); + if (ret) + goto err; + } + + return 0; +err: + free_tdx_memlist(tmb_list); + return ret; +} + static int init_tdx_module(void) { struct tdsysinfo_struct *tdsysinfo; @@ -247,10 +329,25 @@ static int init_tdx_module(void) if (ret) goto out; + /* + * To keep things simple, assume that all TDX-protected memory + * will come from the page allocator. Make sure all pages in the + * page allocator are TDX-usable memory. + * + * Build the list of "TDX-usable" memory regions which cover all + * pages in the page allocator to guarantee that. Do it while + * holding mem_hotplug_lock read-lock as the memory hotplug code + * path reads the @tdx_memlist to reject any new memory. + */ + get_online_mems(); + + ret = build_tdx_memlist(&tdx_memlist); + if (ret) + goto out_put_tdxmem; + /* * TODO: * - * - Build the list of TDX-usable memory regions. * - Construct a list of "TD Memory Regions" (TDMRs) to cover * all TDX-usable memory regions. * - Configure the TDMRs and the global KeyID to the TDX module. @@ -260,6 +357,12 @@ static int init_tdx_module(void) * Return error before all steps are done. */ ret = -EINVAL; +out_put_tdxmem: + /* + * @tdx_memlist is written here and read at memory hotplug time. + * Lock out memory hotplug code while building it. + */ + put_online_mems(); out: /* * For now both @sysinfo and @cmr_array are only used during @@ -357,6 +460,56 @@ static int __init record_keyid_partitioning(u32 *tdx_keyid_start, return 0; } +static bool is_tdx_memory(unsigned long start_pfn, unsigned long end_pfn) +{ + struct tdx_memblock *tmb; + + /* + * This check assumes that the start_pfn<->end_pfn range does not + * cross multiple @tdx_memlist entries. A single memory online + * event across multiple memblocks (from which @tdx_memlist + * entries are derived at the time of module initialization) is + * not possible. This is because memory offline/online is done + * on granularity of 'struct memory_block', and the hotpluggable + * memory region (one memblock) must be multiple of memory_block. + */ + list_for_each_entry(tmb, &tdx_memlist, list) { + if (start_pfn >= tmb->start_pfn && end_pfn <= tmb->end_pfn) + return true; + } + return false; +} + +static int tdx_memory_notifier(struct notifier_block *nb, unsigned long action, + void *v) +{ + struct memory_notify *mn = v; + + if (action != MEM_GOING_ONLINE) + return NOTIFY_OK; + + /* + * Empty list means TDX isn't enabled. Allow any memory + * to go online. + */ + if (list_empty(&tdx_memlist)) + return NOTIFY_OK; + + /* + * The TDX memory configuration is static and can not be + * changed. Reject onlining any memory which is outside of + * the static configuration whether it supports TDX or not. + */ + if (is_tdx_memory(mn->start_pfn, mn->start_pfn + mn->nr_pages)) + return NOTIFY_OK; + + return NOTIFY_BAD; +} + +static struct notifier_block tdx_memory_nb = { + .notifier_call = tdx_memory_notifier, +}; + static int __init tdx_init(void) { u32 tdx_keyid_start, nr_tdx_keyids; @@ -380,6 +533,13 @@ static int __init tdx_init(void) return -ENODEV; } + err = register_memory_notifier(&tdx_memory_nb); + if (err) { + pr_err("initialization failed: register_memory_notifier() failed (%d)\n", + err); + return -ENODEV; + } + /* * Just use the first TDX KeyID as the 'global KeyID' and * leave the rest for TDX guests. diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h index fff36af71448..39c9c6fdc11e 100644 --- a/arch/x86/virt/vmx/tdx/tdx.h +++ b/arch/x86/virt/vmx/tdx/tdx.h @@ -91,4 +91,10 @@ enum tdx_module_status_t { TDX_MODULE_ERROR }; +struct tdx_memblock { + struct list_head list; + unsigned long start_pfn; + unsigned long end_pfn; +}; + #endif From patchwork Tue Oct 17 10:14:34 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154083 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4051339vqb; Tue, 17 Oct 2023 04:04:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGYyMMUcPEO7pgtFjTjd1sk3EST04CYWxqk/OwqLaeC6hBBKAemdpBBcQ+wOpPnS6qM6I9O X-Received: by 2002:a17:902:e80c:b0:1c4:1e65:1e5e with SMTP id u12-20020a170902e80c00b001c41e651e5emr2009875plg.0.1697540649839; Tue, 17 Oct 2023 04:04:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697540649; cv=none; d=google.com; s=arc-20160816; b=D1jub8qBPdUzh9tpVNeZwqi7uGE5eyjDd/eZeYneJ59gp+iWqtE0dvCX3F4Y1DfSAQ sWP8kN1yrXf15jP5NvtO5Nj0y3RlmboiINYCtsXdCw+Ku48SqZw88TqXQHwLnv6lcqmG M8++gzyapuc4yiarZp+WXuTd/zc9X7Mb1F26Uxahy3i1U6ElxCwmPggRH2NM8ubqAujo L61Bi52pEv0vgE0dmk12Qsf6pAUCWlKVWZuXVQTw/Qd3X43Wmw0K/sdSIv7FEy1ZyumN mt9EsacAuf8I2OHFFXeNmy+Zffy6yVuFqR8Gkq3h01QjKcPzVg2FpWZpobAXGu8rpVMp Ramg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=vi+S67K9iz1+ID7NL4s1aNDdLF+h05QVpwkCgoWqBtA=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=vod5XHi2+QVfYHFt5XPUFLzkl5W7R2p4Li7t1XlhP6Eidh+YoLaY04eCi6MpMMwUo1 dWFaCwkNdcmFGdghbVz+gOUdEj7pZD6W3gHm0c2B92/phkNTEYBOZN2LAkz4poouzcDy 5s6X5gm1wK4u/idkQsTJtdRLBAFjDGh+8KHGs90VPrxW0ENXRQCFBBdWfF5iGn55yvL8 2NIFxOLMoAu5+gSFYQvzS5IIKpo18Tpf337P6pkG5cNkW5l1BWpyVgQf/yp/vcODaSir tUdmLEiiSlyGhHLwoCHs9hRrJpInIJmRYARIcOjrBWNEqGsGcE5U32OCelKPabczKYSx fnZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="h6T/X97q"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id t14-20020a170902e84e00b001ca84b9ce73si1586052plg.446.2023.10.17.04.04.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 04:04:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="h6T/X97q"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 111EE801DB15; Tue, 17 Oct 2023 04:04:06 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234843AbjJQLD4 (ORCPT + 19 others); Tue, 17 Oct 2023 07:03:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51714 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343645AbjJQKQh (ORCPT ); Tue, 17 Oct 2023 06:16:37 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C89AB182; Tue, 17 Oct 2023 03:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537765; x=1729073765; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=9dY6RLECRCet1JBs9dKs8gG3/dlOSjz1bQVPNQeewz0=; b=h6T/X97qbXQiDhKsfY9twg8KdNCEbVIaYGDVSWs1usM4W/w8FUcfdC/x xuz7F151Fpg7AYX/Xp1iVa7ErgE/xjX7kcvcRDZO888WBY2zCcspn5zSk CCmWViGxI3SXRVA2t+hnP/MIv9b1/aftqL+sm1E+ZV9ln+wZF5GWA+IRr 7zsC5F2qDwWIt0aftLh/uOGP3fvcXZodzrnD5tiGsbDv7eKnbv+Rd5f7h TiJnyLOvr7jHuKiVhAL7Uq0TXRAA3AmJUlpycNdXqAarX7uznA2Zy2MJI lnGCHvveJ4BZpdaaYkyWl1D+GVAy3bvqN7VSBlzoUI8YIJxyaQZdPF1pB Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="471972374" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="471972374" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503630" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503630" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:15:59 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 10/23] x86/virt/tdx: Add placeholder to construct TDMRs to cover all TDX memory regions Date: Tue, 17 Oct 2023 23:14:34 +1300 Message-ID: <0e1b79c227b5cfef94a632ae9b5b94643593126b.1697532085.git.kai.huang@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Tue, 17 Oct 2023 04:04:06 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780000384485962368 X-GMAIL-MSGID: 1780000384485962368 After the kernel selects all TDX-usable memory regions, the kernel needs to pass those regions to the TDX module via data structure "TD Memory Region" (TDMR). Add a placeholder to construct a list of TDMRs (in multiple steps) to cover all TDX-usable memory regions. === Long Version === TDX provides increased levels of memory confidentiality and integrity. This requires special hardware support for features like memory encryption and storage of memory integrity checksums. Not all memory satisfies these requirements. As a result, TDX introduced the concept of a "Convertible Memory Region" (CMR). During boot, the firmware builds a list of all of the memory ranges which can provide the TDX security guarantees. The list of these ranges is available to the kernel by querying the TDX module. The TDX architecture needs additional metadata to record things like which TD guest "owns" a given page of memory. This metadata essentially serves as the 'struct page' for the TDX module. The space for this metadata is not reserved by the hardware up front and must be allocated by the kernel and given to the TDX module. Since this metadata consumes space, the VMM can choose whether or not to allocate it for a given area of convertible memory. If it chooses not to, the memory cannot receive TDX protections and can not be used by TDX guests as private memory. For every memory region that the VMM wants to use as TDX memory, it sets up a "TD Memory Region" (TDMR). Each TDMR represents a physically contiguous convertible range and must also have its own physically contiguous metadata table, referred to as a Physical Address Metadata Table (PAMT), to track status for each page in the TDMR range. Unlike a CMR, each TDMR requires 1G granularity and alignment. To support physical RAM areas that don't meet those strict requirements, each TDMR permits a number of internal "reserved areas" which can be placed over memory holes. If PAMT metadata is placed within a TDMR it must be covered by one of these reserved areas. Let's summarize the concepts: CMR - Firmware-enumerated physical ranges that support TDX. CMRs are 4K aligned. TDMR - Physical address range which is chosen by the kernel to support TDX. 1G granularity and alignment required. Each TDMR has reserved areas where TDX memory holes and overlapping PAMTs can be represented. PAMT - Physically contiguous TDX metadata. One table for each page size per TDMR. Roughly 1/256th of TDMR in size. 256G TDMR = ~1G PAMT. As one step of initializing the TDX module, the kernel configures TDX-usable memory regions by passing a list of TDMRs to the TDX module. Constructing the list of TDMRs consists below steps: 1) Fill out TDMRs to cover all memory regions that the TDX module will use for TD memory. 2) Allocate and set up PAMT for each TDMR. 3) Designate reserved areas for each TDMR. Add a placeholder to construct TDMRs to do the above steps. To keep things simple, just allocate enough space to hold maximum number of TDMRs up front. Always free the buffer of TDMRs since they are only used during module initialization. Signed-off-by: Kai Huang Reviewed-by: Isaku Yamahata Reviewed-by: Dave Hansen Reviewed-by: Kirill A. Shutemov --- v13 -> v14: - No change. v12 -> v13: - No change. v11 -> v12: - Added tags from Dave/Kirill. v10 -> v11: - Changed to keep TDMRs after module initialization to deal with TDX erratum in future patches. v9 -> v10: - Changed the TDMR list from static variable back to local variable as now TDX module isn't disabled when tdx_cpu_enable() fails. v8 -> v9: - Changes around 'struct tdmr_info_list' (Dave): - Moved the declaration from tdx.c to tdx.h. - Renamed 'first_tdmr' to 'tdmrs'. - 'nr_tdmrs' -> 'nr_consumed_tdmrs'. - Changed 'tdmrs' to 'void *'. - Improved comments for all structure members. - Added a missing empty line in alloc_tdmr_list() (Dave). v7 -> v8: - Improved changelog to tell this is one step of "TODO list" in init_tdx_module(). - Other changelog improvement suggested by Dave (with "Create TDMRs" to "Fill out TDMRs" to align with the code). - Added a "TODO list" comment to lay out the steps to construct TDMRs, following the same idea of "TODO list" in tdx_module_init(). - Introduced 'struct tdmr_info_list' (Dave) - Further added additional members (tdmr_sz/max_tdmrs/nr_tdmrs) to simplify getting TDMR by given index, and reduce passing arguments around functions. - Added alloc_tdmr_list()/free_tdmr_list() accordingly, which internally uses tdmr_size_single() (Dave). - tdmr_num -> nr_tdmrs (Dave). v6 -> v7: - Improved commit message to explain 'int' overflow cannot happen in cal_tdmr_size() and alloc_tdmr_array(). -- Andy/Dave. ... --- arch/x86/virt/vmx/tdx/tdx.c | 97 ++++++++++++++++++++++++++++++++++++- arch/x86/virt/vmx/tdx/tdx.h | 32 ++++++++++++ 2 files changed, 127 insertions(+), 2 deletions(-) diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 24fa8020cc7a..675c37123d45 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include #include @@ -301,9 +302,84 @@ static int build_tdx_memlist(struct list_head *tmb_list) return ret; } +/* Calculate the actual TDMR size */ +static int tdmr_size_single(u16 max_reserved_per_tdmr) +{ + int tdmr_sz; + + /* + * The actual size of TDMR depends on the maximum + * number of reserved areas. + */ + tdmr_sz = sizeof(struct tdmr_info); + tdmr_sz += sizeof(struct tdmr_reserved_area) * max_reserved_per_tdmr; + + return ALIGN(tdmr_sz, TDMR_INFO_ALIGNMENT); +} + +static int alloc_tdmr_list(struct tdmr_info_list *tdmr_list, + struct tdsysinfo_struct *sysinfo) +{ + size_t tdmr_sz, tdmr_array_sz; + void *tdmr_array; + + tdmr_sz = tdmr_size_single(sysinfo->max_reserved_per_tdmr); + tdmr_array_sz = tdmr_sz * sysinfo->max_tdmrs; + + /* + * To keep things simple, allocate all TDMRs together. + * The buffer needs to be physically contiguous to make + * sure each TDMR is physically contiguous. + */ + tdmr_array = alloc_pages_exact(tdmr_array_sz, + GFP_KERNEL | __GFP_ZERO); + if (!tdmr_array) + return -ENOMEM; + + tdmr_list->tdmrs = tdmr_array; + + /* + * Keep the size of TDMR to find the target TDMR + * at a given index in the TDMR list. + */ + tdmr_list->tdmr_sz = tdmr_sz; + tdmr_list->max_tdmrs = sysinfo->max_tdmrs; + tdmr_list->nr_consumed_tdmrs = 0; + + return 0; +} + +static void free_tdmr_list(struct tdmr_info_list *tdmr_list) +{ + free_pages_exact(tdmr_list->tdmrs, + tdmr_list->max_tdmrs * tdmr_list->tdmr_sz); +} + +/* + * Construct a list of TDMRs on the preallocated space in @tdmr_list + * to cover all TDX memory regions in @tmb_list based on the TDX module + * information in @sysinfo. + */ +static int construct_tdmrs(struct list_head *tmb_list, + struct tdmr_info_list *tdmr_list, + struct tdsysinfo_struct *sysinfo) +{ + /* + * TODO: + * + * - Fill out TDMRs to cover all TDX memory regions. + * - Allocate and set up PAMTs for each TDMR. + * - Designate reserved areas for each TDMR. + * + * Return -EINVAL until constructing TDMRs is done + */ + return -EINVAL; +} + static int init_tdx_module(void) { struct tdsysinfo_struct *tdsysinfo; + struct tdmr_info_list tdmr_list; struct cmr_info *cmr_array; int tdsysinfo_size; int cmr_array_size; @@ -345,11 +421,19 @@ static int init_tdx_module(void) if (ret) goto out_put_tdxmem; + /* Allocate enough space for constructing TDMRs */ + ret = alloc_tdmr_list(&tdmr_list, tdsysinfo); + if (ret) + goto out_free_tdxmem; + + /* Cover all TDX-usable memory regions in TDMRs */ + ret = construct_tdmrs(&tdx_memlist, &tdmr_list, tdsysinfo); + if (ret) + goto out_free_tdmrs; + /* * TODO: * - * - Construct a list of "TD Memory Regions" (TDMRs) to cover - * all TDX-usable memory regions. * - Configure the TDMRs and the global KeyID to the TDX module. * - Configure the global KeyID on all packages. * - Initialize all TDMRs. @@ -357,6 +441,15 @@ static int init_tdx_module(void) * Return error before all steps are done. */ ret = -EINVAL; +out_free_tdmrs: + /* + * Always free the buffer of TDMRs as they are only used during + * module initialization. + */ + free_tdmr_list(&tdmr_list); +out_free_tdxmem: + if (ret) + free_tdx_memlist(&tdx_memlist); out_put_tdxmem: /* * @tdx_memlist is written here and read at memory hotplug time. diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h index 39c9c6fdc11e..536d89928cd6 100644 --- a/arch/x86/virt/vmx/tdx/tdx.h +++ b/arch/x86/virt/vmx/tdx/tdx.h @@ -79,6 +79,29 @@ struct tdsysinfo_struct { DECLARE_FLEX_ARRAY(struct cpuid_config, cpuid_configs); } __packed; +struct tdmr_reserved_area { + u64 offset; + u64 size; +} __packed; + +#define TDMR_INFO_ALIGNMENT 512 + +struct tdmr_info { + u64 base; + u64 size; + u64 pamt_1g_base; + u64 pamt_1g_size; + u64 pamt_2m_base; + u64 pamt_2m_size; + u64 pamt_4k_base; + u64 pamt_4k_size; + /* + * Actual number of reserved areas depends on + * 'struct tdsysinfo_struct'::max_reserved_per_tdmr. + */ + DECLARE_FLEX_ARRAY(struct tdmr_reserved_area, reserved_areas); +} __packed __aligned(TDMR_INFO_ALIGNMENT); + /* * Do not put any hardware-defined TDX structure representations below * this comment! @@ -97,4 +120,13 @@ struct tdx_memblock { unsigned long end_pfn; }; +struct tdmr_info_list { + void *tdmrs; /* Flexible array to hold 'tdmr_info's */ + int nr_consumed_tdmrs; /* How many 'tdmr_info's are in use */ + + /* Metadata for finding target 'tdmr_info' and freeing @tdmrs */ + int tdmr_sz; /* Size of one 'tdmr_info' */ + int max_tdmrs; /* How many 'tdmr_info's are allocated */ +}; + #endif From patchwork Tue Oct 17 10:14:35 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154038 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4030854vqb; Tue, 17 Oct 2023 03:17:46 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEOw9mn8Gx/opluKs8xZjkAHIHXCkwDSITTUKE85mEkW5EMbshr03SYXsXfeevwOnYV/OXc X-Received: by 2002:a05:6a20:7d97:b0:171:947f:465b with SMTP id v23-20020a056a207d9700b00171947f465bmr1725853pzj.4.1697537866026; Tue, 17 Oct 2023 03:17:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537866; cv=none; d=google.com; s=arc-20160816; b=wStn9PU4IGNXy7D6SCS9OJLSjWUhySKyOvfWZVyUUcPMXRJGNsD2q+c83WsUEvdkCP wQE0os1ZPHA1hYdEob5pWQkoO0i7GhHX/MMCIZqfT20Z9sV53ilMUC92AjZ8MsfM2eqs wDpUUq7VLOl2Kfg39dvbsR2HWYajOgVdHfsTFTV8yGUA66rh8WZMv5sHVc7BymqeIESk 1c+fB2eI/epXnG2iJM6rUhKWIlZopRp8bKwP7gOlvgG6x+z+/uTYbmwLg8YcEvuhMfcZ TvtjrS+du1J5+dSk+gSwqyuNYx1QcTvy9qDhR1E2an5M4sgX68lCh7XgqCgF4v2aiJE0 qkVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=bqqb+PAwtHBjgI7jWapdeGmFBySF1jilelwNFVLbsMk=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=HXwJDhjDc+xE9APUDVuSQHLZLhfZLvfrruvIHts2r1+yffu62zShre7aVcpra5h75r azk47J1QYbiVAY7RjFK9n9Zl299XbqS+1SPVxAEnURMbv3+P39gBULw9d3DvYdSelUc6 mNaR5vgnqbZTxtE+9CIaoMl8x4Oykh5Vjrf5CiwQ+uP/Skt5jFAx6sv9nvJAEaaQBiQM fFb71TgZETYcoVZYyuXEX2rh7vg/DylxmvCfvI6/U4DWnOvncvUgyII9KLtDEAAIWnxt GeRBFEQ848srFg2pdJVSDCu6Qd54w+NIPVv6f+X0aLRN058eQeOalEyiSr0sNApcloi/ wFBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=biZAGmYP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from pete.vger.email (pete.vger.email. [2620:137:e000::3:6]) by mx.google.com with ESMTPS id w11-20020a17090aea0b00b0027ced219f06si7976506pjy.128.2023.10.17.03.17.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:17:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=biZAGmYP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id EB04480811CF; Tue, 17 Oct 2023 03:17:42 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343655AbjJQKRU (ORCPT + 19 others); Tue, 17 Oct 2023 06:17:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343710AbjJQKQ4 (ORCPT ); Tue, 17 Oct 2023 06:16:56 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BB87AED; Tue, 17 Oct 2023 03:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537771; x=1729073771; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=+SfivUCYbdTg+Nz3SrNJg6w4OhV0FV9TY5y/jlHe+q4=; b=biZAGmYP1L6GSe6SmezwdUjFEA8l5NV7CCLmaycMmyuHV3VVu5QWf1aO IUaPBGjj2EkuLifJP9Zp2+RUSc0ADrBe1/+vqaUNr6IzKldV5ReiJ6DX7 rBhnsHU21+fpxzlgqJxD2C8VXfKjBj2Ik+VzZaZUNjqh4dvz/FiN+dV2W ZZyyQUoncaPeHO5x4wr1E4ws1TQMRHSSiexGFXNV1zYdMFzbOCMVD9Ged jqf4GXiOsjmxi52KlImlnqoGBnRTVwj/zQc09l0AE8PsTjcGTCmQWqULQ zPC3e/AISjVAGZLrlVPFsic2LqQ7JlNjiEflR9RphXNu2LB3qFP1Bn2UL A==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="471972405" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="471972405" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503645" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503645" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:05 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 11/23] x86/virt/tdx: Fill out TDMRs to cover all TDX memory regions Date: Tue, 17 Oct 2023 23:14:35 +1300 Message-ID: <5f5c66b7826df280437b832dfc59d32ba2bfc93b.1697532085.git.kai.huang@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:17:43 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997465378374040 X-GMAIL-MSGID: 1779997465378374040 Start to transit out the "multi-steps" to construct a list of "TD Memory Regions" (TDMRs) to cover all TDX-usable memory regions. The kernel configures TDX-usable memory regions by passing a list of TDMRs "TD Memory Regions" (TDMRs) to the TDX module. Each TDMR contains the information of the base/size of a memory region, the base/size of the associated Physical Address Metadata Table (PAMT) and a list of reserved areas in the region. Do the first step to fill out a number of TDMRs to cover all TDX memory regions. To keep it simple, always try to use one TDMR for each memory region. As the first step only set up the base/size for each TDMR. Each TDMR must be 1G aligned and the size must be in 1G granularity. This implies that one TDMR could cover multiple memory regions. If a memory region spans the 1GB boundary and the former part is already covered by the previous TDMR, just use a new TDMR for the remaining part. TDX only supports a limited number of TDMRs. Disable TDX if all TDMRs are consumed but there is more memory region to cover. There are fancier things that could be done like trying to merge adjacent TDMRs. This would allow more pathological memory layouts to be supported. But, current systems are not even close to exhausting the existing TDMR resources in practice. For now, keep it simple. Signed-off-by: Kai Huang Reviewed-by: Kirill A. Shutemov Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Yuan Yao --- v13 -> v14: - No change v12 -> v13: - Added Yuan's tag. v11 -> v12: - Improved comments around looping over TDX memblock to create TDMRs. (Dave). - Added code to pr_warn() when consumed TDMRs reaching maximum TDMRs (Dave). - BIT_ULL(30) -> SZ_1G (Kirill) - Removed unused TDMR_PFN_ALIGNMENT (Sathy) - Added tags from Kirill/Sathy v10 -> v11: - No update v9 -> v10: - No change. v8 -> v9: - Added the last paragraph in the changelog (Dave). - Removed unnecessary type cast in tdmr_entry() (Dave). --- arch/x86/virt/vmx/tdx/tdx.c | 103 +++++++++++++++++++++++++++++++++++- arch/x86/virt/vmx/tdx/tdx.h | 3 ++ 2 files changed, 105 insertions(+), 1 deletion(-) diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 675c37123d45..9a179ff32ac7 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -355,6 +355,102 @@ static void free_tdmr_list(struct tdmr_info_list *tdmr_list) tdmr_list->max_tdmrs * tdmr_list->tdmr_sz); } +/* Get the TDMR from the list at the given index. */ +static struct tdmr_info *tdmr_entry(struct tdmr_info_list *tdmr_list, + int idx) +{ + int tdmr_info_offset = tdmr_list->tdmr_sz * idx; + + return (void *)tdmr_list->tdmrs + tdmr_info_offset; +} + +#define TDMR_ALIGNMENT SZ_1G +#define TDMR_ALIGN_DOWN(_addr) ALIGN_DOWN((_addr), TDMR_ALIGNMENT) +#define TDMR_ALIGN_UP(_addr) ALIGN((_addr), TDMR_ALIGNMENT) + +static inline u64 tdmr_end(struct tdmr_info *tdmr) +{ + return tdmr->base + tdmr->size; +} + +/* + * Take the memory referenced in @tmb_list and populate the + * preallocated @tdmr_list, following all the special alignment + * and size rules for TDMR. + */ +static int fill_out_tdmrs(struct list_head *tmb_list, + struct tdmr_info_list *tdmr_list) +{ + struct tdx_memblock *tmb; + int tdmr_idx = 0; + + /* + * Loop over TDX memory regions and fill out TDMRs to cover them. + * To keep it simple, always try to use one TDMR to cover one + * memory region. + * + * In practice TDX supports at least 64 TDMRs. A 2-socket system + * typically only consumes less than 10 of those. This code is + * dumb and simple and may use more TMDRs than is strictly + * required. + */ + list_for_each_entry(tmb, tmb_list, list) { + struct tdmr_info *tdmr = tdmr_entry(tdmr_list, tdmr_idx); + u64 start, end; + + start = TDMR_ALIGN_DOWN(PFN_PHYS(tmb->start_pfn)); + end = TDMR_ALIGN_UP(PFN_PHYS(tmb->end_pfn)); + + /* + * A valid size indicates the current TDMR has already + * been filled out to cover the previous memory region(s). + */ + if (tdmr->size) { + /* + * Loop to the next if the current memory region + * has already been fully covered. + */ + if (end <= tdmr_end(tdmr)) + continue; + + /* Otherwise, skip the already covered part. */ + if (start < tdmr_end(tdmr)) + start = tdmr_end(tdmr); + + /* + * Create a new TDMR to cover the current memory + * region, or the remaining part of it. + */ + tdmr_idx++; + if (tdmr_idx >= tdmr_list->max_tdmrs) { + pr_warn("initialization failed: TDMRs exhausted.\n"); + return -ENOSPC; + } + + tdmr = tdmr_entry(tdmr_list, tdmr_idx); + } + + tdmr->base = start; + tdmr->size = end - start; + } + + /* @tdmr_idx is always the index of the last valid TDMR. */ + tdmr_list->nr_consumed_tdmrs = tdmr_idx + 1; + + /* + * Warn early that kernel is about to run out of TDMRs. + * + * This is an indication that TDMR allocation has to be + * reworked to be smarter to not run into an issue. + */ + if (tdmr_list->max_tdmrs - tdmr_list->nr_consumed_tdmrs < TDMR_NR_WARN) + pr_warn("consumed TDMRs reaching limit: %d used out of %d\n", + tdmr_list->nr_consumed_tdmrs, + tdmr_list->max_tdmrs); + + return 0; +} + /* * Construct a list of TDMRs on the preallocated space in @tdmr_list * to cover all TDX memory regions in @tmb_list based on the TDX module @@ -364,10 +460,15 @@ static int construct_tdmrs(struct list_head *tmb_list, struct tdmr_info_list *tdmr_list, struct tdsysinfo_struct *sysinfo) { + int ret; + + ret = fill_out_tdmrs(tmb_list, tdmr_list); + if (ret) + return ret; + /* * TODO: * - * - Fill out TDMRs to cover all TDX memory regions. * - Allocate and set up PAMTs for each TDMR. * - Designate reserved areas for each TDMR. * diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h index 536d89928cd6..15afd6a56fdc 100644 --- a/arch/x86/virt/vmx/tdx/tdx.h +++ b/arch/x86/virt/vmx/tdx/tdx.h @@ -120,6 +120,9 @@ struct tdx_memblock { unsigned long end_pfn; }; +/* Warn if kernel has less than TDMR_NR_WARN TDMRs after allocation */ +#define TDMR_NR_WARN 4 + struct tdmr_info_list { void *tdmrs; /* Flexible array to hold 'tdmr_info's */ int nr_consumed_tdmrs; /* How many 'tdmr_info's are in use */ From patchwork Tue Oct 17 10:14:36 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154039 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4030912vqb; Tue, 17 Oct 2023 03:17:52 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFhfJ3356vndSPX8RPXQ9Sw6ndzSEaAktzCRm5viY3AVyKl94Ln1YS+C5UtV06uIjEHpC74 X-Received: by 2002:a05:6a00:4809:b0:6b9:7d5c:bb58 with SMTP id di9-20020a056a00480900b006b97d5cbb58mr1819493pfb.0.1697537872684; Tue, 17 Oct 2023 03:17:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537872; cv=none; d=google.com; s=arc-20160816; b=HgJNXRULkkP7T4qcdnCuXTg1k6JgS/ABiCGLSb6Weu1/N9mR/H4Tlimnp6ogcRwFWn H1UomJ7GfEp5OY1XI7nksIDsEr8oYFUzCrb5Wu1/NxzKrW+7JfsLeWNNDFA6BW6MF3dC 4DYeOABAcBSDrTm8XBDjvhCVP4wejHX3FMiCgO0PlIerN8nJRUIFqEOOVVAMgBrypYUK HjVp2kYgeVJIi47jAyNH78JzM7meBS14/CcToErDMlyPw0RMRMXpgx58yfoYtlonw95t 9cagU2ZFWshSSIns6WizLw67+lhTHXz6Rm6ziqsaBMVCYIt4UBtqfWa8NovDUzYiF9bG 1LDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=iIjzTeBe/sljZPO10U7XYLFwq8c/I+hfweBYVJpYe5Y=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=MAI4c34fab01pKMD+ZkVYcqAXfqMfKKDuFlEzR+Qu6KEdAAS2zo5QL9pby6tx2yZEz IYsWWPDyy9J6f6riKDvDmph0Pu2ljdykKGVavo+TQGM/Eo8mJRu8g4qY+kbW1xbZ9/k7 1QGN/zsnRuqgtzpQCXN5kvIqgzawmWobvrDAIfFZ2tMwFVh83KI9Qcd3QdJrQJ9CSwWo kP+VXGrSsbOD3x7qpxREMEmAjEPYZk2emSDAF+NcXzdHx3Z/xduxjwqPJO8OQckYwwb4 LFuecBUfdzIG60UHbiiMwU/ShYSgRXdu0+GMMAPMK7/8qXhUJ9wyjQROiCPgNN/OYU0y 6OiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=OXaasvZ+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id t191-20020a6381c8000000b00563de199314si1435427pgd.896.2023.10.17.03.17.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:17:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=OXaasvZ+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 2779C80C256E; Tue, 17 Oct 2023 03:17:49 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343712AbjJQKRa (ORCPT + 19 others); Tue, 17 Oct 2023 06:17:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343787AbjJQKRL (ORCPT ); Tue, 17 Oct 2023 06:17:11 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6363D4C; Tue, 17 Oct 2023 03:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537777; x=1729073777; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=KJcWRoUzjfSW3yOXq/iAQjxyd+J5U+kor2OY1W8U8XM=; b=OXaasvZ++GywPQ7T6VYkRUuzfiVYLzHQwUdgMyL7Px8F+I+EsfTikh3b +pbMEyEaGCOkFUIMAJAQtfTlZnvf1YBxisfYjSYrAkIIgx2rPJpw8nG/A QFutzWsikJIoYFnsO+/502Y8IuPiBrzQxA2qkdYy+hw0xGVQ89roMgAWa F2LJ4KDSrefRVglZBPKdsZ6czCFEuHXyfmBDXuDMBrBBOmsIpowlWg1Il io2hK9qBm9wTWx3rhHjrsRZZLB01Xb1x/mhJf48p63psv9JRwO7JSSTnT 5EtYVHxQD3wPxu30LY8uXhUWq3NuYBECgqnqa3XgjTRwQCEDC+c9SSCss g==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="471972424" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="471972424" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503655" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503655" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:11 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 12/23] x86/virt/tdx: Allocate and set up PAMTs for TDMRs Date: Tue, 17 Oct 2023 23:14:36 +1300 Message-ID: X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:17:49 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997472221479664 X-GMAIL-MSGID: 1779997472221479664 The TDX module uses additional metadata to record things like which guest "owns" a given page of memory. This metadata, referred as Physical Address Metadata Table (PAMT), essentially serves as the 'struct page' for the TDX module. PAMTs are not reserved by hardware up front. They must be allocated by the kernel and then given to the TDX module during module initialization. TDX supports 3 page sizes: 4K, 2M, and 1G. Each "TD Memory Region" (TDMR) has 3 PAMTs to track the 3 supported page sizes. Each PAMT must be a physically contiguous area from a Convertible Memory Region (CMR). However, the PAMTs which track pages in one TDMR do not need to reside within that TDMR but can be anywhere in CMRs. If one PAMT overlaps with any TDMR, the overlapping part must be reported as a reserved area in that particular TDMR. Use alloc_contig_pages() since PAMT must be a physically contiguous area and it may be potentially large (~1/256th of the size of the given TDMR). The downside is alloc_contig_pages() may fail at runtime. One (bad) mitigation is to launch a TDX guest early during system boot to get those PAMTs allocated at early time, but the only way to fix is to add a boot option to allocate or reserve PAMTs during kernel boot. It is imperfect but will be improved on later. TDX only supports a limited number of reserved areas per TDMR to cover both PAMTs and memory holes within the given TDMR. If many PAMTs are allocated within a single TDMR, the reserved areas may not be sufficient to cover all of them. Adopt the following policies when allocating PAMTs for a given TDMR: - Allocate three PAMTs of the TDMR in one contiguous chunk to minimize the total number of reserved areas consumed for PAMTs. - Try to first allocate PAMT from the local node of the TDMR for better NUMA locality. Also dump out how many pages are allocated for PAMTs when the TDX module is initialized successfully. This helps answer the eternal "where did all my memory go?" questions. Signed-off-by: Kai Huang Reviewed-by: Isaku Yamahata Reviewed-by: Dave Hansen Reviewed-by: Kirill A. Shutemov Reviewed-by: Yuan Yao --- v13 -> v14: - No change v12 -> v13: - Added Kirill and Yuan's tag. - Removed unintended space. (Yuan) v11 -> v12: - Moved TDX_PS_NUM from tdx.c to (Kirill) - "<= TDX_PS_1G" -> "< TDX_PS_NUM" (Kirill) - Changed tdmr_get_pamt() to return base and size instead of base_pfn and npages and related code directly (Dave). - Simplified PAMT kb counting. (Dave) - tdmrs_count_pamt_pages() -> tdmr_count_pamt_kb() (Kirill/Dave) v10 -> v11: - No update v9 -> v10: - Removed code change in disable_tdx_module() as it doesn't exist anymore. v8 -> v9: - Added TDX_PS_NR macro instead of open-coding (Dave). - Better alignment of 'pamt_entry_size' in tdmr_set_up_pamt() (Dave). - Changed to print out PAMTs in "KBs" instead of "pages" (Dave). - Added Dave's Reviewed-by. v7 -> v8: (Dave) - Changelog: - Added a sentence to state PAMT allocation will be improved. - Others suggested by Dave. - Moved 'nid' of 'struct tdx_memblock' to this patch. - Improved comments around tdmr_get_nid(). - WARN_ON_ONCE() -> pr_warn() in tdmr_get_nid(). - Other changes due to 'struct tdmr_info_list'. v6 -> v7: - Changes due to using macros instead of 'enum' for TDX supported page sizes. v5 -> v6: - Rebase due to using 'tdx_memblock' instead of memblock. - 'int pamt_entry_nr' -> 'unsigned long nr_pamt_entries' (Dave/Sagis). - Improved comment around tdmr_get_nid() (Dave). - Improved comment in tdmr_set_up_pamt() around breaking the PAMT into PAMTs for 4K/2M/1G (Dave). - tdmrs_get_pamt_pages() -> tdmrs_count_pamt_pages() (Dave). --- arch/x86/Kconfig | 1 + arch/x86/include/asm/shared/tdx.h | 1 + arch/x86/virt/vmx/tdx/tdx.c | 215 +++++++++++++++++++++++++++++- arch/x86/virt/vmx/tdx/tdx.h | 1 + 4 files changed, 213 insertions(+), 5 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 864e43b008b1..ee4ac117aa3c 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1946,6 +1946,7 @@ config INTEL_TDX_HOST depends on KVM_INTEL depends on X86_X2APIC select ARCH_KEEP_MEMBLOCK + depends on CONTIG_ALLOC help Intel Trust Domain Extensions (TDX) protects guest VMs from malicious host and certain physical attacks. This option enables necessary TDX diff --git a/arch/x86/include/asm/shared/tdx.h b/arch/x86/include/asm/shared/tdx.h index abcca86b5af3..cb59fe329b00 100644 --- a/arch/x86/include/asm/shared/tdx.h +++ b/arch/x86/include/asm/shared/tdx.h @@ -58,6 +58,7 @@ #define TDX_PS_4K 0 #define TDX_PS_2M 1 #define TDX_PS_1G 2 +#define TDX_PS_NR (TDX_PS_1G + 1) #ifndef __ASSEMBLY__ diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 9a179ff32ac7..54ce2c1df2f1 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -235,7 +235,7 @@ static int get_tdx_sysinfo(struct tdsysinfo_struct *tdsysinfo, * overlap. */ static int add_tdx_memblock(struct list_head *tmb_list, unsigned long start_pfn, - unsigned long end_pfn) + unsigned long end_pfn, int nid) { struct tdx_memblock *tmb; @@ -246,6 +246,7 @@ static int add_tdx_memblock(struct list_head *tmb_list, unsigned long start_pfn, INIT_LIST_HEAD(&tmb->list); tmb->start_pfn = start_pfn; tmb->end_pfn = end_pfn; + tmb->nid = nid; /* @tmb_list is protected by mem_hotplug_lock */ list_add_tail(&tmb->list, tmb_list); @@ -273,9 +274,9 @@ static void free_tdx_memlist(struct list_head *tmb_list) static int build_tdx_memlist(struct list_head *tmb_list) { unsigned long start_pfn, end_pfn; - int i, ret; + int i, nid, ret; - for_each_mem_pfn_range(i, MAX_NUMNODES, &start_pfn, &end_pfn, NULL) { + for_each_mem_pfn_range(i, MAX_NUMNODES, &start_pfn, &end_pfn, &nid) { /* * The first 1MB is not reported as TDX convertible memory. * Although the first 1MB is always reserved and won't end up @@ -291,7 +292,7 @@ static int build_tdx_memlist(struct list_head *tmb_list) * memblock has already guaranteed they are in address * ascending order and don't overlap. */ - ret = add_tdx_memblock(tmb_list, start_pfn, end_pfn); + ret = add_tdx_memblock(tmb_list, start_pfn, end_pfn, nid); if (ret) goto err; } @@ -451,6 +452,202 @@ static int fill_out_tdmrs(struct list_head *tmb_list, return 0; } +/* + * Calculate PAMT size given a TDMR and a page size. The returned + * PAMT size is always aligned up to 4K page boundary. + */ +static unsigned long tdmr_get_pamt_sz(struct tdmr_info *tdmr, int pgsz, + u16 pamt_entry_size) +{ + unsigned long pamt_sz, nr_pamt_entries; + + switch (pgsz) { + case TDX_PS_4K: + nr_pamt_entries = tdmr->size >> PAGE_SHIFT; + break; + case TDX_PS_2M: + nr_pamt_entries = tdmr->size >> PMD_SHIFT; + break; + case TDX_PS_1G: + nr_pamt_entries = tdmr->size >> PUD_SHIFT; + break; + default: + WARN_ON_ONCE(1); + return 0; + } + + pamt_sz = nr_pamt_entries * pamt_entry_size; + /* TDX requires PAMT size must be 4K aligned */ + pamt_sz = ALIGN(pamt_sz, PAGE_SIZE); + + return pamt_sz; +} + +/* + * Locate a NUMA node which should hold the allocation of the @tdmr + * PAMT. This node will have some memory covered by the TDMR. The + * relative amount of memory covered is not considered. + */ +static int tdmr_get_nid(struct tdmr_info *tdmr, struct list_head *tmb_list) +{ + struct tdx_memblock *tmb; + + /* + * A TDMR must cover at least part of one TMB. That TMB will end + * after the TDMR begins. But, that TMB may have started before + * the TDMR. Find the next 'tmb' that _ends_ after this TDMR + * begins. Ignore 'tmb' start addresses. They are irrelevant. + */ + list_for_each_entry(tmb, tmb_list, list) { + if (tmb->end_pfn > PHYS_PFN(tdmr->base)) + return tmb->nid; + } + + /* + * Fall back to allocating the TDMR's metadata from node 0 when + * no TDX memory block can be found. This should never happen + * since TDMRs originate from TDX memory blocks. + */ + pr_warn("TDMR [0x%llx, 0x%llx): unable to find local NUMA node for PAMT allocation, fallback to use node 0.\n", + tdmr->base, tdmr_end(tdmr)); + return 0; +} + +/* + * Allocate PAMTs from the local NUMA node of some memory in @tmb_list + * within @tdmr, and set up PAMTs for @tdmr. + */ +static int tdmr_set_up_pamt(struct tdmr_info *tdmr, + struct list_head *tmb_list, + u16 pamt_entry_size) +{ + unsigned long pamt_base[TDX_PS_NR]; + unsigned long pamt_size[TDX_PS_NR]; + unsigned long tdmr_pamt_base; + unsigned long tdmr_pamt_size; + struct page *pamt; + int pgsz, nid; + + nid = tdmr_get_nid(tdmr, tmb_list); + + /* + * Calculate the PAMT size for each TDX supported page size + * and the total PAMT size. + */ + tdmr_pamt_size = 0; + for (pgsz = TDX_PS_4K; pgsz < TDX_PS_NR; pgsz++) { + pamt_size[pgsz] = tdmr_get_pamt_sz(tdmr, pgsz, + pamt_entry_size); + tdmr_pamt_size += pamt_size[pgsz]; + } + + /* + * Allocate one chunk of physically contiguous memory for all + * PAMTs. This helps minimize the PAMT's use of reserved areas + * in overlapped TDMRs. + */ + pamt = alloc_contig_pages(tdmr_pamt_size >> PAGE_SHIFT, GFP_KERNEL, + nid, &node_online_map); + if (!pamt) + return -ENOMEM; + + /* + * Break the contiguous allocation back up into the + * individual PAMTs for each page size. + */ + tdmr_pamt_base = page_to_pfn(pamt) << PAGE_SHIFT; + for (pgsz = TDX_PS_4K; pgsz < TDX_PS_NR; pgsz++) { + pamt_base[pgsz] = tdmr_pamt_base; + tdmr_pamt_base += pamt_size[pgsz]; + } + + tdmr->pamt_4k_base = pamt_base[TDX_PS_4K]; + tdmr->pamt_4k_size = pamt_size[TDX_PS_4K]; + tdmr->pamt_2m_base = pamt_base[TDX_PS_2M]; + tdmr->pamt_2m_size = pamt_size[TDX_PS_2M]; + tdmr->pamt_1g_base = pamt_base[TDX_PS_1G]; + tdmr->pamt_1g_size = pamt_size[TDX_PS_1G]; + + return 0; +} + +static void tdmr_get_pamt(struct tdmr_info *tdmr, unsigned long *pamt_base, + unsigned long *pamt_size) +{ + unsigned long pamt_bs, pamt_sz; + + /* + * The PAMT was allocated in one contiguous unit. The 4K PAMT + * should always point to the beginning of that allocation. + */ + pamt_bs = tdmr->pamt_4k_base; + pamt_sz = tdmr->pamt_4k_size + tdmr->pamt_2m_size + tdmr->pamt_1g_size; + + WARN_ON_ONCE((pamt_bs & ~PAGE_MASK) || (pamt_sz & ~PAGE_MASK)); + + *pamt_base = pamt_bs; + *pamt_size = pamt_sz; +} + +static void tdmr_free_pamt(struct tdmr_info *tdmr) +{ + unsigned long pamt_base, pamt_size; + + tdmr_get_pamt(tdmr, &pamt_base, &pamt_size); + + /* Do nothing if PAMT hasn't been allocated for this TDMR */ + if (!pamt_size) + return; + + if (WARN_ON_ONCE(!pamt_base)) + return; + + free_contig_range(pamt_base >> PAGE_SHIFT, pamt_size >> PAGE_SHIFT); +} + +static void tdmrs_free_pamt_all(struct tdmr_info_list *tdmr_list) +{ + int i; + + for (i = 0; i < tdmr_list->nr_consumed_tdmrs; i++) + tdmr_free_pamt(tdmr_entry(tdmr_list, i)); +} + +/* Allocate and set up PAMTs for all TDMRs */ +static int tdmrs_set_up_pamt_all(struct tdmr_info_list *tdmr_list, + struct list_head *tmb_list, + u16 pamt_entry_size) +{ + int i, ret = 0; + + for (i = 0; i < tdmr_list->nr_consumed_tdmrs; i++) { + ret = tdmr_set_up_pamt(tdmr_entry(tdmr_list, i), tmb_list, + pamt_entry_size); + if (ret) + goto err; + } + + return 0; +err: + tdmrs_free_pamt_all(tdmr_list); + return ret; +} + +static unsigned long tdmrs_count_pamt_kb(struct tdmr_info_list *tdmr_list) +{ + unsigned long pamt_size = 0; + int i; + + for (i = 0; i < tdmr_list->nr_consumed_tdmrs; i++) { + unsigned long base, size; + + tdmr_get_pamt(tdmr_entry(tdmr_list, i), &base, &size); + pamt_size += size; + } + + return pamt_size / 1024; +} + /* * Construct a list of TDMRs on the preallocated space in @tdmr_list * to cover all TDX memory regions in @tmb_list based on the TDX module @@ -466,10 +663,13 @@ static int construct_tdmrs(struct list_head *tmb_list, if (ret) return ret; + ret = tdmrs_set_up_pamt_all(tdmr_list, tmb_list, + sysinfo->pamt_entry_size); + if (ret) + return ret; /* * TODO: * - * - Allocate and set up PAMTs for each TDMR. * - Designate reserved areas for each TDMR. * * Return -EINVAL until constructing TDMRs is done @@ -542,6 +742,11 @@ static int init_tdx_module(void) * Return error before all steps are done. */ ret = -EINVAL; + if (ret) + tdmrs_free_pamt_all(&tdmr_list); + else + pr_info("%lu KBs allocated for PAMT\n", + tdmrs_count_pamt_kb(&tdmr_list)); out_free_tdmrs: /* * Always free the buffer of TDMRs as they are only used during diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h index 15afd6a56fdc..6987af46d096 100644 --- a/arch/x86/virt/vmx/tdx/tdx.h +++ b/arch/x86/virt/vmx/tdx/tdx.h @@ -118,6 +118,7 @@ struct tdx_memblock { struct list_head list; unsigned long start_pfn; unsigned long end_pfn; + int nid; }; /* Warn if kernel has less than TDMR_NR_WARN TDMRs after allocation */ From patchwork Tue Oct 17 10:14:37 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154040 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4030962vqb; Tue, 17 Oct 2023 03:17:58 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF5cn0HK6mdzT52zYsPz6j/gargWxy4u/hr6d3hprg9fYQQPxHlQYWVlIUHgRtsBlOziNbm X-Received: by 2002:a17:902:760d:b0:1c6:2b3d:d918 with SMTP id k13-20020a170902760d00b001c62b3dd918mr1878341pll.3.1697537878501; Tue, 17 Oct 2023 03:17:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537878; cv=none; d=google.com; s=arc-20160816; b=lca09FLSJgwVVzdMAbzuZrzCrIsuA6lJRbGVdfRoN4VdjUQfiLbeas7wwJLIZMiIpb YMkvP21gbjndPUveKpmrmpaS2q4asPz2f/U5RK2bjcvO8NWPZCOYPW+chATm+MCugucY 8Q8RsL1djwb4SOkxVTSYAp7368xEL7gHD4DpL0+x7pDecz9eREIMD5yz0DB3vHw/Rlwe mFwFDbVmk+ENbvJnPFwmZfxXcH9Ucv4bRbOO4wmkm3AZCVjW8utwbaVQmcEroudA5xHz wBNBe0hjcsM3R1x5+On1Aessa4WkNQ9ViE4vcD3U6AeL2377q99RteI/vlvzFADEi8qF h6Xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=mq8V43K2LUM0qmcYOyFNVwRveSrQqaLkzrQBl4AZaQ0=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=U/1T/fhvAXj38vfswle9zSSVs9kaN32a/ufjlRb0FbkN8jtWiMAoRSIys53S27ZHrv +mFD+1V7DulJdmNmTrk2ievnBTQTWFU+7CIITQr25cqvd/aDzcuhrkRLxXd2/CEbjNm6 4gLr5Ojn44qRxyNoUpMQlbMESu/lEpTBF3e1uRDrUiXBelkdU2PkXNJAXBhdKQ+IWXqJ Hc6L+AiNaXjD/uQ1UexQggpCbsXri3UllgXp9HXE5+97jbID6SxJljf0a2jZ3xUq1TxH ql/POY4h8nPyPF9Ehmrc1CLIqn+EylppbjhLEMGfDfX3a21/AvwSPdxu6Z2Yck3+vbFY i/Pw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="J6l/dos8"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id li11-20020a170903294b00b001c61af1e683si1327549plb.641.2023.10.17.03.17.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:17:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="J6l/dos8"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id E2CF7802F703; Tue, 17 Oct 2023 03:17:53 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343684AbjJQKRn (ORCPT + 19 others); Tue, 17 Oct 2023 06:17:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40072 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343656AbjJQKRU (ORCPT ); Tue, 17 Oct 2023 06:17:20 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C04121994; Tue, 17 Oct 2023 03:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537783; x=1729073783; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=hSsl9Y1BWUbpmejzKUmHCev1idIS3F9RBhX2aa6XS1A=; b=J6l/dos8LZ3/52OX80y4n90G7PJtyKj5Rrk/h6Gva99Zp5+rL+hPZIK7 2jPr0bpHAxmovhnccRRQdZAf3z7x54UZPJfNxSdfCcwrl4UrrZkV0ZSRH hdW5aISDwVAaUq5L0xkdLhQkgrYrEJyTbrSw5cXj1OTAWcHZLyR04Htvo q+AQr1UTHq4jUKXlwJkCaRrFdhsDfrl/Zlfh6+CtxxbzejPsSdS5upAQk DQ+/zM9nQ3KqaSBRj7H0thZy1MT3iGtR9KWwsQ8EJHGs/XvHJRE2cqyts iu+2gii+eoAIIJDOH3trY1q22WjzejR0cdnG8f32r8oG6E0GL2/sk4zno g==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="471972438" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="471972438" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503687" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503687" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:17 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 13/23] x86/virt/tdx: Designate reserved areas for all TDMRs Date: Tue, 17 Oct 2023 23:14:37 +1300 Message-ID: <1b8dc97182530dff08964a1daca0fb7c7158fc8e.1697532085.git.kai.huang@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:17:53 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997478507714402 X-GMAIL-MSGID: 1779997478507714402 As the last step of constructing TDMRs, populate reserved areas for all TDMRs. For each TDMR, put all memory holes within this TDMR to the reserved areas. And for all PAMTs which overlap with this TDMR, put all the overlapping parts to reserved areas too. Signed-off-by: Kai Huang Reviewed-by: Isaku Yamahata Reviewed-by: Kirill A. Shutemov Reviewed-by: Yuan Yao --- v13 -> v14: - No change v12 -> v13: - Added Yuan's tag. v11 -> v12: - Code change due to tdmr_get_pamt() change from returning pfn/npages to base/size - Added Kirill's tag v10 -> v11: - No update v9 -> v10: - No change. v8 -> v9: - Added comment around 'tdmr_add_rsvd_area()' to point out it doesn't do optimization to save reserved areas. (Dave). v7 -> v8: (Dave) - "set_up" -> "populate" in function name change (Dave). - Improved comment suggested by Dave. - Other changes due to 'struct tdmr_info_list'. --- arch/x86/virt/vmx/tdx/tdx.c | 217 ++++++++++++++++++++++++++++++++++-- 1 file changed, 209 insertions(+), 8 deletions(-) diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 54ce2c1df2f1..d1c6f8ce4e16 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include @@ -648,6 +649,207 @@ static unsigned long tdmrs_count_pamt_kb(struct tdmr_info_list *tdmr_list) return pamt_size / 1024; } +static int tdmr_add_rsvd_area(struct tdmr_info *tdmr, int *p_idx, u64 addr, + u64 size, u16 max_reserved_per_tdmr) +{ + struct tdmr_reserved_area *rsvd_areas = tdmr->reserved_areas; + int idx = *p_idx; + + /* Reserved area must be 4K aligned in offset and size */ + if (WARN_ON(addr & ~PAGE_MASK || size & ~PAGE_MASK)) + return -EINVAL; + + if (idx >= max_reserved_per_tdmr) { + pr_warn("initialization failed: TDMR [0x%llx, 0x%llx): reserved areas exhausted.\n", + tdmr->base, tdmr_end(tdmr)); + return -ENOSPC; + } + + /* + * Consume one reserved area per call. Make no effort to + * optimize or reduce the number of reserved areas which are + * consumed by contiguous reserved areas, for instance. + */ + rsvd_areas[idx].offset = addr - tdmr->base; + rsvd_areas[idx].size = size; + + *p_idx = idx + 1; + + return 0; +} + +/* + * Go through @tmb_list to find holes between memory areas. If any of + * those holes fall within @tdmr, set up a TDMR reserved area to cover + * the hole. + */ +static int tdmr_populate_rsvd_holes(struct list_head *tmb_list, + struct tdmr_info *tdmr, + int *rsvd_idx, + u16 max_reserved_per_tdmr) +{ + struct tdx_memblock *tmb; + u64 prev_end; + int ret; + + /* + * Start looking for reserved blocks at the + * beginning of the TDMR. + */ + prev_end = tdmr->base; + list_for_each_entry(tmb, tmb_list, list) { + u64 start, end; + + start = PFN_PHYS(tmb->start_pfn); + end = PFN_PHYS(tmb->end_pfn); + + /* Break if this region is after the TDMR */ + if (start >= tdmr_end(tdmr)) + break; + + /* Exclude regions before this TDMR */ + if (end < tdmr->base) + continue; + + /* + * Skip over memory areas that + * have already been dealt with. + */ + if (start <= prev_end) { + prev_end = end; + continue; + } + + /* Add the hole before this region */ + ret = tdmr_add_rsvd_area(tdmr, rsvd_idx, prev_end, + start - prev_end, + max_reserved_per_tdmr); + if (ret) + return ret; + + prev_end = end; + } + + /* Add the hole after the last region if it exists. */ + if (prev_end < tdmr_end(tdmr)) { + ret = tdmr_add_rsvd_area(tdmr, rsvd_idx, prev_end, + tdmr_end(tdmr) - prev_end, + max_reserved_per_tdmr); + if (ret) + return ret; + } + + return 0; +} + +/* + * Go through @tdmr_list to find all PAMTs. If any of those PAMTs + * overlaps with @tdmr, set up a TDMR reserved area to cover the + * overlapping part. + */ +static int tdmr_populate_rsvd_pamts(struct tdmr_info_list *tdmr_list, + struct tdmr_info *tdmr, + int *rsvd_idx, + u16 max_reserved_per_tdmr) +{ + int i, ret; + + for (i = 0; i < tdmr_list->nr_consumed_tdmrs; i++) { + struct tdmr_info *tmp = tdmr_entry(tdmr_list, i); + unsigned long pamt_base, pamt_size, pamt_end; + + tdmr_get_pamt(tmp, &pamt_base, &pamt_size); + /* Each TDMR must already have PAMT allocated */ + WARN_ON_ONCE(!pamt_size || !pamt_base); + + pamt_end = pamt_base + pamt_size; + /* Skip PAMTs outside of the given TDMR */ + if ((pamt_end <= tdmr->base) || + (pamt_base >= tdmr_end(tdmr))) + continue; + + /* Only mark the part within the TDMR as reserved */ + if (pamt_base < tdmr->base) + pamt_base = tdmr->base; + if (pamt_end > tdmr_end(tdmr)) + pamt_end = tdmr_end(tdmr); + + ret = tdmr_add_rsvd_area(tdmr, rsvd_idx, pamt_base, + pamt_end - pamt_base, + max_reserved_per_tdmr); + if (ret) + return ret; + } + + return 0; +} + +/* Compare function called by sort() for TDMR reserved areas */ +static int rsvd_area_cmp_func(const void *a, const void *b) +{ + struct tdmr_reserved_area *r1 = (struct tdmr_reserved_area *)a; + struct tdmr_reserved_area *r2 = (struct tdmr_reserved_area *)b; + + if (r1->offset + r1->size <= r2->offset) + return -1; + if (r1->offset >= r2->offset + r2->size) + return 1; + + /* Reserved areas cannot overlap. The caller must guarantee. */ + WARN_ON_ONCE(1); + return -1; +} + +/* + * Populate reserved areas for the given @tdmr, including memory holes + * (via @tmb_list) and PAMTs (via @tdmr_list). + */ +static int tdmr_populate_rsvd_areas(struct tdmr_info *tdmr, + struct list_head *tmb_list, + struct tdmr_info_list *tdmr_list, + u16 max_reserved_per_tdmr) +{ + int ret, rsvd_idx = 0; + + ret = tdmr_populate_rsvd_holes(tmb_list, tdmr, &rsvd_idx, + max_reserved_per_tdmr); + if (ret) + return ret; + + ret = tdmr_populate_rsvd_pamts(tdmr_list, tdmr, &rsvd_idx, + max_reserved_per_tdmr); + if (ret) + return ret; + + /* TDX requires reserved areas listed in address ascending order */ + sort(tdmr->reserved_areas, rsvd_idx, sizeof(struct tdmr_reserved_area), + rsvd_area_cmp_func, NULL); + + return 0; +} + +/* + * Populate reserved areas for all TDMRs in @tdmr_list, including memory + * holes (via @tmb_list) and PAMTs. + */ +static int tdmrs_populate_rsvd_areas_all(struct tdmr_info_list *tdmr_list, + struct list_head *tmb_list, + u16 max_reserved_per_tdmr) +{ + int i; + + for (i = 0; i < tdmr_list->nr_consumed_tdmrs; i++) { + int ret; + + ret = tdmr_populate_rsvd_areas(tdmr_entry(tdmr_list, i), + tmb_list, tdmr_list, max_reserved_per_tdmr); + if (ret) + return ret; + } + + return 0; +} + /* * Construct a list of TDMRs on the preallocated space in @tdmr_list * to cover all TDX memory regions in @tmb_list based on the TDX module @@ -667,14 +869,13 @@ static int construct_tdmrs(struct list_head *tmb_list, sysinfo->pamt_entry_size); if (ret) return ret; - /* - * TODO: - * - * - Designate reserved areas for each TDMR. - * - * Return -EINVAL until constructing TDMRs is done - */ - return -EINVAL; + + ret = tdmrs_populate_rsvd_areas_all(tdmr_list, tmb_list, + sysinfo->max_reserved_per_tdmr); + if (ret) + tdmrs_free_pamt_all(tdmr_list); + + return ret; } static int init_tdx_module(void) From patchwork Tue Oct 17 10:14:38 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154041 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4031171vqb; Tue, 17 Oct 2023 03:18:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFPHj1K//35vsEGY/69wsQzB0EKdaOurr4pFQldtDoYYliuTDhEngtOeuZD7UPF7l1rvkY2 X-Received: by 2002:a05:6a00:180f:b0:68f:c8b3:3077 with SMTP id y15-20020a056a00180f00b0068fc8b33077mr1786682pfa.1.1697537909480; Tue, 17 Oct 2023 03:18:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537909; cv=none; d=google.com; s=arc-20160816; b=qDlKeAUHq8/TGzYQhsLolY8LqoBExoBLH0zjSFv8Gngkqws793MaM0eX5a+EOm6suB bb+NrfQAMp1frlu+k3NapWSM9+z4Ue9Ue7DvRYuEeE3gcoHPa1KcsTD3bZre0I3FVDdU A0bpbQSfeMRenRexM6GQUXrvckqsAnVITzkQIWhOmO8VG4tkJywEyLTycJDJqtcAfS2c S1zfLuU20ZHJSNQ8o9OI305vdtUXwTCTZ98HjVZBetJ49Y5JztkeRoNVOsicDHZn96Ln P9fp7Eo92qfYGYwMBEtWXgqUlV7QBNptO1Bn+PpiUgJUK+p+SBTyQZ86nqJEfhLHBnxc PFEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=mySY3BWjNFSFBhsfFiQ2vj/bYGOq3C9Dbt/nxh301Fs=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=WtN4RSrRDD5LXMOe167qSCJKXUesd49TqGBcTyC6+LmOavyMC5YDCCGkIEzQc1owuz JCoDC/vzAvjB/HhNLoCBhaFq71BJ2ep/zXLEMejbjxYBcCMhUle/BXLwNR8m4mPkM+Nz LtLSf8jCLXarHXhWQXt1NtAvPOiV38L7Tqae6EbjHnrgFwAVWKiZiFgDFq6WzmJjQZlU H4245NGg52lxQjUjtcrO3KqDlfJ61f6gB+SxWJAsl6XVwh7guiAsC/YfZWW4OxpBoPCT CU9dkgkxJMSx2QbvRntxSvBt80qiuiRP5k5Sdi9J/WHZfkwZYo6q1lHwKaiDCFnB3pyw sgBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YSX8cb9N; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id l125-20020a633e83000000b005ac958aa98esi1474950pga.797.2023.10.17.03.18.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:18:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=YSX8cb9N; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 42B86802F685; Tue, 17 Oct 2023 03:18:24 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343840AbjJQKRt (ORCPT + 19 others); Tue, 17 Oct 2023 06:17:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235047AbjJQKR0 (ORCPT ); Tue, 17 Oct 2023 06:17:26 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 02B2F19A2; Tue, 17 Oct 2023 03:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537790; x=1729073790; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=VgX9sPSJs1p1hYJxhznYVCny+0lfqZGWlm7qyMbXIcc=; b=YSX8cb9NKk4e1aQU5kKU76wZET6bBTHo68XysD7jYZl49dniukPAzqAF 9RS8HLXw9/4Dk6ZafOvpC15YPCHGzZL9GjudWtmemab3h8ApuG6SDg901 DlyoNXarhfhRkvl79UtqlYdLcX78du8hA3e4NG2ZPC64aXzzXsRrRtuGH CqywwdgBmuqtwtMC03J9rPtVcy1AAH/DCQ2YXQ6DORF55Fz4SoOaawUNZ TdFG7mMuMu1sQYs7CHJdu6Bi3ssj7nW4Yag8aAHMVlOPi9N+v+mqeeP8n UL9PN1KSfF8oyH6SKWHLld1h/8W38JDAbGBxR2skfE+V7hcKWTnhmOrBU g==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="471972462" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="471972462" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503739" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503739" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:23 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 14/23] x86/virt/tdx: Configure TDX module with the TDMRs and global KeyID Date: Tue, 17 Oct 2023 23:14:38 +1300 Message-ID: <7b8293d905fbcd5fa939897f38b4aae1f8d397f8.1697532085.git.kai.huang@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:18:24 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997511101883611 X-GMAIL-MSGID: 1779997511101883611 The TDX module uses a private KeyID as the "global KeyID" for mapping things like the PAMT and other TDX metadata. This KeyID has already been reserved when detecting TDX during the kernel early boot. After the list of "TD Memory Regions" (TDMRs) has been constructed to cover all TDX-usable memory regions, the next step is to pass them to the TDX module together with the global KeyID. Signed-off-by: Kai Huang Reviewed-by: Isaku Yamahata Reviewed-by: Kirill A. Shutemov Reviewed-by: Yuan Yao --- v13 -> v14: - No change v12 -> v13: - Added Yuan's tag. v11 -> v12: - Added Kirill's tag v10 -> v11: - No update v9 -> v10: - Code change due to change static 'tdx_tdmr_list' to local 'tdmr_list'. v8 -> v9: - Improved changlog to explain why initializing TDMRs can take long time (Dave). - Improved comments around 'next-to-initialize' address (Dave). v7 -> v8: (Dave) - Changelog: - explicitly call out this is the last step of TDX module initialization. - Trimed down changelog by removing SEAMCALL name and details. - Removed/trimmed down unnecessary comments. - Other changes due to 'struct tdmr_info_list'. v6 -> v7: - Removed need_resched() check. -- Andi. --- arch/x86/virt/vmx/tdx/tdx.c | 43 ++++++++++++++++++++++++++++++++++++- arch/x86/virt/vmx/tdx/tdx.h | 2 ++ 2 files changed, 44 insertions(+), 1 deletion(-) diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index d1c6f8ce4e16..764f3f7a5ca2 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include @@ -878,6 +879,41 @@ static int construct_tdmrs(struct list_head *tmb_list, return ret; } +static int config_tdx_module(struct tdmr_info_list *tdmr_list, u64 global_keyid) +{ + struct tdx_module_args args = {}; + u64 *tdmr_pa_array; + size_t array_sz; + int i, ret; + + /* + * TDMRs are passed to the TDX module via an array of physical + * addresses of each TDMR. The array itself also has certain + * alignment requirement. + */ + array_sz = tdmr_list->nr_consumed_tdmrs * sizeof(u64); + array_sz = roundup_pow_of_two(array_sz); + if (array_sz < TDMR_INFO_PA_ARRAY_ALIGNMENT) + array_sz = TDMR_INFO_PA_ARRAY_ALIGNMENT; + + tdmr_pa_array = kzalloc(array_sz, GFP_KERNEL); + if (!tdmr_pa_array) + return -ENOMEM; + + for (i = 0; i < tdmr_list->nr_consumed_tdmrs; i++) + tdmr_pa_array[i] = __pa(tdmr_entry(tdmr_list, i)); + + args.rcx = __pa(tdmr_pa_array); + args.rdx = tdmr_list->nr_consumed_tdmrs; + args.r8 = global_keyid; + ret = seamcall_prerr(TDH_SYS_CONFIG, &args); + + /* Free the array as it is not required anymore. */ + kfree(tdmr_pa_array); + + return ret; +} + static int init_tdx_module(void) { struct tdsysinfo_struct *tdsysinfo; @@ -933,16 +969,21 @@ static int init_tdx_module(void) if (ret) goto out_free_tdmrs; + /* Pass the TDMRs and the global KeyID to the TDX module */ + ret = config_tdx_module(&tdmr_list, tdx_global_keyid); + if (ret) + goto out_free_pamts; + /* * TODO: * - * - Configure the TDMRs and the global KeyID to the TDX module. * - Configure the global KeyID on all packages. * - Initialize all TDMRs. * * Return error before all steps are done. */ ret = -EINVAL; +out_free_pamts: if (ret) tdmrs_free_pamt_all(&tdmr_list); else diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h index 6987af46d096..b8c9e3d016f9 100644 --- a/arch/x86/virt/vmx/tdx/tdx.h +++ b/arch/x86/virt/vmx/tdx/tdx.h @@ -19,6 +19,7 @@ #define TDH_SYS_INFO 32 #define TDH_SYS_INIT 33 #define TDH_SYS_LP_INIT 35 +#define TDH_SYS_CONFIG 45 struct cmr_info { u64 base; @@ -85,6 +86,7 @@ struct tdmr_reserved_area { } __packed; #define TDMR_INFO_ALIGNMENT 512 +#define TDMR_INFO_PA_ARRAY_ALIGNMENT 512 struct tdmr_info { u64 base; From patchwork Tue Oct 17 10:14:39 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154045 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4031452vqb; Tue, 17 Oct 2023 03:19:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFqzQ5CfVFvL2Yqhx+QvM64M3d5+Qxpuhbr+WfKn8mO7UiSQH5c9LzM9H69ZHZBHi8yKTTY X-Received: by 2002:a05:6870:1f0d:b0:1e9:e605:27a1 with SMTP id pd13-20020a0568701f0d00b001e9e60527a1mr1708236oab.2.1697537952529; Tue, 17 Oct 2023 03:19:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537952; cv=none; d=google.com; s=arc-20160816; b=L2luMRYjNS8F+PPwZnAhER8TddCIhxWir+Pfx0JJx/qo3IrGEBonSHBLmMEmeAMZXK Dt1NfYWIB8pDMx9ItXLHuL+rDbJeQORSTeIP7DgE1LyXAZxNgq0xnYpGYH2ooOyZFzWw ULjRwv7x7bBecQu8diaNexhK0bsXwQ2CDaqWBfLKyr8tN8MfV0zRkC5wM8EZG3CbkkLG AeCSfuQFyn18vv+OK07FqHmAsY9a/Icl/Oq9aOVPXHrdulT24kLanco810/SJjCadje2 GoANoBsvPDQiIHFPSRuogFdXkm5KViqF0HABo7yig09smcReBm+HoPti4PG4V1azddTQ Zt6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=m+Enc6AHJzTxlu+f1ncu7Hcj5dQixEVxo6Bp98/sqHU=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=DwSouyD2HVX40jB+MJMTdiq8MOqNKfyZjOClYsqaPJNE8S6LHJFUJMTdI074SVaS9N 0ZjrV7bDyBqAd2NP5sLfSm9BurM/7IdQ6oV86tqCMbah7n7thHGDL1AB+0l0guT5xvwb jsk5GkaNy/9gUYx7fKtaf+Enh4GIhD3sAEiQKb4XgaJCo2VMjK5o21aMqaSen17Cdjgv OSNB3G8nPC7QqROX/eY8n4nJzOu+MSQHx40DntMX00IU1ixqAetCXTIy462/T4KAAaUs tYbUU3+H9UDOXWSZnx034zl0XLWCDgaHRCAdfLQHKB+XyZ/ySEhUPnY+Hf4NgaS7FmtW Jdyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=FyHPYTPX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id e4-20020a637444000000b005859c3a51c0si1411306pgn.421.2023.10.17.03.19.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:19:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=FyHPYTPX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id C4156802F69C; Tue, 17 Oct 2023 03:18:59 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343722AbjJQKSB (ORCPT + 19 others); Tue, 17 Oct 2023 06:18:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51790 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343714AbjJQKRa (ORCPT ); Tue, 17 Oct 2023 06:17:30 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 472BB101; Tue, 17 Oct 2023 03:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537796; x=1729073796; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=d/a72HrfUa37kYK9QizF9pAYWTuXecYhyO/r32yRY50=; b=FyHPYTPXUA7G0RA3Uj/+nAI+XCNGI2PSJtmiQ1HYJe0TCoY1bcz2O/hG F51rnQkTF1RxwWsjapbHB0RnZW6c9u8Df9glsVDTAjqV5fif6py1Y+H+1 VST/7XvvjdvFAdXY3qdUC/wzRf0SM+dMJexnaQewy0KboOkg3mcpx3KwG T/n5pO+xi119nrWOTGw6iKjU65Q12PNhbWPd4OWe9jY8fwvbwofaINFok FWuN7eGFxA+Ac+KVJLV4ld1NEsgkIb+4aMJNUnZCSM4anarjMyp4Tk8jM rLgCUFjsNECbV6JhvZsFc48jwxa1DDG6Cz2XKXB3gaxNOviUGWpGuiFpT g==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="471972485" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="471972485" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503763" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503763" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:29 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 15/23] x86/virt/tdx: Configure global KeyID on all packages Date: Tue, 17 Oct 2023 23:14:39 +1300 Message-ID: X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:18:59 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997555942363864 X-GMAIL-MSGID: 1779997555942363864 After the list of TDMRs and the global KeyID are configured to the TDX module, the kernel needs to configure the key of the global KeyID on all packages using TDH.SYS.KEY.CONFIG. This SEAMCALL cannot run parallel on different cpus. Loop all online cpus and use smp_call_on_cpu() to call this SEAMCALL on the first cpu of each package. To keep things simple, this implementation takes no affirmative steps to online cpus to make sure there's at least one cpu for each package. The callers (aka. KVM) can ensure success by ensuring sufficient CPUs are online for this to succeed. Intel hardware doesn't guarantee cache coherency across different KeyIDs. The PAMTs are transitioning from being used by the kernel mapping (KeyId 0) to the TDX module's "global KeyID" mapping. This means that the kernel must flush any dirty KeyID-0 PAMT cachelines before the TDX module uses the global KeyID to access the PAMTs. Otherwise, if those dirty cachelines were written back, they would corrupt the TDX module's metadata. Aside: This corruption would be detected by the memory integrity hardware on the next read of the memory with the global KeyID. The result would likely be fatal to the system but would not impact TDX security. Following the TDX module specification, flush cache before configuring the global KeyID on all packages. Given the PAMT size can be large (~1/256th of system RAM), just use WBINVD on all CPUs to flush. If TDH.SYS.KEY.CONFIG fails, the TDX module may already have used the global KeyID to write the PAMTs. Therefore, use WBINVD to flush cache before returning the PAMTs back to the kernel. Also convert all PAMTs back to normal by using MOVDIR64B as suggested by the TDX module spec, although on the platform without the "partial write machine check" erratum it's OK to leave PAMTs as is. Signed-off-by: Kai Huang Reviewed-by: Isaku Yamahata Reviewed-by: Kirill A. Shutemov Reviewed-by: Yuan Yao --- v13 -> v14: - No change v12 -> v13: - Added Yuan's tag. v11 -> v12: - Added Kirill's tag - Improved changelog (Nikolay) v10 -> v11: - Convert PAMTs back to normal when module initialization fails. - Fixed an error in changelog v9 -> v10: - Changed to use 'smp_call_on_cpu()' directly to do key configuration. v8 -> v9: - Improved changelog (Dave). - Improved comments to explain the function to configure global KeyID "takes no affirmative action to online any cpu". (Dave). - Improved other comments suggested by Dave. v7 -> v8: (Dave) - Changelog changes: - Point out this is the step of "multi-steps" of init_tdx_module(). - Removed MOVDIR64B part. - Other changes due to removing TDH.SYS.SHUTDOWN and TDH.SYS.LP.INIT. - Changed to loop over online cpus and use smp_call_function_single() directly as the patch to shut down TDX module has been removed. - Removed MOVDIR64B part in comment. --- arch/x86/virt/vmx/tdx/tdx.c | 130 +++++++++++++++++++++++++++++++++++- arch/x86/virt/vmx/tdx/tdx.h | 1 + 2 files changed, 129 insertions(+), 2 deletions(-) diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 764f3f7a5ca2..fc816709ff55 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include "tdx.h" @@ -591,7 +592,8 @@ static void tdmr_get_pamt(struct tdmr_info *tdmr, unsigned long *pamt_base, *pamt_size = pamt_sz; } -static void tdmr_free_pamt(struct tdmr_info *tdmr) +static void tdmr_do_pamt_func(struct tdmr_info *tdmr, + void (*pamt_func)(unsigned long base, unsigned long size)) { unsigned long pamt_base, pamt_size; @@ -604,9 +606,19 @@ static void tdmr_free_pamt(struct tdmr_info *tdmr) if (WARN_ON_ONCE(!pamt_base)) return; + (*pamt_func)(pamt_base, pamt_size); +} + +static void free_pamt(unsigned long pamt_base, unsigned long pamt_size) +{ free_contig_range(pamt_base >> PAGE_SHIFT, pamt_size >> PAGE_SHIFT); } +static void tdmr_free_pamt(struct tdmr_info *tdmr) +{ + tdmr_do_pamt_func(tdmr, free_pamt); +} + static void tdmrs_free_pamt_all(struct tdmr_info_list *tdmr_list) { int i; @@ -635,6 +647,41 @@ static int tdmrs_set_up_pamt_all(struct tdmr_info_list *tdmr_list, return ret; } +/* + * Convert TDX private pages back to normal by using MOVDIR64B to + * clear these pages. Note this function doesn't flush cache of + * these TDX private pages. The caller should make sure of that. + */ +static void reset_tdx_pages(unsigned long base, unsigned long size) +{ + const void *zero_page = (const void *)page_address(ZERO_PAGE(0)); + unsigned long phys, end; + + end = base + size; + for (phys = base; phys < end; phys += 64) + movdir64b(__va(phys), zero_page); + + /* + * MOVDIR64B uses WC protocol. Use memory barrier to + * make sure any later user of these pages sees the + * updated data. + */ + mb(); +} + +static void tdmr_reset_pamt(struct tdmr_info *tdmr) +{ + tdmr_do_pamt_func(tdmr, reset_tdx_pages); +} + +static void tdmrs_reset_pamt_all(struct tdmr_info_list *tdmr_list) +{ + int i; + + for (i = 0; i < tdmr_list->nr_consumed_tdmrs; i++) + tdmr_reset_pamt(tdmr_entry(tdmr_list, i)); +} + static unsigned long tdmrs_count_pamt_kb(struct tdmr_info_list *tdmr_list) { unsigned long pamt_size = 0; @@ -914,6 +961,50 @@ static int config_tdx_module(struct tdmr_info_list *tdmr_list, u64 global_keyid) return ret; } +static int do_global_key_config(void *data) +{ + struct tdx_module_args args = {}; + + return seamcall_prerr(TDH_SYS_KEY_CONFIG, &args); +} + +/* + * Attempt to configure the global KeyID on all physical packages. + * + * This requires running code on at least one CPU in each package. If a + * package has no online CPUs, that code will not run and TDX module + * initialization (TDMR initialization) will fail. + * + * This code takes no affirmative steps to online CPUs. Callers (aka. + * KVM) can ensure success by ensuring sufficient CPUs are online for + * this to succeed. + */ +static int config_global_keyid(void) +{ + cpumask_var_t packages; + int cpu, ret = -EINVAL; + + if (!zalloc_cpumask_var(&packages, GFP_KERNEL)) + return -ENOMEM; + + for_each_online_cpu(cpu) { + if (cpumask_test_and_set_cpu(topology_physical_package_id(cpu), + packages)) + continue; + + /* + * TDH.SYS.KEY.CONFIG cannot run concurrently on + * different cpus, so just do it one by one. + */ + ret = smp_call_on_cpu(cpu, do_global_key_config, NULL, true); + if (ret) + break; + } + + free_cpumask_var(packages); + return ret; +} + static int init_tdx_module(void) { struct tdsysinfo_struct *tdsysinfo; @@ -974,15 +1065,47 @@ static int init_tdx_module(void) if (ret) goto out_free_pamts; + /* + * Hardware doesn't guarantee cache coherency across different + * KeyIDs. The kernel needs to flush PAMT's dirty cachelines + * (associated with KeyID 0) before the TDX module can use the + * global KeyID to access the PAMT. Given PAMTs are potentially + * large (~1/256th of system RAM), just use WBINVD on all cpus + * to flush the cache. + */ + wbinvd_on_all_cpus(); + + /* Config the key of global KeyID on all packages */ + ret = config_global_keyid(); + if (ret) + goto out_reset_pamts; + /* * TODO: * - * - Configure the global KeyID on all packages. * - Initialize all TDMRs. * * Return error before all steps are done. */ ret = -EINVAL; +out_reset_pamts: + if (ret) { + /* + * Part of PAMTs may already have been initialized by the + * TDX module. Flush cache before returning PAMTs back + * to the kernel. + */ + wbinvd_on_all_cpus(); + /* + * According to the TDX hardware spec, if the platform + * doesn't have the "partial write machine check" + * erratum, any kernel read/write will never cause #MC + * in kernel space, thus it's OK to not convert PAMTs + * back to normal. But do the conversion anyway here + * as suggested by the TDX spec. + */ + tdmrs_reset_pamt_all(&tdmr_list); + } out_free_pamts: if (ret) tdmrs_free_pamt_all(&tdmr_list); @@ -1038,6 +1161,9 @@ static int __tdx_enable(void) * lock to prevent any new cpu from becoming online; 2) done both VMXON * and tdx_cpu_enable() on all online cpus. * + * This function requires there's at least one online cpu for each CPU + * package to succeed. + * * This function can be called in parallel by multiple callers. * * Return 0 if TDX is enabled successfully, otherwise error. diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h index b8c9e3d016f9..2427ae40fc3c 100644 --- a/arch/x86/virt/vmx/tdx/tdx.h +++ b/arch/x86/virt/vmx/tdx/tdx.h @@ -16,6 +16,7 @@ /* * TDX module SEAMCALL leaf functions */ +#define TDH_SYS_KEY_CONFIG 31 #define TDH_SYS_INFO 32 #define TDH_SYS_INIT 33 #define TDH_SYS_LP_INIT 35 From patchwork Tue Oct 17 10:14:40 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154042 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4031284vqb; Tue, 17 Oct 2023 03:18:49 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGlxKkXsgWF7WSy0taoGvOQj1VWwpC+12T4bxZIY66JlegyMsilUdjzcR2QEXHKQHb6c3gU X-Received: by 2002:a05:6359:2c43:b0:166:d9b7:2ba5 with SMTP id qv3-20020a0563592c4300b00166d9b72ba5mr1527353rwb.2.1697537929439; Tue, 17 Oct 2023 03:18:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537929; cv=none; d=google.com; s=arc-20160816; b=bQQUXrkTDaYLePODPuKYJ1yhgPdv3QZqinE1a8HHTyfnVQ+e4pYcOw1e9g2yt8z1Yu MQL0EfeeGUac7cado3YhdQRiLE3PzOAF4RFUIOT5qIe2/5rem/5lKyBSDlxj1JoiNDuy 5JkVllUsswxX48VCVqkpO04CImcq2JPiGXK1LsRJ5/wsEIDoZmr3yh5Q+wcyv665Zd7c Fz1a5NBoT15tKkQ+D8nTzR1gCnf4V+dtLVsSDLThQSAonnoMmFGxvveEExqH7oMgwUOH StMOmjR29M4r8xdRGjTzE3wXnZl9e0N7yBepUyIae6OarHrB5xsT90jZpbTItJjNKbtx gu6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Ot3rKx/myW/gCVrPOFroU0f9+xzHUMUVqNg3JymofmY=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=Ob4/JhqM4OPEGLtK4NSa6aOZTJ0bMJiGTHmxX0W7L482T3fasYDXf6r3DvirJy2pk1 gRBq39YsJzAfxSXP/0lUlJ+wr9ZZggL5B4dZKGEeOZkmyeqdx/rKFQ03IajuJDmAHEY6 rwWvQEENy6Ofc9wmSz2/jfekW1sxlhNGHUNZkg25LxXm6Glu2IjoDR5Z1exUkCFY94G6 KC698rbeFyZSfqmg4F/Ut/7VsrgkFrwW8clWT1cC+34GjEy01CjIFNt2TPD3OKgAPy6a cfyLGGEbqvgoIj0ZcygF7sEol5LccPkhG1VE/1318KWevvMOPdMF0fxcJGBBumBi9WDo sG+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=CksM9hQe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id d19-20020a056a00199300b006a15afe16adsi1361106pfl.258.2023.10.17.03.18.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:18:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=CksM9hQe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 4EFE68036854; Tue, 17 Oct 2023 03:18:44 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343736AbjJQKSF (ORCPT + 19 others); Tue, 17 Oct 2023 06:18:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32844 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234953AbjJQKRh (ORCPT ); Tue, 17 Oct 2023 06:17:37 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6252018B; Tue, 17 Oct 2023 03:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537802; x=1729073802; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=GhpQPcS/CMbLQAkfvW4SzXqPwTDy2676TD+2Uq3ONjE=; b=CksM9hQe3IJhIDykDyO/au/pt/nAG/JER5NvgLptO5hA5im7aCEtT9S5 c2w5ZwG1mJq6KBzg10ubSH81W6mgJ83C+qyOey1yliyioamWQmrsPObiT 0Dwztog/4TrvggqbNBjXiLVyGK8OdZNGLYOuJbpWiafNkP3oee5qkUldw 9Y7O7ze5J910xXEQshAoVFer/aPykMlzY0uvHbMNaMqF2TjiH6tUtbvGv 8uC4y7AmfJL05qik4CVQDWxi6dUzj5KAow8ZZCwfaiV+zeNWZMQDPg2ni mV1xeHLjIgT9QLXrDbvipgy6pXf+c2gcFw96yk8w2zdmlaeD1GicCAb5+ g==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="471972507" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="471972507" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503796" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503796" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:36 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 16/23] x86/virt/tdx: Initialize all TDMRs Date: Tue, 17 Oct 2023 23:14:40 +1300 Message-ID: <940fc8df2a1563ca94c0c4212fae997efd540444.1697532085.git.kai.huang@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:18:44 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997532005754429 X-GMAIL-MSGID: 1779997532005754429 After the global KeyID has been configured on all packages, initialize all TDMRs to make all TDX-usable memory regions that are passed to the TDX module become usable. This is the last step of initializing the TDX module. Initializing TDMRs can be time consuming on large memory systems as it involves initializing all metadata entries for all pages that can be used by TDX guests. Initializing different TDMRs can be parallelized. For now to keep it simple, just initialize all TDMRs one by one. It can be enhanced in the future. Signed-off-by: Kai Huang Reviewed-by: Isaku Yamahata Reviewed-by: Kirill A. Shutemov Reviewed-by: Yuan Yao --- v13 -> v14: - No change v12 -> v13: - Added Yuan's tag. v11 -> v12: - Added Kirill's tag v10 -> v11: - No update v9 -> v10: - Code change due to change static 'tdx_tdmr_list' to local 'tdmr_list'. v8 -> v9: - Improved changlog to explain why initializing TDMRs can take long time (Dave). - Improved comments around 'next-to-initialize' address (Dave). v7 -> v8: (Dave) - Changelog: - explicitly call out this is the last step of TDX module initialization. - Trimed down changelog by removing SEAMCALL name and details. - Removed/trimmed down unnecessary comments. - Other changes due to 'struct tdmr_info_list'. v6 -> v7: - Removed need_resched() check. -- Andi. --- arch/x86/virt/vmx/tdx/tdx.c | 60 ++++++++++++++++++++++++++++++++----- arch/x86/virt/vmx/tdx/tdx.h | 1 + 2 files changed, 53 insertions(+), 8 deletions(-) diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index fc816709ff55..4f55da1853a9 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -1005,6 +1005,56 @@ static int config_global_keyid(void) return ret; } +static int init_tdmr(struct tdmr_info *tdmr) +{ + u64 next; + + /* + * Initializing a TDMR can be time consuming. To avoid long + * SEAMCALLs, the TDX module may only initialize a part of the + * TDMR in each call. + */ + do { + struct tdx_module_args args = { + .rcx = tdmr->base, + }; + int ret; + + ret = seamcall_prerr_ret(TDH_SYS_TDMR_INIT, &args); + if (ret) + return ret; + /* + * RDX contains 'next-to-initialize' address if + * TDH.SYS.TDMR.INIT did not fully complete and + * should be retried. + */ + next = args.rdx; + cond_resched(); + /* Keep making SEAMCALLs until the TDMR is done */ + } while (next < tdmr->base + tdmr->size); + + return 0; +} + +static int init_tdmrs(struct tdmr_info_list *tdmr_list) +{ + int i; + + /* + * This operation is costly. It can be parallelized, + * but keep it simple for now. + */ + for (i = 0; i < tdmr_list->nr_consumed_tdmrs; i++) { + int ret; + + ret = init_tdmr(tdmr_entry(tdmr_list, i)); + if (ret) + return ret; + } + + return 0; +} + static int init_tdx_module(void) { struct tdsysinfo_struct *tdsysinfo; @@ -1080,14 +1130,8 @@ static int init_tdx_module(void) if (ret) goto out_reset_pamts; - /* - * TODO: - * - * - Initialize all TDMRs. - * - * Return error before all steps are done. - */ - ret = -EINVAL; + /* Initialize TDMRs to complete the TDX module initialization */ + ret = init_tdmrs(&tdmr_list); out_reset_pamts: if (ret) { /* diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h index 2427ae40fc3c..6e41b0731e48 100644 --- a/arch/x86/virt/vmx/tdx/tdx.h +++ b/arch/x86/virt/vmx/tdx/tdx.h @@ -20,6 +20,7 @@ #define TDH_SYS_INFO 32 #define TDH_SYS_INIT 33 #define TDH_SYS_LP_INIT 35 +#define TDH_SYS_TDMR_INIT 36 #define TDH_SYS_CONFIG 45 struct cmr_info { From patchwork Tue Oct 17 10:14:41 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154043 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4031316vqb; Tue, 17 Oct 2023 03:18:55 -0700 (PDT) X-Google-Smtp-Source: AGHT+IENldCqPJ1Sqjl2gDQPHGiv6U0SJoZ5Mji8GHD2etAS+HKAef0oMhWrnC/Tm2chcZpmUzXD X-Received: by 2002:a05:6a20:9741:b0:163:ab09:196d with SMTP id hs1-20020a056a20974100b00163ab09196dmr1626724pzc.1.1697537934937; Tue, 17 Oct 2023 03:18:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537934; cv=none; d=google.com; s=arc-20160816; b=VzWXYAvAYNmbvj+d9vGF9mYlN9VA2zvqzuyZzSrWPlUW4K2SQRfyTHXr3FCaUjOyM2 oWCe2oR6/g5kylSXB11FbucCwdUTI0nUatFV//+2rdYrMmE78MIaBDa0pDePqiH3Oyse OBhGUSXheaTHZbnl59nJpWNQyKT03CQB/dqdWqD41wpFGj/Mqdu8cvTh7/VbySZnUBNN YWIyML9+vNmdknywKuH59r8HXF9jzyvjzseE4y6yXIRhuhLHh1VcSISa0/TVOJujMN/Z fSnX3/NSiMuSOrV8ap5Ewtllp1tnjsleHJcDMUusxECMMV0hIDLv/qzEyQHXBEvIStPu xg6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Kxm6ktNhIt1fCIkK2rQrwM93JD/ht7OKXMQ8nDReEms=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=tz3szvD+5UsKP722u6UbOC9gSca/PhUy5A3Yo+9oclq8PL+iDsTthkJuRywZNla0/m wcSSuyoFYEJAy8SzmjPu5HuVr8H6TNHAMxh6tzvcozMy2ejquK8csFRqdVWaunwXtNcI ZJ4sITbVMbVyjf/M+o3bgK3GmKygm9ENwXB1u7YqlqlC4qEZdJOWMn220EqQbQ3lQz3V MAV2HSm49HaisXkL0nXwzi5g9qhO9YRlibnaqu9TncQDrFZ8k6/4KyQWV4KK8GQ0CNcs xitaIcFokkFbWX0RaApuQJ4voHo/UtIsL9q2kuj9rbY8F8ub6u6idJDTT10ISbVc8bFN 1zmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=S9SvJbfB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id lw14-20020a17090b180e00b0025960d035c6si1567434pjb.138.2023.10.17.03.18.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:18:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=S9SvJbfB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 25E678036853; Tue, 17 Oct 2023 03:18:50 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343664AbjJQKSO (ORCPT + 19 others); Tue, 17 Oct 2023 06:18:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343758AbjJQKRk (ORCPT ); Tue, 17 Oct 2023 06:17:40 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 68D38D71; Tue, 17 Oct 2023 03:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537808; x=1729073808; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=e3OEQmPhdi+AgT8pJCWMf8X2DtqH5+9i6q9MakSExHE=; b=S9SvJbfBHyKlevzndwoJmJJnsH2TysUbY2MH+P1pSmSbwKw8dHynAwhN ajd/R6UuQWjLIZKvLF5qJN3hH1a4jw2VBVgPTw+wEBX7iMtwpzgUUkM/A 1PZuUT+ixe+gEU1r/u4hov0c3Nt17JllNORw7CHm2+s9yolHSaM+N6aNZ wip1aJI25rpEjm5u8/cL1vcSajUsCaEBNmvNnH/DnhmvM/sCWLys9bNGU hcfbjfu2uQ1gZQqIvZDBIqnOR/b4Gb3DzuVyv18yiG6Lho80hd7m9VDCG 6vY42QwzsrvyKAts6eDXeOpzj0nTCgP/TwN0dnw1RXVzhQTvXRWL0EXiW Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="471972528" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="471972528" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503821" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503821" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:42 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 17/23] x86/kexec: Flush cache of TDX private memory Date: Tue, 17 Oct 2023 23:14:41 +1300 Message-ID: X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:18:50 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997537781330326 X-GMAIL-MSGID: 1779997537781330326 There are two problems in terms of using kexec() to boot to a new kernel when the old kernel has enabled TDX: 1) Part of the memory pages are still TDX private pages; 2) There might be dirty cachelines associated with TDX private pages. The first problem doesn't matter on the platforms w/o the "partial write machine check" erratum. KeyID 0 doesn't have integrity check. If the new kernel wants to use any non-zero KeyID, it needs to convert the memory to that KeyID and such conversion would work from any KeyID. However the old kernel needs to guarantee there's no dirty cacheline left behind before booting to the new kernel to avoid silent corruption from later cacheline writeback (Intel hardware doesn't guarantee cache coherency across different KeyIDs). There are two things that the old kernel needs to do to achieve that: 1) Stop accessing TDX private memory mappings: a. Stop making TDX module SEAMCALLs (TDX global KeyID); b. Stop TDX guests from running (per-guest TDX KeyID). 2) Flush any cachelines from previous TDX private KeyID writes. For 2), use wbinvd() to flush cache in stop_this_cpu(), following SME support. And in this way 1) happens for free as there's no TDX activity between wbinvd() and the native_halt(). Flushing cache in stop_this_cpu() only flushes cache on remote cpus. On the rebooting cpu which does kexec(), unlike SME which does the cache flush in relocate_kernel(), flush the cache right after stopping remote cpus in machine_shutdown(). There are two reasons to do so: 1) For TDX there's no need to defer cache flush to relocate_kernel() because all TDX activities have been stopped. 2) On the platforms with the above erratum the kernel must convert all TDX private pages back to normal before booting to the new kernel in kexec(), and flushing cache early allows the kernel to convert memory early rather than having to muck with the relocate_kernel() assembly. Theoretically, cache flush is only needed when the TDX module has been initialized. However initializing the TDX module is done on demand at runtime, and it takes a mutex to read the module status. Just check whether TDX is enabled by the BIOS instead to flush cache. Signed-off-by: Kai Huang Reviewed-by: Isaku Yamahata Reviewed-by: Kirill A. Shutemov --- v13 -> v14: - No change --- arch/x86/kernel/process.c | 8 +++++++- arch/x86/kernel/reboot.c | 15 +++++++++++++++ 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index 9f0909142a0a..c197be03ea06 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -830,8 +830,14 @@ void __noreturn stop_this_cpu(void *dummy) * * Test the CPUID bit directly because the machine might've cleared * X86_FEATURE_SME due to cmdline options. + * + * The TDX module or guests might have left dirty cachelines + * behind. Flush them to avoid corruption from later writeback. + * Note that this flushes on all systems where TDX is possible, + * but does not actually check that TDX was in use. */ - if (c->extended_cpuid_level >= 0x8000001f && (cpuid_eax(0x8000001f) & BIT(0))) + if ((c->extended_cpuid_level >= 0x8000001f && (cpuid_eax(0x8000001f) & BIT(0))) + || platform_tdx_enabled()) native_wbinvd(); /* diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c index 830425e6d38e..e1a4fa8de11d 100644 --- a/arch/x86/kernel/reboot.c +++ b/arch/x86/kernel/reboot.c @@ -31,6 +31,7 @@ #include #include #include +#include /* * Power off function, if any @@ -741,6 +742,20 @@ void native_machine_shutdown(void) local_irq_disable(); stop_other_cpus(); #endif + /* + * stop_other_cpus() has flushed all dirty cachelines of TDX + * private memory on remote cpus. Unlike SME, which does the + * cache flush on _this_ cpu in the relocate_kernel(), flush + * the cache for _this_ cpu here. This is because on the + * platforms with "partial write machine check" erratum the + * kernel needs to convert all TDX private pages back to normal + * before booting to the new kernel in kexec(), and the cache + * flush must be done before that. If the kernel took SME's way, + * it would have to muck with the relocate_kernel() assembly to + * do memory conversion. + */ + if (platform_tdx_enabled()) + native_wbinvd(); lapic_shutdown(); restore_boot_irq_mode(); From patchwork Tue Oct 17 10:14:42 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154048 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4031536vqb; Tue, 17 Oct 2023 03:19:25 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFL6wrw/qJMPFja4nJ517iCFK5RNLsdz+uDOXa/8LOmj//ntFA6dxgf609ddQ3gdt3nCT/e X-Received: by 2002:a17:90b:4c8b:b0:27d:2762:2728 with SMTP id my11-20020a17090b4c8b00b0027d27622728mr1877568pjb.0.1697537965273; Tue, 17 Oct 2023 03:19:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537965; cv=none; d=google.com; s=arc-20160816; b=CoxCnNh1NVQEY4xG+FFO2VPurIso0AWW1sZJjUR7pup2jo3/mpadXXolfHZopjKuZa AqXhLBEqBVxZ2oYYb8eYwAnZ/YlwWaM/ehnXA5p+wG3YZwBCgkxvPP+XJHGblxidvPBH 2Jr/OrTV+VF1ObTpnrGig23RkhbfnY122BSe11cKmPen5q5b4QEDX6xP8G9nZVQLusGR 0j4xzY32MAISFxgqSPcoiUAtwsryOTXBl1o+HGycaktLIKgHToYOjLUWAim75L4OjA6B CIn5L3fnB6yYrLmwY7fXjpCKlYjIJyUEj5C1UUIgX0ZtQ+lCSwjPMoO7/F5ax985gx/g okgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=YODLY2cz8ULGecZucqR8APBwqHu2M5S6zK5z42JTYts=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=mPjG5G/iTU51DiG8D8qnarZRZnN6pZ9o9ddp7zPIzONPGHPsKsLUoODvZpEmW0oxnn IyZmvT6ntOcY2wbOFlawiwkhK7TbvIWAaEA9BZxfY4/BAbgHFw9YPGM9gWHv7od6nBHU aIWwqxMaPabYHJbnP51MqRjXTIjlsDb9LryIo1unf4Wa7RaJBahBCmlOY+9eL9/ho+qp p3qdPBPrPmNy6xwVpnjLslRvGYUKn9iBpAIYbEFhuPfJeNg4zhOEBVuCGQBFNhHsNmHO jzlx0vNymA0+YhjzNxwGzYp2+9j7g44ICSW6JQDYJMxFzbdbI+3gy1FgiFm6OST2rpdh YbfA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=JXnfxopO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id lr14-20020a17090b4b8e00b002568a675b65si9126768pjb.141.2023.10.17.03.19.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:19:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=JXnfxopO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 2E97B8040C51; Tue, 17 Oct 2023 03:19:19 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343787AbjJQKSS (ORCPT + 19 others); Tue, 17 Oct 2023 06:18:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51530 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343774AbjJQKRl (ORCPT ); Tue, 17 Oct 2023 06:17:41 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8797410C6; Tue, 17 Oct 2023 03:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537814; x=1729073814; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=IW2joqa43yE+gdm/hHMD0E7KRPOslCtHQymG4aQhmYo=; b=JXnfxopOXaRIsK/rg+06t745tLyRUThRSXWLHxRUjme5Kwpe4YFLOOGr yrnsQUo5DLBSBrrdex0AuLnq+tq2Ht603mh/Zt8hhRn56yD7B/sjX9JTJ 4vx4Af7mQZEiQP7dumO+BpeOw+dyi77Infs1JOP0HAMaoTMzghn37g3E4 X70S1YPGYd7ZR+z8f4Rvy7KzoPgSsV4w5gBOPBLDU6KMMcYLmFNHjW9sQ r7z06ITY+MzBK/8OJB2TyZRDHAE1JMy9Os6072vpH3w2GiRxsqw000Xw2 W/sOffLoH/m8yxLBz3B2MgpAF8XlAhdln5W76SN2JAxDEM1idmojk0YtQ w==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="471972561" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="471972561" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503860" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503860" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:48 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 18/23] x86/virt/tdx: Keep TDMRs when module initialization is successful Date: Tue, 17 Oct 2023 23:14:42 +1300 Message-ID: X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:19:19 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997569265486539 X-GMAIL-MSGID: 1779997569265486539 On the platforms with the "partial write machine check" erratum, the kexec() needs to convert all TDX private pages back to normal before booting to the new kernel. Otherwise, the new kernel may get unexpected machine check. There's no existing infrastructure to track TDX private pages. Keep TDMRs when module initialization is successful so that they can be used to find PAMTs. Signed-off-by: Kai Huang Reviewed-by: Rick Edgecombe Reviewed-by: Kirill A. Shutemov --- v13 -> v14: - "Change to keep" -> "Keep" (Kirill) - Add Kirill/Rick's tags v12 -> v13: - Split "improve error handling" part out as a separate patch. v11 -> v12 (new patch): - Defer keeping TDMRs logic to this patch for better review - Improved error handling logic (Nikolay/Kirill in patch 15) --- arch/x86/virt/vmx/tdx/tdx.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 4f55da1853a9..9a02b9237612 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -46,6 +46,8 @@ static DEFINE_MUTEX(tdx_module_lock); /* All TDX-usable memory regions. Protected by mem_hotplug_lock. */ static LIST_HEAD(tdx_memlist); +static struct tdmr_info_list tdx_tdmr_list; + typedef void (*sc_err_func_t)(u64 fn, u64 err, struct tdx_module_args *args); static inline void seamcall_err(u64 fn, u64 err, struct tdx_module_args *args) @@ -1058,7 +1060,6 @@ static int init_tdmrs(struct tdmr_info_list *tdmr_list) static int init_tdx_module(void) { struct tdsysinfo_struct *tdsysinfo; - struct tdmr_info_list tdmr_list; struct cmr_info *cmr_array; int tdsysinfo_size; int cmr_array_size; @@ -1101,17 +1102,17 @@ static int init_tdx_module(void) goto out_put_tdxmem; /* Allocate enough space for constructing TDMRs */ - ret = alloc_tdmr_list(&tdmr_list, tdsysinfo); + ret = alloc_tdmr_list(&tdx_tdmr_list, tdsysinfo); if (ret) goto out_free_tdxmem; /* Cover all TDX-usable memory regions in TDMRs */ - ret = construct_tdmrs(&tdx_memlist, &tdmr_list, tdsysinfo); + ret = construct_tdmrs(&tdx_memlist, &tdx_tdmr_list, tdsysinfo); if (ret) goto out_free_tdmrs; /* Pass the TDMRs and the global KeyID to the TDX module */ - ret = config_tdx_module(&tdmr_list, tdx_global_keyid); + ret = config_tdx_module(&tdx_tdmr_list, tdx_global_keyid); if (ret) goto out_free_pamts; @@ -1131,7 +1132,7 @@ static int init_tdx_module(void) goto out_reset_pamts; /* Initialize TDMRs to complete the TDX module initialization */ - ret = init_tdmrs(&tdmr_list); + ret = init_tdmrs(&tdx_tdmr_list); out_reset_pamts: if (ret) { /* @@ -1148,20 +1149,17 @@ static int init_tdx_module(void) * back to normal. But do the conversion anyway here * as suggested by the TDX spec. */ - tdmrs_reset_pamt_all(&tdmr_list); + tdmrs_reset_pamt_all(&tdx_tdmr_list); } out_free_pamts: if (ret) - tdmrs_free_pamt_all(&tdmr_list); + tdmrs_free_pamt_all(&tdx_tdmr_list); else pr_info("%lu KBs allocated for PAMT\n", - tdmrs_count_pamt_kb(&tdmr_list)); + tdmrs_count_pamt_kb(&tdx_tdmr_list)); out_free_tdmrs: - /* - * Always free the buffer of TDMRs as they are only used during - * module initialization. - */ - free_tdmr_list(&tdmr_list); + if (ret) + free_tdmr_list(&tdx_tdmr_list); out_free_tdxmem: if (ret) free_tdx_memlist(&tdx_memlist); From patchwork Tue Oct 17 10:14:43 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154044 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4031355vqb; Tue, 17 Oct 2023 03:19:00 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHj2y8VgFSx0Q5NCq21L6nMlcG4cq5UNQxXgB7W5eKh2OHIffeAMbAlZ2Aw9xs+FJudKvzo X-Received: by 2002:a92:340d:0:b0:345:e438:7381 with SMTP id b13-20020a92340d000000b00345e4387381mr1959060ila.2.1697537939789; Tue, 17 Oct 2023 03:18:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537939; cv=none; d=google.com; s=arc-20160816; b=qEorJyy5vThVIlNslxvQ9rM/uOwfZ4YheBcZZCFWU8xMqkOBz3Fpb7k2C5PLdMjR9t BE3T+mzxFTGeN++EKkkNQh09q3VAJF/Vf4rsYv0buueHUVYs2o2LOhq6y5M718+dGCqe fDbWSHBZeQKNYm++J7AJokruZHas6oJysZbOawJA1hKAe5Xkh45/z6w+1WyK3893qwUM LdFK7CJ6Enmi4yYRXVAOLdrtnaQT9syvtwj4EytQzbwaQPP15kCiZhCL2r5D+H0N/Hxm Ed0bQP0zQCkyGyaD1py7WfxeFtCSaGVLzd7+817qCLSbP/n2WkNufCXrgC59mEK4mmZS EuZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=r7tBse6MzXqPGZrVfaiZomHRvOEj44B8s5j+CeRfqL4=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=XxGNO4ul4kTzte2/KXBPhiIeLa8eVaNpKoMkl5MyUtfwP6596y25bRjdWnoa6dN0Qi ILhq+DMBtGEBJvIUuUwvazBW0XQy8z74xq9CjN9t+L0lmb4qLt6K2MQKRDRlrx75v7Fa 52m4NByBJRn6NaM1hBFFlEZIhZc8dLw7k9YJA6utP6aZAd0doSivL1hz5VT8kMXGRfpd IroftN7qHjeI5Fj5HnvXl8tAIbN1enm7GbfQn0B+nQDKzDj09akC0ie5Iuxc8EN1kiub iRYWf0S/p75/KjbKUVasseVbyOornuh2v3kIHGmvioPeofkvM16/z8+jSceJDiDzFejW BWEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="BZa/WJ/1"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id i4-20020aa796e4000000b0068fad24a32csi1299264pfq.27.2023.10.17.03.18.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:18:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="BZa/WJ/1"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id E1D028040C51; Tue, 17 Oct 2023 03:18:51 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343824AbjJQKS1 (ORCPT + 19 others); Tue, 17 Oct 2023 06:18:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51596 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343794AbjJQKRn (ORCPT ); Tue, 17 Oct 2023 06:17:43 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C61EDFC; Tue, 17 Oct 2023 03:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537820; x=1729073820; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=R4C2hloBV4Q5RxIUeP/DUfELz3hN3esJuwfm4O46dow=; b=BZa/WJ/1xgxzUeQl+MImeDmCECDEfxfjoVR8NQOrL/PoSJEIuIuVhozf xrd5q3uqrw7WWuJKpKt6GpLVJBjBc4LrBPHu5KFChZvzZu4Z/HEAEcNG9 hv8IIlbFHdiXJV/5gCJFsg0g7hYNn1jnO0WGOHbWhETQXbBpkad8lBjaZ yUEXT6lnthNLQ1WxKPR5mBofTgYtXCCevEBqK3RQOKR/5eJhcpxncCrMl 9Xst6WmtFPYEoCz6jSLgQ0BssdzkfQRLphXk8I8NIlFvjtz+po7iqNyuY Ebpk0ZA/Fzgwcdw4J21VCY1FeP1pAfIVKEdmLppYNFpNV0NOsiPTnxTsM w==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="471972595" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="471972595" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:17:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503894" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503894" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:16:54 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 19/23] x86/virt/tdx: Improve readability of module initialization error handling Date: Tue, 17 Oct 2023 23:14:43 +1300 Message-ID: <7709417c896a28f0b2d4bd1fb08492a1f2ec99fb.1697532085.git.kai.huang@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:18:51 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997542648816951 X-GMAIL-MSGID: 1779997542648816951 With keeping TDMRs upon successful TDX module initialization, now only put_online_mems() and freeing the buffers of the TDSYSINFO_STRUCT and the CMR array still need to be done even when module initialization is successful. On the other hand, all other four "out_*" labels before them explicitly check the return value and only clean up when module initialization fails. This isn't ideal. Make all other four "out_*" labels only reachable when module initialization fails to improve the readability of error handling. Rename them from "out_*" to "err_*" to reflect the fact. Signed-off-by: Kai Huang Reviewed-by: Rick Edgecombe Reviewed-by: Kirill A. Shutemov --- v13 -> v14: - Fix spell typo (Rick) - Add Kirill/Rick's tags v12 -> v13: - New patch to improve error handling. (Kirill, Nikolay) --- arch/x86/virt/vmx/tdx/tdx.c | 67 +++++++++++++++++++------------------ 1 file changed, 34 insertions(+), 33 deletions(-) diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 9a02b9237612..3aaf8d8b4920 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -1104,17 +1104,17 @@ static int init_tdx_module(void) /* Allocate enough space for constructing TDMRs */ ret = alloc_tdmr_list(&tdx_tdmr_list, tdsysinfo); if (ret) - goto out_free_tdxmem; + goto err_free_tdxmem; /* Cover all TDX-usable memory regions in TDMRs */ ret = construct_tdmrs(&tdx_memlist, &tdx_tdmr_list, tdsysinfo); if (ret) - goto out_free_tdmrs; + goto err_free_tdmrs; /* Pass the TDMRs and the global KeyID to the TDX module */ ret = config_tdx_module(&tdx_tdmr_list, tdx_global_keyid); if (ret) - goto out_free_pamts; + goto err_free_pamts; /* * Hardware doesn't guarantee cache coherency across different @@ -1129,40 +1129,16 @@ static int init_tdx_module(void) /* Config the key of global KeyID on all packages */ ret = config_global_keyid(); if (ret) - goto out_reset_pamts; + goto err_reset_pamts; /* Initialize TDMRs to complete the TDX module initialization */ ret = init_tdmrs(&tdx_tdmr_list); -out_reset_pamts: - if (ret) { - /* - * Part of PAMTs may already have been initialized by the - * TDX module. Flush cache before returning PAMTs back - * to the kernel. - */ - wbinvd_on_all_cpus(); - /* - * According to the TDX hardware spec, if the platform - * doesn't have the "partial write machine check" - * erratum, any kernel read/write will never cause #MC - * in kernel space, thus it's OK to not convert PAMTs - * back to normal. But do the conversion anyway here - * as suggested by the TDX spec. - */ - tdmrs_reset_pamt_all(&tdx_tdmr_list); - } -out_free_pamts: if (ret) - tdmrs_free_pamt_all(&tdx_tdmr_list); - else - pr_info("%lu KBs allocated for PAMT\n", - tdmrs_count_pamt_kb(&tdx_tdmr_list)); -out_free_tdmrs: - if (ret) - free_tdmr_list(&tdx_tdmr_list); -out_free_tdxmem: - if (ret) - free_tdx_memlist(&tdx_memlist); + goto err_reset_pamts; + + pr_info("%lu KBs allocated for PAMT\n", + tdmrs_count_pamt_kb(&tdx_tdmr_list)); + out_put_tdxmem: /* * @tdx_memlist is written here and read at memory hotplug time. @@ -1177,6 +1153,31 @@ static int init_tdx_module(void) kfree(tdsysinfo); kfree(cmr_array); return ret; + +err_reset_pamts: + /* + * Part of PAMTs may already have been initialized by the + * TDX module. Flush cache before returning PAMTs back + * to the kernel. + */ + wbinvd_on_all_cpus(); + /* + * According to the TDX hardware spec, if the platform + * doesn't have the "partial write machine check" + * erratum, any kernel read/write will never cause #MC + * in kernel space, thus it's OK to not convert PAMTs + * back to normal. But do the conversion anyway here + * as suggested by the TDX spec. + */ + tdmrs_reset_pamt_all(&tdx_tdmr_list); +err_free_pamts: + tdmrs_free_pamt_all(&tdx_tdmr_list); +err_free_tdmrs: + free_tdmr_list(&tdx_tdmr_list); +err_free_tdxmem: + free_tdx_memlist(&tdx_memlist); + /* Do things irrelevant to module initialization result */ + goto out_put_tdxmem; } static int __tdx_enable(void) From patchwork Tue Oct 17 10:14:44 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154047 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4031522vqb; Tue, 17 Oct 2023 03:19:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFdGeB5CWpOr7l451EE6oLfpgoUshSdtgU2SEkzezbCSW2BNG5J7ZIvAsOMRyx273ta3Ey1 X-Received: by 2002:a05:6359:288d:b0:166:d9dc:5f5f with SMTP id qa13-20020a056359288d00b00166d9dc5f5fmr1454937rwb.3.1697537961673; Tue, 17 Oct 2023 03:19:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537961; cv=none; d=google.com; s=arc-20160816; b=f0Sgi76tOikfiPAF7wKYtW93OurffiBCg9nLaS4/PaLIBNezk4H9yfessHjb5jaSwB NSN9biAfTRcoVppPf82S66liHyWFUs3MCgBqwAYaXPtT07W0aabmOu6ruHnA8/gIzLZ7 a10F7BolDJOUal5UndFawdSxXwIPtWbm50lyGmvJT0hAz0t80pbyrW8KoW119cgeqsUW SONgp79PfUY0OYI6HpNny6ljU019Y2kIgzswKSL3mTOZYkjPoN7gWE0adYz+Hn/gfR/k 0N1kddWgthutkGLj0UsdM8VwH3NCt8Pdc5sbruVh2/73Ns8+EAwv6iCSr7EloT5y/ifC z84A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=XmD9L9xDp/7+cz9ndANoaApJX9m8Y+PudUDVZf8m37o=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=Qe0XeP0CrOwqmNfCv6KH32ZaiigGN8YFqZ6ZB72wqhUjEVTOA8akGHqnO+ySefrSkZ /cObP2T5aqDmEptRaraHWotP5ZtM5X9FosuI5j1qpf4SH1/ELqUI3fABUYNEZ9qWxTBZ 5BJNYz6ozuUIJB9Jt2XyvFF8JcvMaS2TuTMN2gXciT/cmxG5lNMl9OrkytVLknY8vNcL nIunHaQDAQs2q/6T5E8Vs41OgKkB3GkyKsdvdCoaZrfDAsht9PqMBzY5+pCdXge8Zwz3 uE3wHQ7rDmCVkga4y9MfynHO7m19RZHTUoDn9rqsEER1D/B3rfT06ac3hl+bxp4Q495U LOZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jtnNBUJL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id s6-20020a625e06000000b006b7f2d74121si1256337pfb.212.2023.10.17.03.19.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:19:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jtnNBUJL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id D5C1B807503A; Tue, 17 Oct 2023 03:19:08 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343918AbjJQKSa (ORCPT + 19 others); Tue, 17 Oct 2023 06:18:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343809AbjJQKRo (ORCPT ); Tue, 17 Oct 2023 06:17:44 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B76E3196; Tue, 17 Oct 2023 03:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537827; x=1729073827; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=8Da0/TJRBZ9wPF3PE/NTN7haiPXtXDy4AkrJyqo4+mE=; b=jtnNBUJLrkzcohh6Vjx4PE+jEUaiNUoyoBo4IFiNWGhK4L8YseE+490y NltntrMQAD+3olWRWNpMzzoID6VrZG53VM9j/gtr8nLjsyDEk2B7bK+be iELHHAshWmkt5rnHcsrOlU2Fqks7mN6VPvSViF+LDGdPPVgPcbFR2+Bn+ QlPYOAN8LxlmKjI+9kj14hUlC6Y9Pr3vSTsMvFfTw14BFo8GQCSX6GETW 6/4F9gztPlyeIU2uPSFXJDCDKJdq1I3UjIPbDXxqjsa6Cn6omCmZf+x+m 5CBkX4AesHMuEHY5LsKeklk9gw0CmMaZTVoUnHjWpI73q93oOWCAX0Wzq g==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="471972624" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="471972624" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:17:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503947" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503947" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:17:00 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 20/23] x86/kexec(): Reset TDX private memory on platforms with TDX erratum Date: Tue, 17 Oct 2023 23:14:44 +1300 Message-ID: X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:19:08 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997565757461898 X-GMAIL-MSGID: 1779997565757461898 The first few generations of TDX hardware have an erratum. A partial write to a TDX private memory cacheline will silently "poison" the line. Subsequent reads will consume the poison and generate a machine check. According to the TDX hardware spec, neither of these things should have happened. == Background == Virtually all kernel memory accesses operations happen in full cachelines. In practice, writing a "byte" of memory usually reads a 64 byte cacheline of memory, modifies it, then writes the whole line back. Those operations do not trigger this problem. This problem is triggered by "partial" writes where a write transaction of less than cacheline lands at the memory controller. The CPU does these via non-temporal write instructions (like MOVNTI), or through UC/WC memory mappings. The issue can also be triggered away from the CPU by devices doing partial writes via DMA. == Problem == A fast warm reset doesn't reset TDX private memory. Kexec() can also boot into the new kernel directly. Thus if the old kernel has enabled TDX on the platform with this erratum, the new kernel may get unexpected machine check. Note that w/o this erratum any kernel read/write on TDX private memory should never cause machine check, thus it's OK for the old kernel to leave TDX private pages as is. == Solution == In short, with this erratum, the kernel needs to explicitly convert all TDX private pages back to normal to give the new kernel a clean slate after kexec(). The BIOS is also expected to disable fast warm reset as a workaround to this erratum, thus this implementation doesn't try to reset TDX private memory for the reboot case in the kernel but depend on the BIOS to enable the workaround. Convert TDX private pages back to normal after all remote cpus has been stopped and cache flush has been done on all cpus, when no more TDX activity can happen further. Do it in machine_kexec() to avoid the additional overhead to the normal reboot/shutdown as the kernel depends on the BIOS to disable fast warm reset for the reboot case. For now TDX private memory can only be PAMT pages. It would be ideal to cover all types of TDX private memory here, but there are practical problems to do so: 1) There's no existing infrastructure to track TDX private pages; 2) It's not feasible to query the TDX module about page type because VMX has already been stopped when KVM receives the reboot notifier, plus the result from the TDX module may not be accurate (e.g., the remote CPU could be stopped right before MOVDIR64B). One temporary solution is to blindly convert all memory pages, but it's problematic to do so too, because not all pages are mapped as writable in the direct mapping. It can be done by switching to the identical mapping created for kexec() or a new page table, but the complexity looks overkill. Therefore, rather than doing something dramatic, only reset PAMT pages here. Other kernel components which use TDX need to do the conversion on their own by intercepting the rebooting/shutdown notifier (KVM already does that). Note kexec() can happen at anytime, including when TDX module is being initialized. Register TDX reboot notifier callback to stop further TDX module initialization. If there's any ongoing module initialization, wait until it finishes. This makes sure the TDX module status is stable after the reboot notifier callback, and the later kexec() code can read module status to decide whether PAMTs are stable and available. Also stop further TDX module initialization in case of machine shutdown and halt, but not limited to kexec(), as there's no reason to do so in these cases too. Signed-off-by: Kai Huang Reviewed-by: Kirill A. Shutemov --- v13 -> v14: - Skip resetting TDX private memory when preserve_context is true (Rick) - Use reboot notifier to stop TDX module initialization at early time of kexec() to make module status stable, to avoid using a new variable and memory barrier (which is tricky to review). - Added Kirill's tag v12 -> v13: - Improve comments to explain why barrier is needed and ignore WBINVD. (Dave) - Improve comments to document memory ordering. (Nikolay) - Made comments/changelog slightly more concise. v11 -> v12: - Changed comment/changelog to say kernel doesn't try to handle fast warm reset but depends on BIOS to enable workaround (Kirill) - Added a new tdx_may_has_private_mem to indicate system may have TDX private memory and PAMTs/TDMRs are stable to access. (Dave). - Use atomic_t for tdx_may_has_private_mem for build-in memory barrier (Dave) - Changed calling x86_platform.memory_shutdown() to calling tdx_reset_memory() directly from machine_kexec() to avoid overhead to normal reboot case. v10 -> v11: - New patch --- arch/x86/include/asm/tdx.h | 2 + arch/x86/kernel/machine_kexec_64.c | 16 ++++++ arch/x86/virt/vmx/tdx/tdx.c | 92 ++++++++++++++++++++++++++++++ 3 files changed, 110 insertions(+) diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h index 3cfd64f8a2b5..417d98595903 100644 --- a/arch/x86/include/asm/tdx.h +++ b/arch/x86/include/asm/tdx.h @@ -112,10 +112,12 @@ static inline u64 sc_retry(sc_func_t func, u64 fn, bool platform_tdx_enabled(void); int tdx_cpu_enable(void); int tdx_enable(void); +void tdx_reset_memory(void); #else static inline bool platform_tdx_enabled(void) { return false; } static inline int tdx_cpu_enable(void) { return -ENODEV; } static inline int tdx_enable(void) { return -ENODEV; } +static inline void tdx_reset_memory(void) { } #endif /* CONFIG_INTEL_TDX_HOST */ #endif /* !__ASSEMBLY__ */ diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c index 1a3e2c05a8a5..d55522902aa1 100644 --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -28,6 +28,7 @@ #include #include #include +#include #ifdef CONFIG_ACPI /* @@ -301,9 +302,24 @@ void machine_kexec(struct kimage *image) void *control_page; int save_ftrace_enabled; + /* + * For platforms with TDX "partial write machine check" erratum, + * all TDX private pages need to be converted back to normal + * before booting to the new kernel, otherwise the new kernel + * may get unexpected machine check. + * + * But skip this when preserve_context is on. The second kernel + * shouldn't write to the first kernel's memory anyway. Skipping + * this also avoids killing TDX in the first kernel, which would + * require more complicated handling. + */ #ifdef CONFIG_KEXEC_JUMP if (image->preserve_context) save_processor_state(); + else + tdx_reset_memory(); +#else + tdx_reset_memory(); #endif save_ftrace_enabled = __ftrace_enabled_save(); diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 3aaf8d8b4920..e82f0adeea4d 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -27,6 +27,7 @@ #include #include #include +#include #include #include #include @@ -48,6 +49,8 @@ static LIST_HEAD(tdx_memlist); static struct tdmr_info_list tdx_tdmr_list; +static bool tdx_rebooting; + typedef void (*sc_err_func_t)(u64 fn, u64 err, struct tdx_module_args *args); static inline void seamcall_err(u64 fn, u64 err, struct tdx_module_args *args) @@ -1184,6 +1187,9 @@ static int __tdx_enable(void) { int ret; + if (tdx_rebooting) + return -EAGAIN; + ret = init_tdx_module(); if (ret) { pr_err("module initialization failed (%d)\n", ret); @@ -1242,6 +1248,69 @@ int tdx_enable(void) } EXPORT_SYMBOL_GPL(tdx_enable); +/* + * Convert TDX private pages back to normal on platforms with + * "partial write machine check" erratum. + * + * Called from machine_kexec() before booting to the new kernel. + */ +void tdx_reset_memory(void) +{ + if (!platform_tdx_enabled()) + return; + + /* + * Kernel read/write to TDX private memory doesn't + * cause machine check on hardware w/o this erratum. + */ + if (!boot_cpu_has_bug(X86_BUG_TDX_PW_MCE)) + return; + + /* Called from kexec() when only rebooting cpu is alive */ + WARN_ON_ONCE(num_online_cpus() != 1); + + /* + * tdx_reboot_notifier() waits until ongoing TDX module + * initialization to finish, and module initialization is + * rejected after that. Therefore @tdx_module_status is + * stable here and can be read w/o holding lock. + */ + if (tdx_module_status != TDX_MODULE_INITIALIZED) + return; + + /* + * Convert PAMTs back to normal. All other cpus are already + * dead and TDMRs/PAMTs are stable. + * + * Ideally it's better to cover all types of TDX private pages + * here, but it's impractical: + * + * - There's no existing infrastructure to tell whether a page + * is TDX private memory or not. + * + * - Using SEAMCALL to query TDX module isn't feasible either: + * - VMX has been turned off by reaching here so SEAMCALL + * cannot be made; + * - Even SEAMCALL can be made the result from TDX module may + * not be accurate (e.g., remote CPU can be stopped while + * the kernel is in the middle of reclaiming TDX private + * page and doing MOVDIR64B). + * + * One temporary solution could be just converting all memory + * pages, but it's problematic too, because not all pages are + * mapped as writable in direct mapping. It can be done by + * switching to the identical mapping for kexec() or a new page + * table which maps all pages as writable, but the complexity is + * overkill. + * + * Thus instead of doing something dramatic to convert all pages, + * only convert PAMTs here. Other kernel components which use + * TDX need to do the conversion on their own by intercepting the + * rebooting/shutdown notifier (KVM already does that). + */ + tdmrs_reset_pamt_all(&tdx_tdmr_list); +} + static int __init record_keyid_partitioning(u32 *tdx_keyid_start, u32 *nr_tdx_keyids) { @@ -1320,6 +1389,21 @@ static struct notifier_block tdx_memory_nb = { .notifier_call = tdx_memory_notifier, }; +static int tdx_reboot_notifier(struct notifier_block *nb, unsigned long mode, + void *unused) +{ + /* Wait ongoing TDX initialization to finish */ + mutex_lock(&tdx_module_lock); + tdx_rebooting = true; + mutex_unlock(&tdx_module_lock); + + return NOTIFY_OK; +} + +static struct notifier_block tdx_reboot_nb = { + .notifier_call = tdx_reboot_notifier, +}; + static int __init tdx_init(void) { u32 tdx_keyid_start, nr_tdx_keyids; @@ -1350,6 +1434,14 @@ static int __init tdx_init(void) return -ENODEV; } + err = register_reboot_notifier(&tdx_reboot_nb); + if (err) { + pr_err("initialization failed: register_reboot_notifier() failed (%d)\n", + err); + unregister_memory_notifier(&tdx_memory_nb); + return -ENODEV; + } + /* * Just use the first TDX KeyID as the 'global KeyID' and * leave the rest for TDX guests. From patchwork Tue Oct 17 10:14:45 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154049 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4031576vqb; Tue, 17 Oct 2023 03:19:30 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEbw8Gr37YSkYYnqI+Q570BpRLebAzc8Xn0jeJYFx8Zr+QUXykVZ7sPT7Uma57bVEKBvAMg X-Received: by 2002:a05:6a20:c182:b0:15a:2c0b:6c81 with SMTP id bg2-20020a056a20c18200b0015a2c0b6c81mr1772674pzb.3.1697537970324; Tue, 17 Oct 2023 03:19:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537970; cv=none; d=google.com; s=arc-20160816; b=HabFH6GM+a7IZxi+/I6FWBJXWQGIbAi/je/ZrBsCFTjFeyYMo7WvEH4F5KR6cSk+Qw OGA9+L/tBVPONIrQ5CURtWg13oDNvTrUpHDscYsY6pdhjGoR96Cj/PKFq9BNn83lastm RnteFBcbx4sYsSCC0FxkSIZdQLp1xgLmkARqzutblWmXeVGNHQhVJSyNz8WNSVFZbFoi vCMJelqhwe7CkkV8pgjnf0QM01uzWKp+Osk62oV7oqO3Ii8vEJXul2s1z4WycsXBNeIP qPeDQWPlm9WgAcermQjw2E536sEEfYRfXkl192u0AvnFE7gZtSjKeybfl1P1pP5U7xR2 qLtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=MEaTi4H0M9UIJXdDMs5kCl8HsYk3qsd98O3KHbbhK0g=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=XBwbdb3vfyHcv091x1PbPGW1rySiseTUV0GwHEnBMTuDSIzc1cl6wASFEhdGR9+cTX 4tTKSqKJnwpQWAViVI/kpg79dKsW0q0gS//7wX3L/CuZ04PlWH7shQqCghlrtg1MbYvu l0vhoY9Tcba35OkRx6NHT3KIvsA4IrrPKvK/0SoEbPOHyMGiXIxaskuHz1Yn0NUOROxE Ft9nVrhW6/x/upCnv2mL0IsK7LGLvv/fK3sUHbtzVJlUJmbtOyNAU6OEhMuPsVAoScMM q7tMkodMPp7PxoayR395EtRiRYAola2PsWEi6Ob7X56e8WHS5hG48cCLZvD5SRe/3lqD 6HUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=HXmiJjrO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id be3-20020a656e43000000b005789f94cd34si1412293pgb.636.2023.10.17.03.19.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:19:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=HXmiJjrO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id B2F8E802F69C; Tue, 17 Oct 2023 03:19:24 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343820AbjJQKSp (ORCPT + 19 others); Tue, 17 Oct 2023 06:18:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343832AbjJQKRq (ORCPT ); Tue, 17 Oct 2023 06:17:46 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A98D410B; Tue, 17 Oct 2023 03:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537833; x=1729073833; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=8M6A/iAWwAdbCNObEOw+xUv3oHPvF8QdJDksd9FDpGU=; b=HXmiJjrO63ELc702bmvc8VqG2763zg4jIRXDuGhejZIjAm+q8Zv2UJ5V z1CWWDaEZ8Sa8UvwedRbt9PgEVGL4ORhoH6gH7RVKR5Sq4r7q+LKh9Q4/ AO0E2LuyhAS637GR8oBblzonM7+k7RN9+q24ZYLyCRIkdu986BdZcH/RQ dBnhhUa7bJjkdj9BjQFm2CC8rXVkzAxzwWpMAFi4WHKSlaQHSUnDmw2jr t/yWEX4KUAzTykmEoGKOhXJwLyXQ4L++iboJMSC5aZHQ+EBrrlBycp5J4 +B7na4JUqNIAflIHrSxwBWvxuQBRREHsnxnJUBJGvrtzT0o/QhTkERX78 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="471972644" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="471972644" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:17:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872503999" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872503999" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:17:06 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 21/23] x86/virt/tdx: Handle TDX interaction with ACPI S3 and deeper states Date: Tue, 17 Oct 2023 23:14:45 +1300 Message-ID: <7daec6d20bf93c2ff87268866d112ee8efd44e01.1697532085.git.kai.huang@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:19:24 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997575114983873 X-GMAIL-MSGID: 1779997575114983873 TDX cannot survive from S3 and deeper states. The hardware resets and disables TDX completely when platform goes to S3 and deeper. Both TDX guests and the TDX module get destroyed permanently. The kernel uses S3 to support suspend-to-ram, and S4 or deeper states to support hibernation. The kernel also maintains TDX states to track whether it has been initialized and its metadata resource, etc. After resuming from S3 or hibernation, these TDX states won't be correct anymore. Theoretically, the kernel can do more complicated things like resetting TDX internal states and TDX module metadata before going to S3 or deeper, and re-initialize TDX module after resuming, etc, but there is no way to save/restore TDX guests for now. Until TDX supports full save and restore of TDX guests, there is no big value to handle TDX module in suspend and hibernation alone. To make things simple, just choose to make TDX mutually exclusive with S3 and hibernation. Note the TDX module is initialized at runtime. To avoid having to deal with the fuss of determining TDX state at runtime, just choose TDX vs S3 and hibernation at kernel early boot. It's a bad user experience if the choice of TDX and S3/hibernation is done at runtime anyway, i.e., the user can experience being able to do S3/hibernation but later becoming unable to due to TDX being enabled. Disable TDX in kernel early boot when hibernation is available, and give a message telling the user to disable hibernation via kernel command line in order to use TDX. Currently there's no mechanism exposed by the hibernation code to allow other kernel code to disable hibernation once for all. Disable ACPI S3 by setting acpi_suspend_lowlevel function pointer to NULL when TDX is enabled by the BIOS. This avoids having to modify the ACPI code to disable ACPI S3 in other ways. Also give a message telling the user to disable TDX in the BIOS in order to use ACPI S3. A new kernel command line can be added in the future if there's a need to let user disable TDX host via kernel command line. Signed-off-by: Kai Huang Reviewed-by: Kirill A. Shutemov Signed-off-by: Kai Huang Signed-off-by: Kai Huang --- v13 -> v14: - New patch --- arch/x86/virt/vmx/tdx/tdx.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index e82f0adeea4d..1d0f1045dd33 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -28,10 +28,12 @@ #include #include #include +#include #include #include #include #include +#include #include #include "tdx.h" @@ -1427,6 +1429,22 @@ static int __init tdx_init(void) return -ENODEV; } +#define HIBERNATION_MSG \ + "Disable TDX due to hibernation is available. Use 'nohibernate' command line to disable hibernation." + /* + * Note hibernation_available() can vary when it is called at + * runtime as it checks secretmem_active() and cxl_mem_active() + * which can both vary at runtime. But here at early_init() they + * both cannot return true, thus when hibernation_available() + * returns false here, hibernation is disabled by either + * 'nohibernate' or LOCKDOWN_HIBERNATION security lockdown, + * which are both permanent. + */ + if (hibernation_available()) { + pr_err("initialization failed: %s\n", HIBERNATION_MSG); + return -ENODEV; + } + err = register_memory_notifier(&tdx_memory_nb); if (err) { pr_err("initialization failed: register_memory_notifier() failed (%d)\n", @@ -1442,6 +1460,11 @@ static int __init tdx_init(void) return -ENODEV; } +#ifdef CONFIG_ACPI + pr_info("Disable ACPI S3 suspend. Turn off TDX in the BIOS to use ACPI S3.\n"); + acpi_suspend_lowlevel = NULL; +#endif + /* * Just use the first TDX KeyID as the 'global KeyID' and * leave the rest for TDX guests. From patchwork Tue Oct 17 10:14:46 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154050 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4031603vqb; Tue, 17 Oct 2023 03:19:34 -0700 (PDT) X-Google-Smtp-Source: AGHT+IED3VfaEm5JQc3YYcK3O9MWtyi1ziDDGVwzNyuNc72COqKhT+1e3x497mSkLWG7fnGYbo4d X-Received: by 2002:a05:6a00:6008:b0:68f:c309:9736 with SMTP id fo8-20020a056a00600800b0068fc3099736mr1711167pfb.3.1697537974327; Tue, 17 Oct 2023 03:19:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537974; cv=none; d=google.com; s=arc-20160816; b=ripoqxYXv9KmxAnZI449pzEeW2I5A1HN9XpVO2xF1ihHoxvPRVKUSZSaP6vS9lBpDf G88eR3/h3ucmunIgeWoz2t47U/md6zSSCRiLqng81IEkCh2drGb4iXeFMireRndr3KfF RIrTYJ/Ua8oeTU6STgGGI/OBDq1Jjk0JjNcG9/vXwM7LrYbzhmgPo3KSwv85wRnhlpRM D4HKfaS9TiSLYdLUMCB8AyLb+gTv0f2rSm6zGQGhRoCGZ+T5Y8b0Y3ybUnAf3gwCy+9R uYgeuoS9itFKOGTjxxNSr2M1n1a97WG1jBMsqhqcFntYxBPmGN5pC8GVHqj/Dq+6bemw +Fjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=knO+/IlsUc8uYBqkGKTPAxe/5Yn9buI28N+Kf4N4Kao=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=owHw5kjLFxFu0nYsDy3FnjJj8eB+hYfMeQhd5KR1srbNpMLI7BJEuT9rkAsmz9dUq/ cM6VOPoJW/6AayaqBIlGR1p5Gb6bDcDXDiAfYl0FG68pLlANCuQm2TQ/EFtSCEcJE+0y 76hFHa93UAeuINKAXDpUz0Cn7nMxI1GDM6dP0NmyheToAXK8SOJ2Vr3acjhylrGSnK0X ELo4+SjzSgFlp/Ed1QiqNyIEuWQZAcWwlHN7jpxM1gt6jYi43aL1QSqJHYpPD/FI61xs M9jdAvE9FwAc+nwcZI5RLxxXo720CZ2TWHEP8KJGnJcpd6iw117O8WIQ9XSGdyVG62y1 hSww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=J1L7g9eb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from morse.vger.email (morse.vger.email. [2620:137:e000::3:1]) by mx.google.com with ESMTPS id f7-20020a056a001ac700b006b6efb7f99fsi1342478pfv.280.2023.10.17.03.19.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:19:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=J1L7g9eb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by morse.vger.email (Postfix) with ESMTP id 415FF801F35E; Tue, 17 Oct 2023 03:19:29 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at morse.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343730AbjJQKSe (ORCPT + 19 others); Tue, 17 Oct 2023 06:18:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343715AbjJQKSB (ORCPT ); Tue, 17 Oct 2023 06:18:01 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9987219D; Tue, 17 Oct 2023 03:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537839; x=1729073839; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=lIl4r0dPTRvwlMmObgg/+6STYlNC/oefL41oDb1q92I=; b=J1L7g9ebsTA9jpgWA62m+/Pss4CDzJFs1TLsPRBWcjSe0ygw1Qi6kIx2 OXbH0GbTCx1vH1Q8a/3n8eVWqzQwyFg0ZSkdiqYl7cmpT2r5b6SJnii5l Uf2ifPz5Mu2+pmlPqSrQ79GOGy0BfxLiernlJobFz3JrNBCTT22sXcKJZ T9uxgH+ZosaDdmGuZCmf6OtvIyldObVVBwYPxqq14Gm5uuKpxP+MaSTG7 lgv0K7sQfHBPazGO0wS8qJGUO466e2LlYlx+U+1q3l+tuxCmDhdJsDz9b phWQGxqwbVSFHaqHVW2m1JzY6B+l5RRYcl+Qqw0GFkfimYU0fNZCHyJZV w==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="471972682" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="471972682" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:17:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872504026" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872504026" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:17:13 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 22/23] x86/mce: Improve error log of kernel space TDX #MC due to erratum Date: Tue, 17 Oct 2023 23:14:46 +1300 Message-ID: <8bd7eaf243eadf2bdc14ad21070f2e71be74b5b1.1697532085.git.kai.huang@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:19:29 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997578981802747 X-GMAIL-MSGID: 1779997578981802747 The first few generations of TDX hardware have an erratum. Triggering it in Linux requires some kind of kernel bug involving relatively exotic memory writes to TDX private memory and will manifest via spurious-looking machine checks when reading the affected memory. == Background == Virtually all kernel memory accesses operations happen in full cachelines. In practice, writing a "byte" of memory usually reads a 64 byte cacheline of memory, modifies it, then writes the whole line back. Those operations do not trigger this problem. This problem is triggered by "partial" writes where a write transaction of less than cacheline lands at the memory controller. The CPU does these via non-temporal write instructions (like MOVNTI), or through UC/WC memory mappings. The issue can also be triggered away from the CPU by devices doing partial writes via DMA. == Problem == A partial write to a TDX private memory cacheline will silently "poison" the line. Subsequent reads will consume the poison and generate a machine check. According to the TDX hardware spec, neither of these things should have happened. To add insult to injury, the Linux machine code will present these as a literal "Hardware error" when they were, in fact, a software-triggered issue. == Solution == In the end, this issue is hard to trigger. Rather than do something rash (and incomplete) like unmap TDX private memory from the direct map, improve the machine check handler. Currently, the #MC handler doesn't distinguish whether the memory is TDX private memory or not but just dump, for instance, below message: [...] mce: [Hardware Error]: CPU 147: Machine Check Exception: f Bank 1: bd80000000100134 [...] mce: [Hardware Error]: RIP 10: {__tlb_remove_page_size+0x10/0xa0} ... [...] mce: [Hardware Error]: Run the above through 'mcelog --ascii' [...] mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel [...] Kernel panic - not syncing: Fatal local machine check Which says "Hardware Error" and "Data load in unrecoverable area of kernel". Ideally, it's better for the log to say "software bug around TDX private memory" instead of "Hardware Error". But in reality the real hardware memory error can happen, and sadly such software-triggered #MC cannot be distinguished from the real hardware error. Also, the error message is used by userspace tool 'mcelog' to parse, so changing the output may break userspace. So keep the "Hardware Error". The "Data load in unrecoverable area of kernel" is also helpful, so keep it too. Instead of modifying above error log, improve the error log by printing additional TDX related message to make the log like: ... [...] mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel [...] mce: [Hardware Error]: Machine Check: TDX private memory error. Possible kernel bug. Adding this additional message requires determination of whether the memory page is TDX private memory. There is no existing infrastructure to do that. Add an interface to query the TDX module to fill this gap. == Impact == This issue requires some kind of kernel bug to trigger. TDX private memory should never be mapped UC/WC. A partial write originating from these mappings would require *two* bugs, first mapping the wrong page, then writing the wrong memory. It would also be detectable using traditional memory corruption techniques like DEBUG_PAGEALLOC. MOVNTI (and friends) could cause this issue with something like a simple buffer overrun or use-after-free on the direct map. It should also be detectable with normal debug techniques. The one place where this might get nasty would be if the CPU read data then wrote back the same data. That would trigger this problem but would not, for instance, set off mechanisms like slab redzoning because it doesn't actually corrupt data. With an IOMMU at least, the DMA exposure is similar to the UC/WC issue. TDX private memory would first need to be incorrectly mapped into the I/O space and then a later DMA to that mapping would actually cause the poisoning event. Signed-off-by: Kai Huang Reviewed-by: Kirill A. Shutemov Reviewed-by: Yuan Yao --- v13 -> v14: - No change v12 -> v13: - Added Kirill and Yuan's tag. v11 -> v12: - Simplified #MC message (Dave/Kirill) - Slightly improved some comments. v10 -> v11: - New patch --- arch/x86/include/asm/tdx.h | 2 + arch/x86/kernel/cpu/mce/core.c | 33 +++++++++++ arch/x86/virt/vmx/tdx/tdx.c | 103 +++++++++++++++++++++++++++++++++ arch/x86/virt/vmx/tdx/tdx.h | 5 ++ 4 files changed, 143 insertions(+) diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h index 417d98595903..0b72d18a9f48 100644 --- a/arch/x86/include/asm/tdx.h +++ b/arch/x86/include/asm/tdx.h @@ -113,11 +113,13 @@ bool platform_tdx_enabled(void); int tdx_cpu_enable(void); int tdx_enable(void); void tdx_reset_memory(void); +bool tdx_is_private_mem(unsigned long phys); #else static inline bool platform_tdx_enabled(void) { return false; } static inline int tdx_cpu_enable(void) { return -ENODEV; } static inline int tdx_enable(void) { return -ENODEV; } static inline void tdx_reset_memory(void) { } +static inline bool tdx_is_private_mem(unsigned long phys) { return false; } #endif /* CONFIG_INTEL_TDX_HOST */ #endif /* !__ASSEMBLY__ */ diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c index 6f35f724cc14..5ed623e34a14 100644 --- a/arch/x86/kernel/cpu/mce/core.c +++ b/arch/x86/kernel/cpu/mce/core.c @@ -52,6 +52,7 @@ #include #include #include +#include #include "internal.h" @@ -228,11 +229,34 @@ static void wait_for_panic(void) panic("Panicing machine check CPU died"); } +static const char *mce_memory_info(struct mce *m) +{ + if (!m || !mce_is_memory_error(m) || !mce_usable_address(m)) + return NULL; + + /* + * Certain initial generations of TDX-capable CPUs have an + * erratum. A kernel non-temporal partial write to TDX private + * memory poisons that memory, and a subsequent read of that + * memory triggers #MC. + * + * However such #MC caused by software cannot be distinguished + * from the real hardware #MC. Just print additional message + * to show such #MC may be result of the CPU erratum. + */ + if (!boot_cpu_has_bug(X86_BUG_TDX_PW_MCE)) + return NULL; + + return !tdx_is_private_mem(m->addr) ? NULL : + "TDX private memory error. Possible kernel bug."; +} + static noinstr void mce_panic(const char *msg, struct mce *final, char *exp) { struct llist_node *pending; struct mce_evt_llist *l; int apei_err = 0; + const char *memmsg; /* * Allow instrumentation around external facilities usage. Not that it @@ -283,6 +307,15 @@ static noinstr void mce_panic(const char *msg, struct mce *final, char *exp) } if (exp) pr_emerg(HW_ERR "Machine check: %s\n", exp); + /* + * Confidential computing platforms such as TDX platforms + * may occur MCE due to incorrect access to confidential + * memory. Print additional information for such error. + */ + memmsg = mce_memory_info(final); + if (memmsg) + pr_emerg(HW_ERR "Machine check: %s\n", memmsg); + if (!fake_panic) { if (panic_timeout == 0) panic_timeout = mca_cfg.panic_timeout; diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 1d0f1045dd33..38ec6815a42a 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -1313,6 +1313,109 @@ void tdx_reset_memory(void) tdmrs_reset_pamt_all(&tdx_tdmr_list); } +static bool is_pamt_page(unsigned long phys) +{ + struct tdmr_info_list *tdmr_list = &tdx_tdmr_list; + int i; + + /* + * This function is called from #MC handler, and theoretically + * it could run in parallel with the TDX module initialization + * on other logical cpus. But it's not OK to hold mutex here + * so just blindly check module status to make sure PAMTs/TDMRs + * are stable to access. + * + * This may return inaccurate result in rare cases, e.g., when + * #MC happens on a PAMT page during module initialization, but + * this is fine as #MC handler doesn't need a 100% accurate + * result. + */ + if (tdx_module_status != TDX_MODULE_INITIALIZED) + return false; + + for (i = 0; i < tdmr_list->nr_consumed_tdmrs; i++) { + unsigned long base, size; + + tdmr_get_pamt(tdmr_entry(tdmr_list, i), &base, &size); + + if (phys >= base && phys < (base + size)) + return true; + } + + return false; +} + +/* + * Return whether the memory page at the given physical address is TDX + * private memory or not. Called from #MC handler do_machine_check(). + * + * Note this function may not return an accurate result in rare cases. + * This is fine as the #MC handler doesn't need a 100% accurate result, + * because it cannot distinguish #MC between software bug and real + * hardware error anyway. + */ +bool tdx_is_private_mem(unsigned long phys) +{ + struct tdx_module_args args = { + .rcx = phys & PAGE_MASK, + }; + u64 sret; + + if (!platform_tdx_enabled()) + return false; + + /* Get page type from the TDX module */ + sret = __seamcall_ret(TDH_PHYMEM_PAGE_RDMD, &args); + /* + * Handle the case that CPU isn't in VMX operation. + * + * KVM guarantees no VM is running (thus no TDX guest) + * when there's any online CPU isn't in VMX operation. + * This means there will be no TDX guest private memory + * and Secure-EPT pages. However the TDX module may have + * been initialized and the memory page could be PAMT. + */ + if (sret == TDX_SEAMCALL_UD) + return is_pamt_page(phys); + + /* + * Any other failure means: + * + * 1) TDX module not loaded; or + * 2) Memory page isn't managed by the TDX module. + * + * In either case, the memory page cannot be a TDX + * private page. + */ + if (sret) + return false; + + /* + * SEAMCALL was successful -- read page type (via RCX): + * + * - PT_NDA: Page is not used by the TDX module + * - PT_RSVD: Reserved for Non-TDX use + * - Others: Page is used by the TDX module + * + * Note PAMT pages are marked as PT_RSVD but they are also TDX + * private memory. + * + * Note: Even page type is PT_NDA, the memory page could still + * be associated with TDX private KeyID if the kernel hasn't + * explicitly used MOVDIR64B to clear the page. Assume KVM + * always does that after reclaiming any private page from TDX + * gusets. + */ + switch (args.rcx) { + case PT_NDA: + return false; + case PT_RSVD: + return is_pamt_page(phys); + default: + return true; + } +} + static int __init record_keyid_partitioning(u32 *tdx_keyid_start, u32 *nr_tdx_keyids) { diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h index 6e41b0731e48..5bcbfc2fc466 100644 --- a/arch/x86/virt/vmx/tdx/tdx.h +++ b/arch/x86/virt/vmx/tdx/tdx.h @@ -16,6 +16,7 @@ /* * TDX module SEAMCALL leaf functions */ +#define TDH_PHYMEM_PAGE_RDMD 24 #define TDH_SYS_KEY_CONFIG 31 #define TDH_SYS_INFO 32 #define TDH_SYS_INIT 33 @@ -23,6 +24,10 @@ #define TDH_SYS_TDMR_INIT 36 #define TDH_SYS_CONFIG 45 +/* TDX page types */ +#define PT_NDA 0x0 +#define PT_RSVD 0x1 + struct cmr_info { u64 base; u64 size; From patchwork Tue Oct 17 10:14:47 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Huang X-Patchwork-Id: 154046 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4031509vqb; Tue, 17 Oct 2023 03:19:20 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFfoHmeva3CXayr4oC3yFOwfJiz5BKt2ci/VgNLUq5AlrCae7auRlO1fn5a8R/rwOfwhAZy X-Received: by 2002:a17:90b:4c8b:b0:27d:2762:2728 with SMTP id my11-20020a17090b4c8b00b0027d27622728mr1877346pjb.0.1697537959994; Tue, 17 Oct 2023 03:19:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697537959; cv=none; d=google.com; s=arc-20160816; b=K4sZ6VHJ5zr70Fw2tGL2tYflkgDOVNUU/Bz+66HPfO4sz1fBK37JktFVj7JrDkoOt3 BDP3FCCqAZfzSsjfhr2RO09jdqLF6v+R5WfTf+FT3EZ4AHxaJjenuMSbn+J+mxuBN0oS GXZqGODkrs0GaalcVxmF66o6t3TRiWyQtnMSXnNgcjOOAw2dU8BJKenBXvK4iHR7t3zu cZRD5nTq55l5OhMGRyl99Q5RBsF1BujlJteTIYc/Da2DBRhjbCOPRyhnmMKzcVaek1/D kXNxTacaKOBdo2vhyYvWFGud6X1YAMNkh+qkEgHFs6NKeuq47UtLed6yvCuZl6AAfI+S 3xwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=/PzWJLzmyCWOynpj66PRZiRvsKaLCHxPzApcIfWYGqc=; fh=WBgbLtMencYhgeHuu2sUs5b9THiYLgy17d2w1N+xuf4=; b=aB6PaW7TKp3/p+BsLBzovYtxZigaNkXlTuT9xHoXTIIgxS9rTCQPkoef7LvQAF9aPG Yf5K7Tt4hxKrp1eYQ7vaIkc0tI0eu+fA/ye5+QLtsNOK70yQOwP4BR0ssN/f0GpqYKC9 BVu6G78DXAAORQjmqwu4G1ovznOzoLhLaieP9eXSYlbfhBJwZwySVq9/o4N5T0jUatWr dy3ohjvQXzQihlvSwPVWzPSLpZ5IO68iF7UmoZds7w2Pc9r3E5vZ+b/q6+vbWMzYJeTl Bz/V0MBaajpuc32qHh9pLHxxUiAlrtdhCi+p6ui1uIfRpzGUGMIqJrlnxyBlMnE+Lfwd JNDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Vm1Z5CiO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id mh17-20020a17090b4ad100b0027d4f7298e2si9196380pjb.65.2023.10.17.03.19.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 03:19:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Vm1Z5CiO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 4A61B80398EE; Tue, 17 Oct 2023 03:19:16 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234982AbjJQKTB (ORCPT + 19 others); Tue, 17 Oct 2023 06:19:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39812 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343782AbjJQKSR (ORCPT ); Tue, 17 Oct 2023 06:18:17 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB96510F5; Tue, 17 Oct 2023 03:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1697537846; x=1729073846; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=y4yMyedDeteyldyvQVYJqX2ni5QeOfCnD2RsBQvoGjM=; b=Vm1Z5CiO1Ul063gAXpupe8DnJCt6J1RmJ/9DXLL8SHCqzwBPn6RXZbqA kqHwPKvoutSXu1Fs2IvSFUBKzRwyZmsEl0v3L9PGUVSiLNFNDQeMVj2pk eZBc5qs7hk7Emrf+raWzBm6yy/uAi2bfeRpV9jhA0B7E2E+KHpBhZqXZO 8Dt3jWdNCpHkJB3nY833JlNalWexUy+jVHa3X7BTd9gViZIP2ylefwMUA 4YmKY7z1R5t+A6p9BL9kzQkA8fuMSYLoGqL5mI/wgBAppn/L+OSZ1lP4u shlKoFC/ujwACJAHlb70fy+IOrI+m5kiMCyjmdO9tSwUus7Asa58ZPgpV A==; X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="471972732" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="471972732" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:17:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10865"; a="872504064" X-IronPort-AV: E=Sophos;i="6.03,231,1694761200"; d="scan'208";a="872504064" Received: from chowe-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.255.229.64]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 03:17:19 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: x86@kernel.org, dave.hansen@intel.com, kirill.shutemov@linux.intel.com, peterz@infradead.org, tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de, mingo@redhat.com, hpa@zytor.com, seanjc@google.com, pbonzini@redhat.com, rafael@kernel.org, david@redhat.com, dan.j.williams@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, ying.huang@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, nik.borisov@suse.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v14 23/23] Documentation/x86: Add documentation for TDX host support Date: Tue, 17 Oct 2023 23:14:47 +1300 Message-ID: <5760a79a5d0755323d590f356ad2cc67c4d7df83.1697532085.git.kai.huang@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Tue, 17 Oct 2023 03:19:16 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779997564255076048 X-GMAIL-MSGID: 1779997564255076048 Add documentation for TDX host kernel support. There is already one file Documentation/x86/tdx.rst containing documentation for TDX guest internals. Also reuse it for TDX host kernel support. Introduce a new level menu "TDX Guest Support" and move existing materials under it, and add a new menu for TDX host kernel support. Signed-off-by: Kai Huang --- - Added new sections for "Erratum" and "TDX vs S3/hibernation" --- Documentation/arch/x86/tdx.rst | 217 +++++++++++++++++++++++++++++++-- 1 file changed, 206 insertions(+), 11 deletions(-) diff --git a/Documentation/arch/x86/tdx.rst b/Documentation/arch/x86/tdx.rst index dc8d9fd2c3f7..0f524b9d1353 100644 --- a/Documentation/arch/x86/tdx.rst +++ b/Documentation/arch/x86/tdx.rst @@ -10,6 +10,201 @@ encrypting the guest memory. In TDX, a special module running in a special mode sits between the host and the guest and manages the guest/host separation. +TDX Host Kernel Support +======================= + +TDX introduces a new CPU mode called Secure Arbitration Mode (SEAM) and +a new isolated range pointed by the SEAM Ranger Register (SEAMRR). A +CPU-attested software module called 'the TDX module' runs inside the new +isolated range to provide the functionalities to manage and run protected +VMs. + +TDX also leverages Intel Multi-Key Total Memory Encryption (MKTME) to +provide crypto-protection to the VMs. TDX reserves part of MKTME KeyIDs +as TDX private KeyIDs, which are only accessible within the SEAM mode. +BIOS is responsible for partitioning legacy MKTME KeyIDs and TDX KeyIDs. + +Before the TDX module can be used to create and run protected VMs, it +must be loaded into the isolated range and properly initialized. The TDX +architecture doesn't require the BIOS to load the TDX module, but the +kernel assumes it is loaded by the BIOS. + +TDX boot-time detection +----------------------- + +The kernel detects TDX by detecting TDX private KeyIDs during kernel +boot. Below dmesg shows when TDX is enabled by BIOS:: + + [..] virt/tdx: BIOS enabled: private KeyID range: [16, 64) + +TDX module initialization +--------------------------------------- + +The kernel talks to the TDX module via the new SEAMCALL instruction. The +TDX module implements SEAMCALL leaf functions to allow the kernel to +initialize it. + +If the TDX module isn't loaded, the SEAMCALL instruction fails with a +special error. In this case the kernel fails the module initialization +and reports the module isn't loaded:: + + [..] virt/tdx: module not loaded + +Initializing the TDX module consumes roughly ~1/256th system RAM size to +use it as 'metadata' for the TDX memory. It also takes additional CPU +time to initialize those metadata along with the TDX module itself. Both +are not trivial. The kernel initializes the TDX module at runtime on +demand. + +Besides initializing the TDX module, a per-cpu initialization SEAMCALL +must be done on one cpu before any other SEAMCALLs can be made on that +cpu. + +The kernel provides two functions, tdx_enable() and tdx_cpu_enable() to +allow the user of TDX to enable the TDX module and enable TDX on local +cpu. + +Making SEAMCALL requires the CPU already being in VMX operation (VMXON +has been done). For now both tdx_enable() and tdx_cpu_enable() don't +handle VMXON internally, but depends on the caller to guarantee that. + +To enable TDX, the caller of TDX should: 1) hold read lock of CPU hotplug +lock; 2) do VMXON and tdx_enable_cpu() on all online cpus successfully; +3) call tdx_enable(). For example:: + + cpus_read_lock(); + on_each_cpu(vmxon_and_tdx_cpu_enable()); + ret = tdx_enable(); + cpus_read_unlock(); + if (ret) + goto no_tdx; + // TDX is ready to use + +And the caller of TDX must guarantee the tdx_cpu_enable() has been +successfully done on any cpu before it wants to run any other SEAMCALL. +A typical usage is do both VMXON and tdx_cpu_enable() in CPU hotplug +online callback, and refuse to online if tdx_cpu_enable() fails. + +User can consult dmesg to see whether the TDX module has been initialized. + +If the TDX module is initialized successfully, dmesg shows something +like below:: + + [..] virt/tdx: TDX module: attributes 0x0, vendor_id 0x8086, major_version 1, minor_version 0, build_date 20211209, build_num 160 + [..] virt/tdx: 262668 KBs allocated for PAMT + [..] virt/tdx: module initialized + +If the TDX module failed to initialize, dmesg also shows it failed to +initialize:: + + [..] virt/tdx: module initialization failed ... + +TDX Interaction to Other Kernel Components +------------------------------------------ + +TDX Memory Policy +~~~~~~~~~~~~~~~~~ + +TDX reports a list of "Convertible Memory Region" (CMR) to tell the +kernel which memory is TDX compatible. The kernel needs to build a list +of memory regions (out of CMRs) as "TDX-usable" memory and pass those +regions to the TDX module. Once this is done, those "TDX-usable" memory +regions are fixed during module's lifetime. + +To keep things simple, currently the kernel simply guarantees all pages +in the page allocator are TDX memory. Specifically, the kernel uses all +system memory in the core-mm at the time of initializing the TDX module +as TDX memory, and in the meantime, refuses to online any non-TDX-memory +in the memory hotplug. + +Physical Memory Hotplug +~~~~~~~~~~~~~~~~~~~~~~~ + +Note TDX assumes convertible memory is always physically present during +machine's runtime. A non-buggy BIOS should never support hot-removal of +any convertible memory. This implementation doesn't handle ACPI memory +removal but depends on the BIOS to behave correctly. + +CPU Hotplug +~~~~~~~~~~~ + +TDX module requires the per-cpu initialization SEAMCALL (TDH.SYS.LP.INIT) +must be done on one cpu before any other SEAMCALLs can be made on that +cpu, including those involved during the module initialization. + +The kernel provides tdx_cpu_enable() to let the user of TDX to do it when +the user wants to use a new cpu for TDX task. + +TDX doesn't support physical (ACPI) CPU hotplug. During machine boot, +TDX verifies all boot-time present logical CPUs are TDX compatible before +enabling TDX. A non-buggy BIOS should never support hot-add/removal of +physical CPU. Currently the kernel doesn't handle physical CPU hotplug, +but depends on the BIOS to behave correctly. + +Note TDX works with CPU logical online/offline, thus the kernel still +allows to offline logical CPU and online it again. + +Kexec() +~~~~~~~ + +There are two problems in terms of using kexec() to boot to a new kernel +when the old kernel has enabled TDX: 1) Part of the memory pages are +still TDX private pages; 2) There might be dirty cachelines associated +with TDX private pages. + +The first problem doesn't matter. KeyID 0 doesn't have integrity check. +Even the new kernel wants use any non-zero KeyID, it needs to convert +the memory to that KeyID and such conversion would work from any KeyID. + +However the old kernel needs to guarantee there's no dirty cacheline +left behind before booting to the new kernel to avoid silent corruption +from later cacheline writeback (Intel hardware doesn't guarantee cache +coherency across different KeyIDs). + +Similar to AMD SME, the kernel just uses wbinvd() to flush cache before +booting to the new kernel. + +Erratum +~~~~~~~ + +The first few generations of TDX hardware have an erratum. A partial +write to a TDX private memory cacheline will silently "poison" the +line. Subsequent reads will consume the poison and generate a machine +check. + +A partial write is a memory write where a write transaction of less than +cacheline lands at the memory controller. The CPU does these via +non-temporal write instructions (like MOVNTI), or through UC/WC memory +mappings. Devices can also do partial writes via DMA. + +Theoretically, a kernel bug could do partial write to TDX private memory +and trigger unexpected machine check. What's more, the machine check +code will present these as "Hardware error" when they were, in fact, a +software-triggered issue. But in the end, this issue is hard to trigger. + +If the platform has such erratum, the kernel does additional things: +1) resetting TDX private pages using MOVDIR64B in kexec before booting to +the new kernel; 2) Printing additional message in machine check handler +to tell user the machine check may be caused by kernel bug on TDX private +memory. + +Interaction vs S3 and deeper states +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +TDX cannot survive from S3 and deeper states. The hardware resets and +disables TDX completely when platform goes to S3 and deeper. Both TDX +guests and the TDX module get destroyed permanently. + +The kernel uses S3 for suspend-to-ram, and use S4 and deeper states for +hibernation. Currently, for simplicity, the kernel chooses to make TDX +mutually exclusive with S3 and hibernation. + +For most cases, the user needs to add 'nohibernation' kernel command line +in order to use TDX. S3 is disabled during kernel early boot if TDX is +detected. The user needs to turn off TDX in the BIOS in order to use S3. + +TDX Guest Support +================= Since the host cannot directly access guest registers or memory, much normal functionality of a hypervisor must be moved into the guest. This is implemented using a Virtualization Exception (#VE) that is handled by the @@ -20,7 +215,7 @@ TDX includes new hypercall-like mechanisms for communicating from the guest to the hypervisor or the TDX module. New TDX Exceptions -================== +------------------ TDX guests behave differently from bare-metal and traditional VMX guests. In TDX guests, otherwise normal instructions or memory accesses can cause @@ -30,7 +225,7 @@ Instructions marked with an '*' conditionally cause exceptions. The details for these instructions are discussed below. Instruction-based #VE ---------------------- +~~~~~~~~~~~~~~~~~~~~~ - Port I/O (INS, OUTS, IN, OUT) - HLT @@ -41,7 +236,7 @@ Instruction-based #VE - CPUID* Instruction-based #GP ---------------------- +~~~~~~~~~~~~~~~~~~~~~ - All VMX instructions: INVEPT, INVVPID, VMCLEAR, VMFUNC, VMLAUNCH, VMPTRLD, VMPTRST, VMREAD, VMRESUME, VMWRITE, VMXOFF, VMXON @@ -52,7 +247,7 @@ Instruction-based #GP - RDMSR*,WRMSR* RDMSR/WRMSR Behavior --------------------- +~~~~~~~~~~~~~~~~~~~~ MSR access behavior falls into three categories: @@ -73,7 +268,7 @@ trapping and handling in the TDX module. Other than possibly being slow, these MSRs appear to function just as they would on bare metal. CPUID Behavior --------------- +~~~~~~~~~~~~~~ For some CPUID leaves and sub-leaves, the virtualized bit fields of CPUID return values (in guest EAX/EBX/ECX/EDX) are configurable by the @@ -93,7 +288,7 @@ not know how to handle. The guest kernel may ask the hypervisor for the value with a hypercall. #VE on Memory Accesses -====================== +---------------------- There are essentially two classes of TDX memory: private and shared. Private memory receives full TDX protections. Its content is protected @@ -107,7 +302,7 @@ entries. This helps ensure that a guest does not place sensitive information in shared memory, exposing it to the untrusted hypervisor. #VE on Shared Memory --------------------- +~~~~~~~~~~~~~~~~~~~~ Access to shared mappings can cause a #VE. The hypervisor ultimately controls whether a shared memory access causes a #VE, so the guest must be @@ -127,7 +322,7 @@ be careful not to access device MMIO regions unless it is also prepared to handle a #VE. #VE on Private Pages --------------------- +~~~~~~~~~~~~~~~~~~~~ An access to private mappings can also cause a #VE. Since all kernel memory is also private memory, the kernel might theoretically need to @@ -145,7 +340,7 @@ The hypervisor is permitted to unilaterally move accepted pages to a to handle the exception. Linux #VE handler -================= +----------------- Just like page faults or #GP's, #VE exceptions can be either handled or be fatal. Typically, an unhandled userspace #VE results in a SIGSEGV. @@ -167,7 +362,7 @@ While the block is in place, any #VE is elevated to a double fault (#DF) which is not recoverable. MMIO handling -============= +------------- In non-TDX VMs, MMIO is usually implemented by giving a guest access to a mapping which will cause a VMEXIT on access, and then the hypervisor @@ -189,7 +384,7 @@ MMIO access via other means (like structure overlays) may result in an oops. Shared Memory Conversions -========================= +------------------------- All TDX guest memory starts out as private at boot. This memory can not be accessed by the hypervisor. However, some kernel users like device