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 DCC8AC433FE for ; Wed, 23 Nov 2022 16:59:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 669616B0071; Wed, 23 Nov 2022 11:59:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 619CC6B0073; Wed, 23 Nov 2022 11:59:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 509A16B0074; Wed, 23 Nov 2022 11:59:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 418576B0071 for ; Wed, 23 Nov 2022 11:59:01 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 07D8A1602E0 for ; Wed, 23 Nov 2022 16:59:01 +0000 (UTC) X-FDA: 80165316882.13.5700751 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf06.hostedemail.com (Postfix) with ESMTP id E2667180004 for ; Wed, 23 Nov 2022 16:58:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669222740; x=1700758740; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=6G5Mp68iqToBzIfY887gjlmXUVBeK2AFrXb5/cTUWOM=; b=eqV4hoOIFRrA3QyNKs2lu9kb6wh/1gT1xf0VyVaDvcO/YMEOFgqZP2V3 NxI8iCF4KUxhTUgLlTonpFQ36tPRm+ypI1gzVyqrUkf6bzJUBda9LYkYH 3jQ2rLL35GdfixLwIDVJnJfHudYYTGrbi1/Twa32DCLaz6LgJLr0H9bQJ /fZbHuL+Py03hAPdQO/v8zoChGzZACUUBepG3wi8XxY1wHwHsPDU/RVOE phczRqZPZx6gc2qYEmwlSAQYgbWoNoraeTBnTzqASLwm7taRuTfkbrvPE Yhv7jGfnfQ6podZuEcWFDGjscJNWzMpcN27fX9wsUL38pHcoSpvC/wDhu Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10540"; a="378370368" X-IronPort-AV: E=Sophos;i="5.96,187,1665471600"; d="scan'208";a="378370368" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Nov 2022 08:58:57 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10540"; a="674786756" X-IronPort-AV: E=Sophos;i="5.96,187,1665471600"; d="scan'208";a="674786756" Received: from vcbudden-mobl3.amr.corp.intel.com (HELO [10.212.129.67]) ([10.212.129.67]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Nov 2022 08:58:57 -0800 Message-ID: Date: Wed, 23 Nov 2022 08:58:56 -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 04/20] x86/virt/tdx: Add skeleton to initialize TDX on demand 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: From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=eqV4hoOI; spf=pass (imf06.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669222740; a=rsa-sha256; cv=none; b=mv+XBbG7Kr7PxqoHvCadPkHvLwySBwGZt+AiJ7yGCYZKkOPVaan1dTzNRpGWgHEiq3GuBB SUbDzkQUgha7BF/fQK6PANxESDJTrNAR8Tfu2zb/VbJbLIzsUbtk/9ZbsUrv1owSMpK1XJ dQlkQ3mf0MadWZZkIfsgAXWH7yhQPqY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669222740; 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=5bu3vmLVt0ICgDGwRDh8Trw8QnjwYIcPcMH/z2FtrgY=; b=Cg38ZrsxPZq5AqCbX/8ceQujFTYfTc1DqCedKB6eBfrrK2yphA4hyL2WP04Ja4zx+jnatr cEIH74hVfXaQQQziJBd2hAauLKG9FT6wE/OTVbAr6NwaaA//WiVtMkbRVdzIK63qSvMuLc PquJWXXgzph+6xbyvRi5Yk92OdsZuag= X-Stat-Signature: eeh8a9zd6crmkyf7ssndbrc6rhib87yf X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: E2667180004 Authentication-Results: imf06.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=eqV4hoOI; spf=pass (imf06.hostedemail.com: domain of dave.hansen@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-HE-Tag: 1669222739-783063 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 11/23/22 02:18, Huang, Kai wrote: >> Again, there are a lot of words in that comment, but I'm not sure why >> it's here. Despite all the whinging about ACPI, doesn't it boil down to: >> >> The TDX module itself establishes its own concept of how many >> logical CPUs there are in the system when it is loaded. >> > This isn't accurate. TDX MCHECK records the total number of logical CPUs when > the BIOS enables TDX. This happens before the TDX module is loaded. In fact > the TDX module only gets this information from a secret location. Kai, this is the point where I lose patience with the conversation around this series. I'll you paste you the line of code where the TDX module literally "establishes its own concept of how many logical CPUs there are in the system": > //NUM_LPS > tdx_global_data_ptr->num_of_lps = sysinfo_table_ptr->mcheck_fields.tot_num_lps; Yes, this is derived directly from MCHECK. But, this concept is separate from MCHECK. We have seen zero actual facts from you or other folks at Intel that this is anything other than an arbitrary choice made for the convenience of the TDX module. It _might_ not be this way. I'm open to hearing those facts and changing my position on this. But, please bring facts, not random references to "secret locations" that aren't that secret.