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 574E3C4332F for ; Tue, 22 Nov 2022 01:55:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5E616B0071; Mon, 21 Nov 2022 20:55:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A0E516B0073; Mon, 21 Nov 2022 20:55:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D55F6B0074; Mon, 21 Nov 2022 20:55:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7F8D16B0071 for ; Mon, 21 Nov 2022 20:55:30 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 48E2B1A0730 for ; Tue, 22 Nov 2022 01:55:30 +0000 (UTC) X-FDA: 80159411220.12.9446490 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf26.hostedemail.com (Postfix) with ESMTP id 288D2140005 for ; Tue, 22 Nov 2022 01:55:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669082129; x=1700618129; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=UL9BppxMI7SvBsBmBhEJhMoMeo2j0emkQGnFT8j41tc=; b=dPZKO2JmeMU1d6FeB4paThcfzll7sPRfpVqF0eCl4/3GbmWe7k9iy/n5 oiGDiR9MePsJW7GrRTJ0geMKYe6YyeblsnVmoNbkF0iOWZMWedV7FoA7c rjEjmAwofaqQMGI3WQG8vKKLpuFdz1ItxH0gSwq3ymYcXtJvLQC07B9Iu QZ8lhvbGzM46Lf5WWKEDykd+3eG2Uk75y5Lx/ANFMo6ubHcP6s2z5v3rd w77YQPavqdmIKffrNHDPs5gwpgMHPZSqd2d0TMxDbi+mUfGbwsliQygR2 agaPQRwBj47cL0dVgSAZmMNpoZGASqlKI6g4SeFTRcdSpFlEGytyA6La/ w==; X-IronPort-AV: E=McAfee;i="6500,9779,10538"; a="377964565" X-IronPort-AV: E=Sophos;i="5.96,182,1665471600"; d="scan'208";a="377964565" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Nov 2022 17:55:27 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10538"; a="730227673" X-IronPort-AV: E=Sophos;i="5.96,182,1665471600"; d="scan'208";a="730227673" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Nov 2022 17:55:22 -0800 From: "Huang, Ying" To: "Huang, Kai" Cc: "kvm@vger.kernel.org" , "Hansen, Dave" , "Luck, Tony" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "linux-kernel@vger.kernel.org" , "Christopherson,, Sean" , "Chatre, Reinette" , "pbonzini@redhat.com" , "linux-mm@kvack.org" , "Yamahata, Isaku" , "kirill.shutemov@linux.intel.com" , "peterz@infradead.org" , "Shahar, Sagi" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Williams, Dan J" Subject: Re: [PATCH v7 10/20] x86/virt/tdx: Use all system memory when initializing TDX module as TDX memory References: <9b545148275b14a8c7edef1157f8ec44dc8116ee.1668988357.git.kai.huang@intel.com> <87cz9gvpej.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Tue, 22 Nov 2022 09:54:25 +0800 In-Reply-To: (Kai Huang's message of "Mon, 21 Nov 2022 17:09:33 +0800") Message-ID: <87sfibpxda.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=dPZKO2Jm; spf=pass (imf26.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669082129; a=rsa-sha256; cv=none; b=yU02tkUuzvtJmLTb/DzcLSdHwVEjpVCm8XhTqS9v8Az0w9V1K3cpBCT9wddUlznzo+5765 O5Z/+g/cSr7DlGoaUshmKWyZ91ypVP/1irgMscFcayA34UrJ1Zuk/oG87P6VO8R43g3mag PdnPeGLf7mU0l2H9OXwbsIfMkbR+wBI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669082129; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KfGWuThId4Hb2thA/kktER7yuMk5ln2b1vNdptm4GKA=; b=bGHsnF8Xqn5KGKoH/ehCw6kVFKMs/n3Ny4w2M/fhCDh9IK3zMJyX7GJG522Ad70yHHRmVN dGksvCGtfFmKcW09tIEXqCavtOByTT6JcutNl/kZqtU1Z+Z6oPl58Yn3Y0WsVcl5P8FUyV HQbeJTVAW/0ue618iQV2dZAS/LGEj+c= X-Stat-Signature: w3tn8q4ipgzya9wm5tyhmtiimyi9n9nb X-Rspamd-Server: rspam08 X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=dPZKO2Jm; spf=pass (imf26.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.100 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Queue-Id: 288D2140005 X-HE-Tag: 1669082128-707 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: "Huang, Kai" writes: [...] > >> > + >> > +/* >> > + * Add all memblock memory regions to the @tdx_memlist as TDX memory. >> > + * Must be called when get_online_mems() is called by the caller. >> > + */ >> > +static int build_tdx_memory(void) >> > +{ >> > + unsigned long start_pfn, end_pfn; >> > + int i, nid, ret; >> > + >> > + for_each_mem_pfn_range(i, MAX_NUMNODES, &start_pfn, &end_pfn, &nid) { >> > + /* >> > + * The first 1MB may not be reported as TDX convertible >> > + * memory. Manually exclude them as TDX memory. >> > + * >> > + * This is fine as the first 1MB is already reserved in >> > + * reserve_real_mode() and won't end up to ZONE_DMA as >> > + * free page anyway. >> > + */ >> > + start_pfn = max(start_pfn, (unsigned long)SZ_1M >> PAGE_SHIFT); >> > + if (start_pfn >= end_pfn) >> > + continue; >> >> How about check whether first 1MB is reserved instead of depending on >> the corresponding code isn't changed? Via for_each_reserved_mem_range()? > > IIUC, some reserved memory can be freed to page allocator directly, i.e. kernel > init code/data. I feel it's not safe to just treat reserved memory will never > be in page allocator. Otherwise we have for_each_free_mem_range() can use. Yes. memblock reverse information isn't perfect. But I still think that it is still better than just assumption to check whether the frist 1MB is reserved in memblock. Or, we can check whether the pages of the first 1MB is reversed via checking struct page directly? [...] Best Regards, Huang, Ying