From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 762E4C4321E for ; Fri, 2 Dec 2022 17:10:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 070166B0073; Fri, 2 Dec 2022 12:10:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0202C6B0074; Fri, 2 Dec 2022 12:10:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2B116B0075; Fri, 2 Dec 2022 12:10:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D47096B0073 for ; Fri, 2 Dec 2022 12:10:08 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 7B4C3A128C for ; Fri, 2 Dec 2022 17:10:08 +0000 (UTC) X-FDA: 80198004096.21.C243CBE Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf26.hostedemail.com (Postfix) with ESMTP id 227F014001A for ; Fri, 2 Dec 2022 17:10:06 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=eKwwYJhK; spf=pass (imf26.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670001007; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=s8Hb/ccaCeukoetdTAD7bfPIGyNSPcg82WsqLpnn7/E=; b=V7A/WHk+Z3hLi3i9P485LA8n1AXFTa+GqDPJMRZZmN6bw41e+OUz4bm9I2TwHYDwyoME9S DOY/GQSbu/dBqfR+7Vpj+CsxjgIrChnUJB3iQkqIVAEkcB2PTyzR6+SS01ClWuOnBrCr00 iEX8mZCapukR0E5ed/ML/K37bSJ1cQI= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=eKwwYJhK; spf=pass (imf26.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.20 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670001007; a=rsa-sha256; cv=none; b=OSl5B5U3tFPAM4jx29OOQcHUrPrxHv+7c9+B4ApiWxBV/rF7JSB0Yb4Z2j0HQPZ6zvv5BM mIShDHRu/S+BSceI/fR4tG3hUZXc1a7p+Q5FIZt3B1wYyBEFuOsFGC1zY9slFckP0QnqtI jQTjrv7+5sEBGVnZqq6/tNEqc5tLhcQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1670001007; x=1701537007; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Bc7pDOCSVt6BMMxZ2t1mYgmI78+hnoS9G21qkQu3Alg=; b=eKwwYJhKqJpbebjL2MWwc2CbeL1k5cNmKdit28iIIg8zSN6ZXB5iOzTN 31y/HIwtqbtyR47k8QRKN/gLsMR5wA5w9NyteiGKcqrXvq86PVjNzgBq2 9jLc+Le5WE3Hxm6ZXPGFcVxJLA9YVx7DyUD/NIlWYGCK4WyAPsoYtYVLo Fav/h+Bu49laiqH3gCELHYrC/Q/E60Bw920jLKpN/YYs3ttVyjP//H7/t 8K7cIfoDhSQ6s1BAHydsdcc7zk366XjndBFtC+i4q4tFaU6KYOPxWyoMp L8g0nbIv5SJk/3mXxsg14+EBl/+P1frZjJ6AggeOpTdC0peHJ55TQYAvb Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10548"; a="303602799" X-IronPort-AV: E=Sophos;i="5.96,213,1665471600"; d="scan'208";a="303602799" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2022 09:06:05 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10548"; a="675889323" X-IronPort-AV: E=Sophos;i="5.96,213,1665471600"; d="scan'208";a="675889323" Received: from rsnyder-mobl.amr.corp.intel.com (HELO [10.209.68.71]) ([10.209.68.71]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2022 09:06:04 -0800 Message-ID: <21b43adc-37aa-bac3-0615-4703438ea4a1@intel.com> Date: Fri, 2 Dec 2022 09:06:04 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v7 09/20] x86/virt/tdx: Get information about TDX module and TDX-capable memory Content-Language: en-US To: "Huang, Kai" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Cc: "Luck, Tony" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "kirill.shutemov@linux.intel.com" , "Christopherson,, Sean" , "Chatre, Reinette" , "pbonzini@redhat.com" , "linux-mm@kvack.org" , "Yamahata, Isaku" , "peterz@infradead.org" , "Shahar, Sagi" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" References: <850e0899-d54e-6a49-851e-56f4d353905c@intel.com> <8f3b1492aefc37f6bdcd8a10051af57c7deb4430.camel@intel.com> From: Dave Hansen In-Reply-To: <8f3b1492aefc37f6bdcd8a10051af57c7deb4430.camel@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-5.25 / 9.00]; BAYES_HAM(-4.35)[96.05%]; DMARC_POLICY_ALLOW(-0.50)[intel.com,none]; R_SPF_ALLOW(-0.20)[+ip4:134.134.136.20/32]; R_DKIM_ALLOW(-0.20)[intel.com:s=Intel]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWELVE(0.00)[21]; DKIM_TRACE(0.00)[intel.com:+]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[] X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 227F014001A X-Stat-Signature: czjsiipsgkd6qt8nwfoytgah85o17ajo X-HE-Tag: 1670001006-404507 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000026, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 12/2/22 03:11, Huang, Kai wrote: > And also to address you concern that not all 892 bytes are reserved, how about > below: > > union { > - struct cpuid_config cpuid_configs[0]; > - u8 reserved5[892]; > + DECLARE_FLEX_ARRAY(struct cpuid_config, cpuid_configs); > + u8 padding[892]; > }; > } __packed __aligned(TDSYSINFO_STRUCT_ALIGNMENT); > > The goal is to make the size of 'struct tdsysinfo_struct' to be 1024B so we can > use a static variable for it, and at the meantime, it can still have 1024B > (enough space) for the TDH.SYS.INFO to write to. I just don't like the open-coded sizes. For instance, wouldn't it be great if you didn't have to know the size of *ANYTHING* else to properly size the '892'? Maybe we just need some helpers to hide the gunk: #define DECLARE_PADDED_STRUCT(type, name, alignment) \ struct type##_padded { \ union { \ struct type name; \ u8 padding[alignment]; \ } \ } name##_padded; #define PADDED_STRUCT(name) (name##_padded.name) That can get used like this: DECLARE_PADDED_STRUCT(struct tdsysinfo_struct, tdsysinfo, TDSYSINFO_STRUCT_ALIGNMENT); struct tdsysinfo_struct sysinfo = PADDED_STRUCT(tdsysinfo)