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 F2B0BC433EF for ; Fri, 22 Jul 2022 19:30:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 851846B0072; Fri, 22 Jul 2022 15:30:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8009C6B0073; Fri, 22 Jul 2022 15:30:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A0F06B0074; Fri, 22 Jul 2022 15:30:42 -0400 (EDT) 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 538726B0072 for ; Fri, 22 Jul 2022 15:30:42 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 288B6160D74 for ; Fri, 22 Jul 2022 19:30:42 +0000 (UTC) X-FDA: 79715727924.07.F3BCD6D Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by imf09.hostedemail.com (Postfix) with ESMTP id 0B51E1400A2 for ; Fri, 22 Jul 2022 19:30:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658518241; x=1690054241; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=yiC+//i7K9IE9d4hXO9yECQl7g97rBdGulNv7h3t0vA=; b=FZ9RDXGdAdAIqDb/noO/6fb1GWmXOB+kVZrnF1EW+GYnLI5O+CFMpMEL ISdYc9cVC8J3G7N8mlFff/s8NN/WqakmLVIzrzhmQYYEdV4lPqBgcxxDz sleBaP7h69x4dsoqIRpalGFtWo+VL/TWDRXJaMoiDIajbJwcsYcNTDyIh ydpjmZdQdOIq/sOAq7eSQIL/GFYbg3EOUPEDIgJAzBmphtCeKvJvZotLT i75Ry6449DdDTako8nyBxG4NyXQeZaK+fiG8WYQE+qDtRlSUBnDHfZvPm 0yCYqi6L2k3Q8+hDyYZP5Nw4k589xwDg4dWSJ0W4XJRU1xKKnyGZQ/fdL A==; X-IronPort-AV: E=McAfee;i="6400,9594,10416"; a="349091198" X-IronPort-AV: E=Sophos;i="5.93,186,1654585200"; d="scan'208";a="349091198" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jul 2022 12:30:39 -0700 X-IronPort-AV: E=Sophos;i="5.93,186,1654585200"; d="scan'208";a="926161928" Received: from jnoah-mobl.amr.corp.intel.com (HELO [10.209.71.211]) ([10.209.71.211]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jul 2022 12:30:37 -0700 Message-ID: <707ca113-c2a2-8fe2-a22c-5be13adc7bb4@intel.com> Date: Fri, 22 Jul 2022 12:30:36 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCHv7 02/14] mm: Add support for unaccepted memory Content-Language: en-US To: Borislav Petkov Cc: "Kirill A. Shutemov" , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Mike Rapoport , David Hildenbrand , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Mike Rapoport References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <20220614120231.48165-3-kirill.shutemov@linux.intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658518241; a=rsa-sha256; cv=none; b=K9ThPsA6VGUPP8p4OxQvdeqMadyZamBEE+2KGmTQOEO0u4fuFLr2emZMZW4izs418yItTK kn3d2QVUwukh78/TqULgIZpS1KY/FRxK1pMWbCGqhwYEXJyfJaVonF6NxCQhnJAKdO9Ci6 +3EvSThmTaKl+mJ5L2PuCwZbhO7YOWg= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=FZ9RDXGd; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf09.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=dave.hansen@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658518241; 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=WOcYm1ZMQ9A0eQne2We6FbXs/av8zRhKooI8k1YVe2o=; b=wEXN01G5Ugs/faV9ZOXa/6Mz3wokp7VaQZDkocJvLiCA102CmBiWFo3aLBitFeNrS8i5H2 FEyy9EnPK8fzXC9rl1XpiDftOw8f0g0QUeFG5OivVVP8tsl3+Oko4HJq45ieiO5G81qxya 5fit8GGBaoSrwyIV/z7C4Tj/T2k2e/0= X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 0B51E1400A2 X-Stat-Signature: 17w6zuqpxnb39qsktcrdeeijn6dkm7zo Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=FZ9RDXGd; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf09.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=dave.hansen@intel.com X-HE-Tag: 1658518240-325073 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 7/22/22 12:18, Borislav Petkov wrote: > On Thu, Jul 21, 2022 at 08:49:31AM -0700, Dave Hansen wrote: >> So, those (effective) 2MB clflush+memset's (plus a few thousand cycles >> for the hypercall/tdcall transitions) > > So this sounds strange - page validation on AMD - judging by the > pseudocode of the PVALIDATE insn - does a bunch of sanity checks on the > gVA of the page and then installs it into the RMP and also "PVALIDATE > performs the same segmentation and paging checks as a 1-byte read. > PVALIDATE does not invalidate TLB caches." > > But that still sounds a lot less work than what the TDX module needs to > do... Sure does... *Something* has to manage the cache coherency so that old physical aliases of the converted memory don't write back and clobber new data. But, maybe the hardware is doing that now. >> If you have a few hundred CPUs all trying to allocate memory (say, >> doing the first kernel compile after a reboot), this is going to be >> very, very painful for a while. >> >> That said, I think this is the right place to _start_. There is going >> to need to be some kind of follow-on solution (likely background >> acceptance of some kind). But, even with that solution, *this* code >> is still needed to handle the degenerate case where the background >> accepter can't keep up with foreground memory needs. > > I'm still catering to the view that it should be a two-tier thing: you > validate during boot a certain amount - say 4G - a size for which the > boot delay is acceptable and you do the rest on-demand along with a > background accepter. > > That should give you the best of both worlds... Yeah, that two-tier system is the way it's happening today from what I understand. This whole conversation is about how to handle the >4GB memory.