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 CD416C54EBD for ; Fri, 6 Jan 2023 22:07:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5471F8E0002; Fri, 6 Jan 2023 17:07:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F7258E0001; Fri, 6 Jan 2023 17:07:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E6AF8E0002; Fri, 6 Jan 2023 17:07:53 -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 3242B8E0001 for ; Fri, 6 Jan 2023 17:07:53 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0C5D1120E7D for ; Fri, 6 Jan 2023 22:07:53 +0000 (UTC) X-FDA: 80325762426.02.78D69E9 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf22.hostedemail.com (Postfix) with ESMTP id D2730C0015 for ; Fri, 6 Jan 2023 22:07:50 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=TstpgnmX; spf=pass (imf22.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.88 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=1673042871; 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=MMDhsrOfFsNIv+Q5XoIql3nvFXxvJ3C+JhnURBnf2b8=; b=WYT5D46/roS3lR5NXuPubV7V112bTkmOTejKxmBLfBmVid+SK3/utsGm81CVqG14KZFAGc e+XIBwwDG8PixxYCgYFqLt7rcqFPlZJ/reGs1+hplmj6YvJsa+B0uult7mxtvzR+rxmSGj YpqyByFUf5GkmNrvkKz7houTzGzKsO4= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=TstpgnmX; spf=pass (imf22.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.88 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=1673042871; a=rsa-sha256; cv=none; b=UC7yIuLMW+f4D32DL3fpGJXoT++HVLVQYlHpvILEJ3+x1TsnefBMjBmFylUHeb8sIudDBL wvm/56aXnB8Wl+50nQh2d2QsdrhZRlKTHM80u7GHTMN1hD1HD5sWzLFiadb2UxHQzWIYFB TFKo25uZZFmOaYfp+UaS5fU7usBvAno= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673042870; x=1704578870; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=PUhwpAPx9QoZBSVf0J1Kqv9kcSs4Ha7qkZRGZTH8vzQ=; b=TstpgnmX5bvZcDRLGWTiIaPAmhVTBv17B5OlRwYXIgJbivEtLOWBog1x bsDB4CUtirQNavtaWMoqg7Pidu0yrQEUUHm4p1CxYo8uMcRGVGShrnG/f WLaYuxDKAxex7wDe7NruSrUY6fW6Vy0io0LjZEfXa62critAjx3qjv7uJ AWWlMgEHnKCePhQipcKWVLcqdjEiLse4l+/Gc8R3RNk5uqyqV0Su6WcWJ 7nLUjwTl6AzsFWtzskZ6Hw/00eMrlf71p8If7U50sV61krEE8PZDmmlE/ N6aWBRarhgkR5Rvo5U5nEFRNlEZLYgER0XQiUXF2Sb9DqF8a+qXQ1vTY6 g==; X-IronPort-AV: E=McAfee;i="6500,9779,10582"; a="349787234" X-IronPort-AV: E=Sophos;i="5.96,306,1665471600"; d="scan'208";a="349787234" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2023 14:07:48 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10582"; a="649436711" X-IronPort-AV: E=Sophos;i="5.96,306,1665471600"; d="scan'208";a="649436711" Received: from xiangyuy-mobl.amr.corp.intel.com (HELO [10.212.251.186]) ([10.212.251.186]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2023 14:07:47 -0800 Message-ID: <2d7d2824-7aa7-5f96-d79b-b44ff7fe2ef9@intel.com> Date: Fri, 6 Jan 2023 14:07:47 -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: Kai Huang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: linux-mm@kvack.org, peterz@infradead.org, tglx@linutronix.de, seanjc@google.com, pbonzini@redhat.com, dan.j.williams@intel.com, rafael.j.wysocki@intel.com, kirill.shutemov@linux.intel.com, ying.huang@intel.com, reinette.chatre@intel.com, len.brown@intel.com, tony.luck@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com References: <27dcd2781a450b3f77a2aec833de6a3669bc0fb8.1670566861.git.kai.huang@intel.com> From: Dave Hansen In-Reply-To: <27dcd2781a450b3f77a2aec833de6a3669bc0fb8.1670566861.git.kai.huang@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D2730C0015 X-Stat-Signature: t6u78oo98stb7mxn67ookgbf6a4y15xm X-HE-Tag: 1673042870-92218 X-HE-Meta: U2FsdGVkX18d2Y4yWQrz77B3biTU7eIyw/ZCJxSY1/JMiEm/AxHchB7OkBpfTZo2TWDXMYi1yMxu72+Hj9fxg0miSZ0bNWCjjrKwYdhOjb7wTJ+mDzo7gcEY3fY+ZhL9Dl2Wf6N8chlNCntW1kCNnW3NMI/b2LPjNs/eJpFNllUKaWuocwEsLMOYhuoppRxIK6+Us/ZroiTTMVV65oPeFm7sJiJYSVCMjuGlmO6oKj5IijYYawrra+700I2RP3KLeWJS0/prA5TEsN4i16aomc6jxCrv6ELzZcu7X3KStmuKiBWf3O94kijh+bVC8SP0ZAbsksi89c5NBDGa+KRJTsuKszLZj0LcZtWAy+ICBC1f+4IwxKrfiz2UhoJIMCLQ8WJsjYWvRaobwYx+p1qnJa6KZnDWeG3EuUmywOIif9iDa4FAVGVR8Ig55FprIHcVGYuHO/AIm1E9dZDhwgMHP4wZgG9rWh7YFhgi2PuC/GtGc3sgA472vDaqydmclGBEwghMfVNgvas72wct4el68jXf+xl3GAoLDK5HAEXdCL7sIi1GsQaOrl+vUMVyAoMJMwY2ykNCiKtQzGWQ70PV9RKNr44NK37U2n8sXrsZa5FAkq+TZsHOFNU5EsDt6mSeyCohdgy79y8Jxuh+6fYgmomaDy1svS9NY7KBK0pG/gcx6E8pfMPHMbxgGvmmTkLu67kVtvF5XBjvCotzEOKF7wJ5vDrf138EyLi4ekYsokS2K3jdF0TFxjPQqvw9vNtnlpWGoTSSWazn6iw76guh0Q7lXeqjdjM2AoHk9aIbu1OC+B4qTZ7NtrR79JpHkXOh X-Bogosity: Ham, tests=bogofilter, spamicity=0.000138, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 12/8/22 22:52, Kai Huang wrote: > +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; > + > + if (idx >= max_reserved_per_tdmr) > + return -E2BIG; > + > + rsvd_areas[idx].offset = addr - tdmr->base; > + rsvd_areas[idx].size = size; > + > + *p_idx = idx + 1; > + > + return 0; > +} It's probably worth at least a comment here to say: /* * Consume one reserved area per call. Make no effort to * optimize or reduce the number of reserved areas which are * consumed by contiguous reserved areas, for instance. */ I think the -E2BIG is also wrong. It should be ENOSPC. I'd also add a pr_warn() there. Especially with how lazy this whole thing is, I can start to see how the reserved areas might be exhausted. Let's be kind to our future selves and make the error (and the fix) easier to find. 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. I'm *really* close to acking this patch once those are fixed up.