Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp7654568rwb; Wed, 23 Nov 2022 09:05:43 -0800 (PST) X-Google-Smtp-Source: AA0mqf6Frh8WvheKrj8DltzcDKDMTMizR2zKvasjy9fMptW7GGTEqa4vJR7Dhj8cLoulboV1FM0f X-Received: by 2002:a17:902:bd83:b0:17d:6603:8e45 with SMTP id q3-20020a170902bd8300b0017d66038e45mr13064476pls.173.1669223143249; Wed, 23 Nov 2022 09:05:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669223143; cv=none; d=google.com; s=arc-20160816; b=IhKglGlIqLnQSdo8S1+gyh9FbO2oArAdaMlhC5ELXoitZUwWBRJUPZ0SxAUKIgl2pI JU7CSGKcScnx1jSsQrYEbgvxcZHdyuJYRNTvIf06t4xKjTjf18DWMiYjXeEkQyFCHHaS Gz/qAGE1u9PK+sYpUEwZJjoMhF2MrpijNBDwnE7etrBUsRBeqSLaKOFtpCwNpLhq3EO9 SqlPdh0Dkk8IFpEt6VU/XdtHs4krQpKfa7FvegKAEU4d9RwigbDL8PC8C5G3CEORCoxH eN5tbR5veAEnQHoKHSw9rmdSqXTNtxibsG71M0Nlt0fi/BvERIyUbUHWc8h3ll+WAD+r TxRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=5bu3vmLVt0ICgDGwRDh8Trw8QnjwYIcPcMH/z2FtrgY=; b=wgRO1yzRnO+wsoc1PviF3vt/5asSdZVhIGhsJb2BMV410CSMqp3s6m74/Ym0LsMFXG IEtqyj6plzPvifSrWJso47VC4ycWxknwykIu3snXvqb4BleS+YZ15FLdsV1HtZFrLPB0 PeFGYdwuLsdAny3h38/LRDbiAyKOWvALhbB8faC1HerkQq9CLhXlTaqxfjlqrcuFE8MS N2g6vdY80/bJeZ48udMDKXEStL0gYemzOJqqKa/FWt1o80GCXhDX0EXuaS701CREsQIF XR59mVSmav3IZpu3J8K8DXe1wvlNswS7TgDpQFyF4QVo5BZOOAfCdYPqdZ2tQdIrrmv6 y1mA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=GxPx15yh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w6-20020a63f506000000b004700a4a4a29si17593742pgh.663.2022.11.23.09.05.29; Wed, 23 Nov 2022 09:05:43 -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=GxPx15yh; 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 S236923AbiKWQ7D (ORCPT + 88 others); Wed, 23 Nov 2022 11:59:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48980 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238060AbiKWQ67 (ORCPT ); Wed, 23 Nov 2022 11:58:59 -0500 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 947C368C61; Wed, 23 Nov 2022 08:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669222738; x=1700758738; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=6G5Mp68iqToBzIfY887gjlmXUVBeK2AFrXb5/cTUWOM=; b=GxPx15yhGJ7DjkxBslg/oBJbdRGNjMONTPKm2JELNlPOj0fG3Mp7Y0iL N1ctCOWHfqG3dmr3LniP1QpEt1lqk85V9qZ6m1Cpjp6Unx9YOiozXHOEI GeNLedfM3sbPpggSx+lOgXcrSPY7xv8eYgn3yY6apiAt0cQPTrbNh3Xla Xz5o782orDMFcL49LInGuKMe0ipvyoEbZnSgWeSylIFDitxQHLU846e3f y7z9IzS39fQAGFJwmGgGCcBox+SBPQoeqXgimH1Z0Yv3EAQoRatbVWgIb SXkOxu+02Cp96sPfiM5C7ShqEGqPhTaKcswu/xcKsyU2/RLr4oKcVCIZf Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10540"; a="378370369" X-IronPort-AV: E=Sophos;i="5.96,187,1665471600"; d="scan'208";a="378370369" 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 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,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/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.