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 92B43C46467 for ; Wed, 11 Jan 2023 16:19:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F1A138E0001; Wed, 11 Jan 2023 11:19:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EC817900002; Wed, 11 Jan 2023 11:19:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1B5E8E0003; Wed, 11 Jan 2023 11:19:30 -0500 (EST) 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 C524E8E0001 for ; Wed, 11 Jan 2023 11:19:30 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A2E78A0648 for ; Wed, 11 Jan 2023 16:19:30 +0000 (UTC) X-FDA: 80343028500.16.A87FBE4 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf19.hostedemail.com (Postfix) with ESMTP id 2D3AA1A0024 for ; Wed, 11 Jan 2023 16:19:27 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=lkv0vdJj; spf=pass (imf19.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=1673453968; a=rsa-sha256; cv=none; b=xMTJKO8DSEOeQwrmgEOkEdm/A58zskcLha5tVjJYM/TODWNB0X00m17GSmPVk6juFVZSf7 D2iEaGCftNtsGHIKvh5jJPm8nXfYBSxk+5qS+kLOJNuNRG6BW2X5dm7lIOyrML/n2XiFhR FJ1aO5TLyJ/tmKoWz98xXB9zTyf0L6s= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=lkv0vdJj; spf=pass (imf19.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=1673453968; 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=U6YCuGfud/Xfp7rSvuIQSCooOL0BDpuCfrtg4EAwydI=; b=NkfZe/d0HQb4SR7PFEE67kYDd3UoXGgkwphS+oVFUHX6aEBjlWHvRK73/r/gu5Py+EINTW T7UofQ/QJUN7GoTR/aTNmB1oW4QEAhF5qNpPdnFgd7Z5mdmwQPVFa9Iyf5yLH/L+lZMYvV 5E9oJ5HKCJKzP8y7z8Cg67hvEOV2vQg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673453968; x=1704989968; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=iulAX5B5LcGBjvNPrRdZ2p5me0aPi4T1H+C2nWRMmDo=; b=lkv0vdJjm07Og0qWBIiapx4EESvxKx4WSgSYC/MTswNvQ5wvEQxg+oUP +uFCq7DbGsQOVDtO21lHXHNcHinav5eOJ4wz5P7XpvP8fjq9AO3qzNZWP tc1JGzqPrX+09P8XNWaqjWgyeuBxRRIp+SVfciYr+IjpCwu6JEC1zXf5I 6R/3zD2PBckgQSm84ZpsmyML/TeMI52mHRzi60rbRX/2IBbEwVeCDwYOk y9yjUzg4rgOVevbGtRtZmmKXZDzPjIJBFjzICMfJ/DEzALpYQE1z25rzS iqzvpINUfHiGvSsoW7WEVn40a/0EP0tA5gRP3TB7b61IKvFJrDSS+QqjD Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="311272194" X-IronPort-AV: E=Sophos;i="5.96,317,1665471600"; d="scan'208";a="311272194" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2023 08:16:38 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="765202756" X-IronPort-AV: E=Sophos;i="5.96,317,1665471600"; d="scan'208";a="765202756" Received: from pchoi7-mobl1.amr.corp.intel.com (HELO [10.212.194.225]) ([10.212.194.225]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jan 2023 08:16:36 -0800 Message-ID: <0293d72e-e03f-03d7-5982-29b4f11006a9@intel.com> Date: Wed, 11 Jan 2023 08:16:36 -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" , "peterz@infradead.org" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "Shahar, Sagi" , "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> <3bfe283e-6a90-54cb-1ba2-45ce6d022206@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 2D3AA1A0024 X-Rspamd-Server: rspam01 X-Stat-Signature: jsi6ry7sfsw74zm6hwfaumizppyofcfg X-HE-Tag: 1673453967-648778 X-HE-Meta: U2FsdGVkX1+CDqLv9hGM3EhqOdEnPuZLFSSir5OeU6bU3BDkFUAUPL8ce/cvLT7zDq2TB6wINJjxp9MIMxUXTmd/tM98ATxFKcwqIbKW+F43uaSGN9L5CMXHYwFqujutDKmJNECtGeaE6WQhbVtbGA2lyNjs+4gJMc9FPepbOt/t5Z7oN6ONMTUoRRZfIiQ8Xe08osvyOuz3zUq3r0oky7sa+1GaSE+CuzX0geJ6Z/K7X/yYjPrw4GbOG0iWV2SHbZGL0rhvfO/1KC5TjI+yP4A646XUDj99vrPgnicjrzdGb9PranFOTwphbRZyiHVShiL2H5WyZ5tnrTnp2//z5CqCYaVLRBRZNTE4np2FKHxmq3UZzOmmKeUj8GYU0BfJuJSwdk53bzM9Nx9dv4+49z3C2TVlUcx0lAxybBpPljVKb22mHk7BXOTWHlYFPzhSI/tSwb6yLzBYTF5r1n5WGNLow/C14opqHxNvy3XgcmXJOljz3W/WqygEpRVyS8peVCjWp2dIroZaCGcwfqpWtfJL/NRz/xy7njKljvIywh0WUs30jSA2S36zbMgmpnDsRrSHPaOXOgy+N2K9iy5s/F5VzWsGgo9ZMHDon9+ceSIp6j6mMKRV8VWG1DF9PyT20uheJDFOwXETLafbzPDW1hPYr7CzqkrYRCK76Ksf5T1UYtBL379/17S9UtxoqKQxuIQxSNAB3be1htMXit0Qds7PL1hO/m8Imj24S1BuT/4ToQFw/wuzC0Pp1YPraG2CwWKzL5p0n6c3X3cSxh89x0tYXlX9aJfoRXL1BGDWej9gJ8l3FdZoT/XaDeMSPAOg0IW+x1/gLBrN0eFx/IORe3kXxSIWoz8k15erZbxiI3A2GPHKlL1PcEqdLWoYFDcFaPL/nZPKs2Ur99pAV7TjGA== 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 1/11/23 02:57, Huang, Kai wrote: > On Tue, 2023-01-10 at 07:19 -0800, Dave Hansen wrote: >> 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. >> > > Thanks for the tip. How about below? > > static int tdmr_add_rsvd_area(struct tdmr_info *tdmr, int *p_idx, u64 addr, > u64 size, u16 max_reserved_per_tdmr) > { > struct tdmr_reserved_area *rsvd_areas = tdmr->reserved_areas; > int idx = *p_idx; > > /* Reserved area must be 4K aligned in offset and size */ > if (WARN_ON(addr & ~PAGE_MASK || size & ~PAGE_MASK)) > return -EINVAL; > > /* > * The TDX module supports only limited number of TDMRs and > * limited number of reserved areas for each TDMR. There's a > * balance to be had between TDMRs a2nd 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. > */ > if (idx >= max_reserved_per_tdmr) { > pr_warn("too many reserved areas for TDMR [0x%llx, 0x%llx)\n", > tdmr->base, tdmr_end(tdmr)); > return -ENOSPC; > } This isn't really converging on a solution. At this point, I just see my verbatim text being copied and pasted into these functions without really anything additional. This comment, for instance, just blathers about what could be done but doesn't actually explain what it is doing here. But, again, this isn't converging. It's just thrashing and not getting any better. I guess I'll just fix it up best I can when I apply it.