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 41604C7EE23 for ; Thu, 8 Jun 2023 13:15:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF35E6B0072; Thu, 8 Jun 2023 09:15:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A7C656B0074; Thu, 8 Jun 2023 09:15:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F5EA8E0001; Thu, 8 Jun 2023 09:15:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7CEF66B0072 for ; Thu, 8 Jun 2023 09:15:11 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3882312022A for ; Thu, 8 Jun 2023 13:15:11 +0000 (UTC) X-FDA: 80879626422.09.395D903 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf02.hostedemail.com (Postfix) with ESMTP id A04978001E for ; Thu, 8 Jun 2023 13:15:07 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=OhzjBAD0; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf02.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686230108; 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=X1Tim7U/CKApAgIPkim6R/86N8bDxWng+p7j6BKc4BQ=; b=Y6KHbTrioIGsl3XaN4Hd322WGBmmpJNzntEYGrD68GicoYVQZKy9isCuHvd30xeXKSXFOo FchS9t+GlloJjkGTUcNat/n6PU0UiK3oNFyJPgkSOzXBnx6eknUWT2p2uqmKtH/I3g9Q8L uxh0q860yPPt/BYSss4JClQAhq3Iq2g= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=OhzjBAD0; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf02.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.151 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686230108; a=rsa-sha256; cv=none; b=ODeLFcDO18S/ES4bUDVn2xg83PC1iP7U5+I3V6X5xogN2MK0oITHhTRCKv/i/vYaxL+1Wp BHwxtvEtfZnDw/jrA+lYbpz/UbR6ue3ANRO0p+WhttsjLEmK1epzNuKYh98vvOX9BgE6Sd 25i245LRNBM8iScZ/oUdugJXBijUHJE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686230107; x=1717766107; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=a3E93K6hoxZKC9yt31Lu/vhy/OxQU5XWodnX5xa9HOg=; b=OhzjBAD0TBW4yPtVM9pY/oPF+A0DK2WlNg6YVoQcuetZxKHNs2ZN5J/q ZFQjSyt+xiP3LowKc+DBF3b7wh5DanvZC0QYVA6/tuwarfk2SOnXNaAt3 KHikei7miNrnrMMy8eugHeYdZDEUMrlCtCc/5cMXK96zIIJzgEnIzpEIG IDz65Beqwags9ZbTQ4qvzrZKYSpJdrDYXLJkBOi0PkuyYcyslbFtgp3dV dmM/o3sDv9CBYSf/jStc104Nn4eypeAZHnpVBzvtZUAzPzrEyqYJuwpEy HDZx70YtNG5MKAr2h+ctz0dP+Rb/kiAdcA6T07e7N1vpYrto6O3zFECZR Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10734"; a="337660732" X-IronPort-AV: E=Sophos;i="6.00,226,1681196400"; d="scan'208";a="337660732" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2023 06:11:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10734"; a="854335641" X-IronPort-AV: E=Sophos;i="6.00,226,1681196400"; d="scan'208";a="854335641" Received: from swalker-mobl1.amr.corp.intel.com (HELO [10.209.22.184]) ([10.209.22.184]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2023 06:11:18 -0700 Message-ID: <201af662-f700-9145-c113-563e378074ad@intel.com> Date: Thu, 8 Jun 2023 06:11:17 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v11 11/20] x86/virt/tdx: Fill out TDMRs to cover all TDX memory regions Content-Language: en-US To: "Huang, Kai" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Cc: "Luck, Tony" , "david@redhat.com" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "kirill.shutemov@linux.intel.com" , "Chatre, Reinette" , "Christopherson,, Sean" , "pbonzini@redhat.com" , "tglx@linutronix.de" , "Yamahata, Isaku" , "linux-mm@kvack.org" , "peterz@infradead.org" , "Shahar, Sagi" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" References: <927ec9871721d2a50f1aba7d1cf7c3be50e4f49b.1685887183.git.kai.huang@intel.com> <0600959d-9e10-fb1f-b3a9-862a51b9d8e1@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A04978001E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: xuchj6gikkr9bx1goss67drmbqc8soa5 X-HE-Tag: 1686230107-776652 X-HE-Meta: U2FsdGVkX18PHoAAvvLOHeGE34H9BRqjIJKFGXN9tuJjK/TGVe5SYeTK6zVCqe9PMEQ8etYIN/LYZoZw8Dyapq5+u0bwPVwflBiJ9uT8Nl1ASA9Ke+87WA8MyjP3qlD2ZZSmAiYv8eH2Xs8x2B/+r6w3D9UV5Ct/fpBNXPE9c2719IS99K9d2DPHNPmSPJp8wgrDpqH1DRTyeBJEB+3PL58yw/mkfKLqo0GJ7GFXE6VbOZ6XM/XpqtKfnpRP9bPGyJZo5TxFgUTiYNcRE1BboU5jOPuMHnMyl59B6tUmUY0NFj+/PZ4L3/MWgTPSOnGgTkqK1Rtv9H8gaInvFsjelVOOtDo34AxB3mnyfSgOSAD9h2X0jc7OQZxD7gMgpJP17O6Y+emwmYrp3zW/cQgshmzQrsVziPJY2syYsj2idAGDw46u83z7xK7+Ldze47CglIdmzIZGR3OynICc+EmnoRcoFYSo3Glc5xrqIEMjfyuZnPEyxvD3Mm5a6zlGIIqzWXxDepCP0cvGxdrzTC8qt+Jw8nt+8Rye6kPZAi0gxOF8Hehwx6TcH/MvDUrW9HYgD6hECrEEFs+qzJpr2i2JKDm274tSb7stpUHoc/EeqTttS4WMJ1Ds4yKAltnbflSIUuW+qedFh/An8trQAGzYSAeqYSxBkX2wk/9DI7zohUFp5z+uACtVKYTL71NSqGJIix0VoL/cSdMHJY6Kvv8shRFukYI+NYDJsovy19EC5ELvGA0/qOEtp/dzqZPr+Of2tL3zIAR8xH8nrrxO6fWaYb2nx2tZ/+B8QQ2mJS/TZX/Q+McrjnSf+HQfaujN5NlrXpLUCzTNAu1m1O7Oa54kr57pn49EVHNYFppcErnVvptqSCcn+Y2TF20I8xucAUkyIrn75mTTen1aIB70V/kaFANH0Ko62gywAp6ybq3+ZtTOXXgOmZWxCP+zv0MI+mTmaqpztSR8u/cQFVJ+scr vikYSVDW xv5mGppD1utWRHyEYQhb9h5d2z2OwOOjNKsQGkyIAMZAuXk2Ye66NnDTZpG12oMHIXTEnxhavVsbp9YDTtjzF3Fv0VvyiKdDNm0LzSihl3nZOgjOZcWlov41+mggn8QlweJGsi/EqZNOe8pm95IAt1b3mvrre/ZnC0WPPhnkskNmHwPI9+wyOypiWQw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000088, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 6/8/23 03:48, Huang, Kai wrote: >> Let's also put a pr_warn() in here if we exceed, say 1/2 or maybe 3/4 of >> the 64. We'll hopefully start to get reports somewhat in advance if >> systems get close to the limit. > May I ask why this is useful? TDX module can only be initialized once, so if > not considering module runtime update case, the kernel can only get two results > for once: > > 1) Succeed to initialize: consumed TDMRs doesn't exceed maximum TDMRs > 2) Fail to initialize: consumed TDMRs exceeds maximum TDMRs > > What's the value of pr_warn() user when consumed TDMRs exceeds some threshold? Today, we're saying, "64 TMDRs out to be enough for anybody!" I'd actually kinda like to know if anybody starts building platforms that get anywhere near using 64. That way, we won't get a bug report that TDX is broken and we'll have a fire drill. We'll get a bug report that TDX is complaining and we'll have some time to go fix it without anyone actually being broken. Maybe not even a pr_warn(), but something that's a bit ominous and has a chance of getting users to act.