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 0AA2EC63797 for ; Tue, 10 Jan 2023 15:19:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91D9E8E0003; Tue, 10 Jan 2023 10:19:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A7018E0001; Tue, 10 Jan 2023 10:19:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 720D58E0003; Tue, 10 Jan 2023 10:19:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 5B79A8E0001 for ; Tue, 10 Jan 2023 10:19:54 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 07781160DF7 for ; Tue, 10 Jan 2023 15:19:54 +0000 (UTC) X-FDA: 80339249508.28.84C825A Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf30.hostedemail.com (Postfix) with ESMTP id 7859B80012 for ; Tue, 10 Jan 2023 15:19:49 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=I9KwFVdm; spf=pass (imf30.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=1673363991; 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=3KOFsqY6KXL32YQM9I5xNA3gfpI5UtsDadk/sMobim4=; b=367Rv7pxSrcK2PpJGzlgBgPAshp31LtRC6J9A6XwxiClUPVUw3moFaOZvnCnA8+M9nU6jj XN4FywQKkS8Nu6W+wU0s+IVgwtuRzssA61zEDOooFUCAyJvt4L16/w8ix9M4HPo8EJnwhE h0zFzEsjsWODoxyrI5etJq9hLN0lBCw= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=I9KwFVdm; spf=pass (imf30.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=1673363991; a=rsa-sha256; cv=none; b=CAbHD1C1BEbEt2Pi1IqyyVdUBZedo/yp1qnmUnEDoTVUf5uREoaZfs/f8Kla+ATeszOClK VxCeSzmLVVbLIG1ToNNuJUzbAyLn19JOUOg1LBApK6kyF9RFIjpbzbW7ZqIVLRBi21Z9U3 RfARduhFZZA84pnmh7IEPLbiomulrSc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673363989; x=1704899989; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=19LiZ+HqQL5Doh9UbMQEiLpyHqyJB3yalB7IXIegZGI=; b=I9KwFVdmnzhXlyoKFOLxbUWZI05whTK/ChzVSevv0dG/ST4RLkRe2zw4 gRyPfijikbU0XXY5we5BbSnLq15+CP+5Jyb2GUfvd5v5qfJflN1C0sz+V sK5ultm+WvnlecEdUJYc3TOZIFdLjZoVEAyCmSh2Q3+5awZd0Pr5/ZRQF Pq87kM7c00ahXQDfYR7MwxD4fF38DjUjWB8wbd1VzeLqDTiKj1MmtjPv+ 2MGsehgjvPOi7zvrX4HbrNoJHgkyP7IXVZ5kLg68AAcMZ9vMaXxml1wbc Cpyl4+ANhGxHITSIGvl2V6I6E7itNavbnli5LKhTxSYkUvbl4kx2yG3sJ A==; X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="310969211" X-IronPort-AV: E=Sophos;i="5.96,315,1665471600"; d="scan'208";a="310969211" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jan 2023 07:19:47 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="657088890" X-IronPort-AV: E=Sophos;i="5.96,315,1665471600"; d="scan'208";a="657088890" Received: from svenka7-mobl1.amr.corp.intel.com (HELO [10.209.63.27]) ([10.209.63.27]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jan 2023 07:19:47 -0800 Message-ID: <3bfe283e-6a90-54cb-1ba2-45ce6d022206@intel.com> Date: Tue, 10 Jan 2023 07:19:46 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v8 11/16] x86/virt/tdx: Designate reserved areas for all TDMRs 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" , "tglx@linutronix.de" , "Shahar, Sagi" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "peterz@infradead.org" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" References: <27dcd2781a450b3f77a2aec833de6a3669bc0fb8.1670566861.git.kai.huang@intel.com> <2d7d2824-7aa7-5f96-d79b-b44ff7fe2ef9@intel.com> <778a6c80-a955-620d-a82a-c2ca82f26363@intel.com> <24ea02aa4db7d470adeb7a64b7692d8bd5a428ca.camel@intel.com> From: Dave Hansen In-Reply-To: <24ea02aa4db7d470adeb7a64b7692d8bd5a428ca.camel@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 7859B80012 X-Rspam-User: X-Stat-Signature: wurxa41xbw3xu47z66ys3hi73zk33r6r X-HE-Tag: 1673363989-69195 X-HE-Meta: U2FsdGVkX19FMnAsig2sw0cckRRjHB13xzodncLr0xOQ4OYkOaqplYXP4k8UUBb40+rMSnlMO2ok1an7QOxydV/lqS9WEekHSORkNfYyxlN9UNqm7xyAA7WxgJNfVVs0WztGgraKFa4JsvAk5N/JTGvej4aN+kUmwGUqz0qFKKHgE4Z1ople1zKehzkzTp8kHhCQq+XoGPj2qwOrgBFl9mBOySOUCIRPlFfdf6tW/fUL+NUPHnUnYAakLwQP/Rk8tPwBGHK0NxTwY2au/EDaI7dW9O+3BCQVSAjFkgRi/DYfhuXGaP+pM9qCyjGAoLI5MIYLW3cKnOJKHjQuTbVBwkF/zkRTRmKTEuuV5XkemqLxUdbqAdpnGKzsV49gwlgWh3ysbB5kpx4t6I6aFfkINLWaL+UObK+Bx6cJvpDiV/OrjQ93HwtQHD23HNpP6ZrJKYU9xWBgA5h5wmj3d3xjw6jx5T1wuN5MqheX1Y5x+c04RaFQ/OQWxo/xizwNZp7zEo3273xPSHMM0t8GCLOKf8QieuQYNDV/Bkrwew4pNaT8TiuI/EEQgyF6gew8LELXM5Y+ntbiL5hPdGFzd7hXN9wWZdOiYQz3382XauJIAh9QXYwvP7E2k05s+LI2BiIUrYw0ySoL5XuLHfp25y7rdve6jo2kYTWECkvq7tC6MO5wqXksM7ROvljnwqMjBJYmH4xbf4vHMSG0fTbrnQhIf5w1pKri9wR8Aw1l/RjITfW3EElBbfhwxh2Efq5WpwAm23REeJV6hXz0gLYspA6Mt9LCwQ4l6c1kOBLLxyBsyE4PHp8UX+AUAqlXOaA3QQf3gGjfZ/A4rThO0vvR52NXkKPduO1hxJAwKmQyG299kGS+JHjZVEha4RkXRpyvy5zyXT1xsYswclOf9Zcz3UnlAw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.017339, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 1/10/23 03:01, Huang, Kai wrote: > On Mon, 2023-01-09 at 17:22 -0800, Dave Hansen wrote: >> On 1/9/23 17:19, Huang, Kai wrote: >>>> It's probably also worth noting *somewhere* that there's a balance to be >>>> had between TDMRs and reserved areas. A system that is running out of >>>> reserved areas in a TDMR could split a TDMR to get more reserved areas. >>>> A system that has run out of TDMRs could relatively easily coalesce two >>>> adjacent TDMRs (before the PAMTs are allocated) and use a reserved area >>>> if there was a gap between them. >>> We can add above to the changelog of this patch, or the patch 09 ("x86/virt/tdx: >>> Fill out TDMRs to cover all TDX memory regions"). The latter perhaps is better >>> since that patch is the first place where the balance of TDMRs and reserved >>> areas is related. >>> >>> What is your suggestion? >> Just put it close to the code that actually hits the problem so the >> potential solution is close at hand to whoever hits the problem. >> > Sorry to double check: the code which hits the problem is the 'if (idx >= > max_reserved_per_tdmr)' check in tdmr_add_rsvd_area(), so I think I can add > right before this check? Please just hack together how you think it should look and either reply with an updated patch, or paste the relevant code snippet in your reply. That'll keep me from having to go chase this code back down.