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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39FD1C4338F for ; Tue, 10 Aug 2021 15:16:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 978B560F13 for ; Tue, 10 Aug 2021 15:16:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 978B560F13 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 0AA198D0012; Tue, 10 Aug 2021 11:16:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 033B18D0001; Tue, 10 Aug 2021 11:16:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E63A98D0012; Tue, 10 Aug 2021 11:16:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0119.hostedemail.com [216.40.44.119]) by kanga.kvack.org (Postfix) with ESMTP id C7D838D0001 for ; Tue, 10 Aug 2021 11:16:28 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 79DB722000 for ; Tue, 10 Aug 2021 15:16:28 +0000 (UTC) X-FDA: 78459522456.35.D5A41EC Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf22.hostedemail.com (Postfix) with ESMTP id 528651987 for ; Tue, 10 Aug 2021 15:16:27 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10072"; a="211816397" X-IronPort-AV: E=Sophos;i="5.84,310,1620716400"; d="scan'208";a="211816397" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2021 08:16:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,310,1620716400"; d="scan'208";a="469054407" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga008.jf.intel.com with ESMTP; 10 Aug 2021 08:16:15 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 03C38142; Tue, 10 Aug 2021 18:15:48 +0300 (EEST) Date: Tue, 10 Aug 2021 18:15:48 +0300 From: "Kirill A. Shutemov" To: Dave Hansen Cc: "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/5] x86: Impplement support for unaccepted memory Message-ID: <20210810151548.4exag5uj73bummsr@black.fi.intel.com> References: <20210810062626.1012-1-kirill.shutemov@linux.intel.com> <4b80289a-07a4-bf92-9946-b0a8afb27326@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4b80289a-07a4-bf92-9946-b0a8afb27326@intel.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 528651987 Authentication-Results: imf22.hostedemail.com; dkim=none; spf=none (imf22.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none) X-Stat-Signature: dzetqwwf4swp7gcnu187e6s9uj79pqba X-HE-Tag: 1628608587-588349 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 Tue, Aug 10, 2021 at 07:08:58AM -0700, Dave Hansen wrote: > On 8/9/21 11:26 PM, Kirill A. Shutemov wrote: > > UEFI Specification version 2.9 introduces concept of memory acceptance: > > Some Virtual Machine platforms, such as Intel TDX or AMD SEV-SNP, > > requiring memory to be accepted before it can be used by the guest. > > Accepting happens via a protocol specific for the Virtrual Machine > > platform. > > > > Accepting memory is costly and it makes VMM allocate memory for the > > accepted guest physical address range. We don't want to accept all memory > > upfront. > > This could use a bit more explanation. Any VM is likely to *eventually* > touch all its memory, so it's not like a VMM has a long-term advantage > by delaying this. > > So, it must have to do with resource use at boot. Is this to help boot > times? Yes, boot time is main motivation. But I'm going also to look at long-term VM behaviour with the fixed memory footprint. I think if a workload allocate/free memory within the same amount we can keep memory beyond the size unaccepted. Few tweaks likely will be required such as disabling page shuffling on free to keep unaccepted memory at the tail of free list. More investigation needed. > I had expected this series, but I also expected it to be connected to > CONFIG_DEFERRED_STRUCT_PAGE_INIT somehow. Could you explain a bit how > this problem is different and demands a totally orthogonal solution? > > For instance, what prevents us from declaring: "Memory is accepted at > the time that its 'struct page' is initialized" ? Then, we use all the > infrastructure we already have for DEFERRED_STRUCT_PAGE_INIT. That was my first thought too and I tried it just to realize that it is not what we want. If we would accept page on page struct init it means we would make host allocate all memory assigned to the guest on boot even if guest actually use small portion of it. Also deferred page init only allows to scale memory accept across multiple CPUs, but doesn't allow to get to userspace before we done with it. See wait_for_completion(&pgdat_init_all_done_comp). -- Kirill A. Shutemov