Message ID | 344234642a5eb9dc1aa34410f641f596ec428ea5.1668988357.git.kai.huang@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp1323228wrr; Sun, 20 Nov 2022 16:31:27 -0800 (PST) X-Google-Smtp-Source: AA0mqf4FKuNgcOHV3hObZ6A79aYwZc5S7t/G+SVpiqTJ5LMvJc76AY72rCJXa+IkCmoGWxWZP9AR X-Received: by 2002:a63:110d:0:b0:46e:bcc1:28df with SMTP id g13-20020a63110d000000b0046ebcc128dfmr15323716pgl.187.1668990687560; Sun, 20 Nov 2022 16:31:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668990687; cv=none; d=google.com; s=arc-20160816; b=jn1AkRlANgpaFa4WVACEzSBp+tidcXGDe2asSGQ10MYvT8ZX2UVPWZnf/TxD53yqET P8E94e4/AxrgOg23oOngeMtn9ceFldMqBpQ3SEOpmCndgXLSeOF/NcBhhDzYdB8LVXQM UDedK08t81JpgwAZdxkiT3v1JAr/vPnbXiWB6eEAjrw5iiQ40a0+Gt8o3cCOc8usG6xb 2Mk7xVsnSOjGG2155729ebFIn8vZrp6DqMx902l3WDgw2WR+oWhyDRWGaCwMucqHDXi4 e82BZ+VPoLRorYWfNsgJPeWYWKQ3E+CiSrBdHKbWV5s1PT3oLooMggLwYpPSd9l2dQ6c lE0w== 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=tmJYBtyDZ7or73XyG1rgNnlZS36N1OabISvnADKu2Gk=; b=YPjqfNUTDyGPPbfuyfoZ0W3WSKCcKS6jmOg4X68P8bSKImHKIBE8FHDQoNOxlm5pRJ uBK7niX2rYGCaqA65e6nusi+GCgwB+4HTlPVCYz2nnE/RIhpE3ClwOReJv9vVn+S2UGE I1akqffvmBfPx3wGrU1glLOfSzdW3RcpUedOKQS9WOyCtgoSI9p3JsOPRR4eu8JlmEuE Hn5aPMEiBQzkHoo/pgt0EE7AR2VTvk5ienAesftevO89ndQXf4uL6h8gayJN8Xgr2buZ KAkeI6MHasUc/K/Y/vaxdzl0ibSypZ9pJLQ2phWEf0MvgcXRUcmaYl/nHxeznbxRxKXf fBVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=M0Aj5Qrc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s1-20020a170902c64100b001870464adb6si8553294pls.183.2022.11.20.16.31.11; Sun, 20 Nov 2022 16:31:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=M0Aj5Qrc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229997AbiKUAak (ORCPT <rfc822;leviz.kernel.dev@gmail.com> + 99 others); Sun, 20 Nov 2022 19:30:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229978AbiKUAaT (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 20 Nov 2022 19:30:19 -0500 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 30CE66A693; Sun, 20 Nov 2022 16:28:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1668990532; x=1700526532; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=UBAtxkoUHDLhrJ6Ir/h/0EBfmIyd0UUVQOxLVLHPC58=; b=M0Aj5QrcALu7z12Di0o4q8ex3qwTkai9hCfK/LwRCCNKBw0QzJd9lb2/ QPi9Bnt6hs/z/gEeejH08PuRVRg23ClkroYbYIKw4uZ3hbVfSny6CrVrG Avw4ibiDzjnrH/nijc5oTMwrqo6j9gfAIz5W/GM0s0lLt2oLsiqe+OYqE HjtZ/vA4f2pR9WWHyf58Xu3KaXitadFMDlwqJo692xgoltsOBlZ3483Ea 8yG1/+epNuPxPPuLYbO5Aeze+nI4kPw+ZNtqw+xxkECCN69qfAxyTsG+w SWQu6c9dX7jG5WEBLNcRUST4LqK5b9M2Qb46KxB4tXA2ndyB14RJCGqHc g==; X-IronPort-AV: E=McAfee;i="6500,9779,10537"; a="377705751" X-IronPort-AV: E=Sophos;i="5.96,180,1665471600"; d="scan'208";a="377705751" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Nov 2022 16:28:05 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10537"; a="729825519" X-IronPort-AV: E=Sophos;i="5.96,180,1665471600"; d="scan'208";a="729825519" Received: from tomnavar-mobl.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.209.176.15]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Nov 2022 16:28:00 -0800 From: Kai Huang <kai.huang@intel.com> To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: linux-mm@kvack.org, seanjc@google.com, pbonzini@redhat.com, dave.hansen@intel.com, dan.j.williams@intel.com, rafael.j.wysocki@intel.com, kirill.shutemov@linux.intel.com, ying.huang@intel.com, reinette.chatre@intel.com, len.brown@intel.com, tony.luck@intel.com, peterz@infradead.org, ak@linux.intel.com, isaku.yamahata@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com, kai.huang@intel.com Subject: [PATCH v7 16/20] x86/virt/tdx: Configure TDX module with TDMRs and global KeyID Date: Mon, 21 Nov 2022 13:26:38 +1300 Message-Id: <344234642a5eb9dc1aa34410f641f596ec428ea5.1668988357.git.kai.huang@intel.com> X-Mailer: git-send-email 2.38.1 In-Reply-To: <cover.1668988357.git.kai.huang@intel.com> References: <cover.1668988357.git.kai.huang@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750063579075793938?= X-GMAIL-MSGID: =?utf-8?q?1750063579075793938?= |
Series |
TDX host kernel support
|
|
Commit Message
Kai Huang
Nov. 21, 2022, 12:26 a.m. UTC
After the TDX-usable memory regions are constructed in an array of TDMRs and the global KeyID is reserved, configure them to the TDX module using TDH.SYS.CONFIG SEAMCALL. TDH.SYS.CONFIG can only be called once and can be done on any logical cpu. Reviewed-by: Isaku Yamahata <isaku.yamahata@intel.com> Signed-off-by: Kai Huang <kai.huang@intel.com> --- arch/x86/virt/vmx/tdx/tdx.c | 37 +++++++++++++++++++++++++++++++++++++ arch/x86/virt/vmx/tdx/tdx.h | 2 ++ 2 files changed, 39 insertions(+)
Comments
On 11/20/22 16:26, Kai Huang wrote: > After the TDX-usable memory regions are constructed in an array of TDMRs > and the global KeyID is reserved, configure them to the TDX module using > TDH.SYS.CONFIG SEAMCALL. TDH.SYS.CONFIG can only be called once and can > be done on any logical cpu. > > Reviewed-by: Isaku Yamahata <isaku.yamahata@intel.com> > Signed-off-by: Kai Huang <kai.huang@intel.com> > --- > arch/x86/virt/vmx/tdx/tdx.c | 37 +++++++++++++++++++++++++++++++++++++ > arch/x86/virt/vmx/tdx/tdx.h | 2 ++ > 2 files changed, 39 insertions(+) > > diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c > index e2cbeeb7f0dc..3a032930e58a 100644 > --- a/arch/x86/virt/vmx/tdx/tdx.c > +++ b/arch/x86/virt/vmx/tdx/tdx.c > @@ -979,6 +979,37 @@ static int construct_tdmrs(struct tdmr_info *tdmr_array, int *tdmr_num) > return ret; > } > > +static int config_tdx_module(struct tdmr_info *tdmr_array, int tdmr_num, > + u64 global_keyid) > +{ > + u64 *tdmr_pa_array; > + int i, array_sz; > + u64 ret; > + > + /* > + * TDMR_INFO entries are configured to the TDX module via an > + * array of the physical address of each TDMR_INFO. TDX module > + * requires the array itself to be 512-byte aligned. Round up > + * the array size to 512-byte aligned so the buffer allocated > + * by kzalloc() will meet the alignment requirement. > + */ Aagh. Return of (a different) 512-byte aligned structure. > + array_sz = ALIGN(tdmr_num * sizeof(u64), TDMR_INFO_PA_ARRAY_ALIGNMENT); > + tdmr_pa_array = kzalloc(array_sz, GFP_KERNEL); Just to be clear, all that chatter about alignment is because the *START* of the array has to be aligned. Right? I see alignment for 'array_sz', but that's not the start of the array. tdmr_pa_array is the start of the array. Where is *THAT* aligned? How does rounding up the size make kzalloc() magically know how to align the *START* of the allocation? Because I'm actually questioning my own sanity at this point, I went and double-checked the docs (Documentation/core-api/memory-allocation.rst): > The address of a chunk allocated with `kmalloc` is aligned to at least > ARCH_KMALLOC_MINALIGN bytes. For sizes which are a power of two, the > alignment is also guaranteed to be at least the respective size. Hint #1: ARCH_KMALLOC_MINALIGN is way less than 512. Hint #2: tdmr_num is not guaranteed to be a power of two. Hint #3: Comments don't actually affect the allocation <snip>
On Wed, 2022-11-23 at 15:56 -0800, Dave Hansen wrote: > On 11/20/22 16:26, Kai Huang wrote: > > After the TDX-usable memory regions are constructed in an array of TDMRs > > and the global KeyID is reserved, configure them to the TDX module using > > TDH.SYS.CONFIG SEAMCALL. TDH.SYS.CONFIG can only be called once and can > > be done on any logical cpu. > > > > Reviewed-by: Isaku Yamahata <isaku.yamahata@intel.com> > > Signed-off-by: Kai Huang <kai.huang@intel.com> > > --- > > arch/x86/virt/vmx/tdx/tdx.c | 37 +++++++++++++++++++++++++++++++++++++ > > arch/x86/virt/vmx/tdx/tdx.h | 2 ++ > > 2 files changed, 39 insertions(+) > > > > diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c > > index e2cbeeb7f0dc..3a032930e58a 100644 > > --- a/arch/x86/virt/vmx/tdx/tdx.c > > +++ b/arch/x86/virt/vmx/tdx/tdx.c > > @@ -979,6 +979,37 @@ static int construct_tdmrs(struct tdmr_info *tdmr_array, int *tdmr_num) > > return ret; > > } > > > > +static int config_tdx_module(struct tdmr_info *tdmr_array, int tdmr_num, > > + u64 global_keyid) > > +{ > > + u64 *tdmr_pa_array; > > + int i, array_sz; > > + u64 ret; > > + > > + /* > > + * TDMR_INFO entries are configured to the TDX module via an > > + * array of the physical address of each TDMR_INFO. TDX module > > + * requires the array itself to be 512-byte aligned. Round up > > + * the array size to 512-byte aligned so the buffer allocated > > + * by kzalloc() will meet the alignment requirement. > > + */ > > Aagh. Return of (a different) 512-byte aligned structure. > > > + array_sz = ALIGN(tdmr_num * sizeof(u64), TDMR_INFO_PA_ARRAY_ALIGNMENT); > > + tdmr_pa_array = kzalloc(array_sz, GFP_KERNEL); > > Just to be clear, all that chatter about alignment is because the > *START* of the array has to be aligned. Right? > Correct. > I see alignment for > 'array_sz', but that's not the start of the array. > > tdmr_pa_array is the start of the array. Where is *THAT* aligned? The alignment is assumed to be guaranteed based on the Documentation you quoted below. > > How does rounding up the size make kzalloc() magically know how to align > the *START* of the allocation? > > Because I'm actually questioning my own sanity at this point, I went and > double-checked the docs (Documentation/core-api/memory-allocation.rst): > > > The address of a chunk allocated with `kmalloc` is aligned to at least > > ARCH_KMALLOC_MINALIGN bytes. For sizes which are a power of two, the > > alignment is also guaranteed to be at least the respective size. > > Hint #1: ARCH_KMALLOC_MINALIGN is way less than 512. > Hint #2: tdmr_num is not guaranteed to be a power of two. tdmr_num * sizeof(u64) is not guaranteed. > Hint #3: Comments don't actually affect the allocation Sorry I don't understand the Hint #3. Perhaps I should just allocate one page so it must be 512-byte aligned? /* * TDMR_INFO entries are configured to the TDX module via an array * of physical address of each TDMR_INFO. The TDX module requires * the array itself to be 512-byte aligned. Just allocate a page * to use it as the array so the alignment can be guaranteed. The * page will be freed after TDH.SYS.CONFIG anyway. */
On 11/24/22 16:59, Huang, Kai wrote: > On Wed, 2022-11-23 at 15:56 -0800, Dave Hansen wrote: >> On 11/20/22 16:26, Kai Huang wrote: >>> + array_sz = ALIGN(tdmr_num * sizeof(u64), TDMR_INFO_PA_ARRAY_ALIGNMENT); >>> + tdmr_pa_array = kzalloc(array_sz, GFP_KERNEL); >> >> Just to be clear, all that chatter about alignment is because the >> *START* of the array has to be aligned. Right? > > Correct. > >> I see alignment for >> 'array_sz', but that's not the start of the array. >> >> tdmr_pa_array is the start of the array. Where is *THAT* aligned? > > The alignment is assumed to be guaranteed based on the Documentation you quoted > below. I'm feeling kinda dense today, being Thanksgiving and all. Could you please walk me through, step-by-step how you get kzalloc() to give you an allocation where the start address is 512-byte aligned? ... > Perhaps I should just allocate one page so it must be 512-byte aligned? > > /* > * TDMR_INFO entries are configured to the TDX module via an array > * of physical address of each TDMR_INFO. The TDX module requires > * the array itself to be 512-byte aligned. Just allocate a page > * to use it as the array so the alignment can be guaranteed. The > * page will be freed after TDH.SYS.CONFIG anyway. > */ Kai, I just plain can't believe at this point that comments like this are still being written. I _thought_ I was very clear before that if you have a constant, say: #define FOO_ALIGN 512 and you want to align foo, you can just do: foo = ALIGN(foo, FOO_ALIGN); You don't need to mention the 512-byte alignment again. The #define is good enough.
On Thu, 2022-11-24 at 17:18 -0800, Dave Hansen wrote: > On 11/24/22 16:59, Huang, Kai wrote: > > On Wed, 2022-11-23 at 15:56 -0800, Dave Hansen wrote: > > > On 11/20/22 16:26, Kai Huang wrote: > > > > + array_sz = ALIGN(tdmr_num * sizeof(u64), TDMR_INFO_PA_ARRAY_ALIGNMENT); > > > > + tdmr_pa_array = kzalloc(array_sz, GFP_KERNEL); > > > > > > Just to be clear, all that chatter about alignment is because the > > > *START* of the array has to be aligned. Right? > > > > Correct. > > > > > I see alignment for > > > 'array_sz', but that's not the start of the array. > > > > > > tdmr_pa_array is the start of the array. Where is *THAT* aligned? > > > > The alignment is assumed to be guaranteed based on the Documentation you quoted > > below. > > I'm feeling kinda dense today, being Thanksgiving and all. Could you > please walk me through, step-by-step how you get kzalloc() to give you > an allocation where the start address is 512-byte aligned? Sorry I am not good at math. I forgot although 512 is power of two, n x 512 may not be power of two. The code works because in practice tdmr_num is never larger than 64 so tdmr_num * sizeof(64) cannot be larger than 512. So if want to consider array size being larger than 4K, we should use alloc_pages_exact() to allocate? > > ... > > Perhaps I should just allocate one page so it must be 512-byte aligned? > > > > /* > > * TDMR_INFO entries are configured to the TDX module via an array > > * of physical address of each TDMR_INFO. The TDX module requires > > * the array itself to be 512-byte aligned. Just allocate a page > > * to use it as the array so the alignment can be guaranteed. The > > * page will be freed after TDH.SYS.CONFIG anyway. > > */ > > Kai, I just plain can't believe at this point that comments like this > are still being written. I _thought_ I was very clear before that if > you have a constant, say: > > #define FOO_ALIGN 512 > > and you want to align foo, you can just do: > > foo = ALIGN(foo, FOO_ALIGN); > > You don't need to mention the 512-byte alignment again. The #define is > good enough. > > My fault. I thought by changing to allocate a page we don't need to do 'foo = ALIGN(foo, FOO_ALIGN)' so I thought the comment could be useful. Thanks for responding at Thanksgiving day.
diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index e2cbeeb7f0dc..3a032930e58a 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -979,6 +979,37 @@ static int construct_tdmrs(struct tdmr_info *tdmr_array, int *tdmr_num) return ret; } +static int config_tdx_module(struct tdmr_info *tdmr_array, int tdmr_num, + u64 global_keyid) +{ + u64 *tdmr_pa_array; + int i, array_sz; + u64 ret; + + /* + * TDMR_INFO entries are configured to the TDX module via an + * array of the physical address of each TDMR_INFO. TDX module + * requires the array itself to be 512-byte aligned. Round up + * the array size to 512-byte aligned so the buffer allocated + * by kzalloc() will meet the alignment requirement. + */ + array_sz = ALIGN(tdmr_num * sizeof(u64), TDMR_INFO_PA_ARRAY_ALIGNMENT); + tdmr_pa_array = kzalloc(array_sz, GFP_KERNEL); + if (!tdmr_pa_array) + return -ENOMEM; + + for (i = 0; i < tdmr_num; i++) + tdmr_pa_array[i] = __pa(tdmr_array_entry(tdmr_array, i)); + + ret = seamcall(TDH_SYS_CONFIG, __pa(tdmr_pa_array), tdmr_num, + global_keyid, 0, NULL, NULL); + + /* Free the array as it is not required anymore. */ + kfree(tdmr_pa_array); + + return ret; +} + /* * Detect and initialize the TDX module. * @@ -1062,11 +1093,17 @@ static int init_tdx_module(void) */ tdx_global_keyid = tdx_keyid_start; + /* Pass the TDMRs and the global KeyID to the TDX module */ + ret = config_tdx_module(tdmr_array, tdmr_num, tdx_global_keyid); + if (ret) + goto out_free_pamts; + /* * Return -EINVAL until all steps of TDX module initialization * process are done. */ ret = -EINVAL; +out_free_pamts: if (ret) tdmrs_free_pamt_all(tdmr_array, tdmr_num); else diff --git a/arch/x86/virt/vmx/tdx/tdx.h b/arch/x86/virt/vmx/tdx/tdx.h index a737f2b51474..c26bab2555ca 100644 --- a/arch/x86/virt/vmx/tdx/tdx.h +++ b/arch/x86/virt/vmx/tdx/tdx.h @@ -19,6 +19,7 @@ #define TDH_SYS_INIT 33 #define TDH_SYS_LP_INIT 35 #define TDH_SYS_LP_SHUTDOWN 44 +#define TDH_SYS_CONFIG 45 struct cmr_info { u64 base; @@ -86,6 +87,7 @@ struct tdmr_reserved_area { } __packed; #define TDMR_INFO_ALIGNMENT 512 +#define TDMR_INFO_PA_ARRAY_ALIGNMENT 512 struct tdmr_info { u64 base;