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 5B020C433FE for ; Mon, 11 Apr 2022 16:27:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D3F386B0072; Mon, 11 Apr 2022 12:27:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CEE236B0073; Mon, 11 Apr 2022 12:27:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BDD446B0074; Mon, 11 Apr 2022 12:27:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id AFC236B0072 for ; Mon, 11 Apr 2022 12:27:26 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 75CA0121A00 for ; Mon, 11 Apr 2022 16:27:26 +0000 (UTC) X-FDA: 79345128492.12.3C83D54 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf16.hostedemail.com (Postfix) with ESMTP id 44608180005 for ; Mon, 11 Apr 2022 16:27:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649694445; x=1681230445; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=/aHQQW61ELAgL2r5a3VbnJQ4DMr1/mD/2EjRSZ2mIbc=; b=FofUUJNMujwtgk2JnkpPNQqC/nCmUSVZWMJqSLdFsXwSfgNmeH03M0p/ Xt2fCmrt412ZjEm7wjZpylMfhnuAQlMl/iVz4/Uz2JurDJsbGJUMkUbcP +i8yv4N8QFObAgzfGmJ8luT2xd9nkvHM1ckajkDVUD6ejWUza1RRz2F+Y wP5l3i6+gvyBuqazFRZmGXAM64GL6yvi9UtWva+lO76VIR/xDx7y5wsUB T8fGmp9QGc27UtqN9YdGuPcXbcH+a+uU5Kna19UXqk+lyzECZ9wQaVK5V 4zolaNtipaoXpBLX8VQErDtef5P5g92In1F68gIUPUJxiAZJUPVkCcASu g==; X-IronPort-AV: E=McAfee;i="6400,9594,10314"; a="287166136" X-IronPort-AV: E=Sophos;i="5.90,252,1643702400"; d="scan'208";a="287166136" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2022 09:27:23 -0700 X-IronPort-AV: E=Sophos;i="5.90,252,1643702400"; d="scan'208";a="507173559" Received: from srkondle-mobl.amr.corp.intel.com (HELO [10.212.113.6]) ([10.212.113.6]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2022 09:27:22 -0700 Message-ID: Date: Mon, 11 Apr 2022 09:27:27 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Borislav Petkov Cc: "Kirill A. Shutemov" , "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 , Brijesh Singh , Mike Rapoport , David Hildenbrand , 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: <20220405234343.74045-1-kirill.shutemov@linux.intel.com> <20220405234343.74045-2-kirill.shutemov@linux.intel.com> <93a7cfdf-02e6-6880-c563-76b01c9f41f5@intel.com> <20220409175210.xik3ue3shpagskvi@box.shutemov.name> From: Dave Hansen Subject: Re: [PATCHv4 1/8] mm: Add support for unaccepted memory In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 44608180005 X-Stat-Signature: 44zuamgopxxpwamm7nea3pa4es3mc93u Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=FofUUJNM; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf16.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=dave.hansen@intel.com X-Rspam-User: X-HE-Tag: 1649694445-441198 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 4/11/22 08:55, Borislav Petkov wrote: > On Sun, Apr 10, 2022 at 11:41:57PM -0700, Dave Hansen wrote: >> Let's just call out the possible (probable?) need for new ABI here. >> Maybe it will cue folks who care to speak up. > Err, why would you teach the user to go poke at some arbitrary sysfs > nodes when the accepting code can simply issue a printk from time to > time > > "Guest unnaccepted memory progress: XX%. This slows down operations at the moment." I guess that's not a horrible place to start. It's also not *horribly* different from how guests work today. If hosts lazily allocate RAM, they'll see largely the same kind of behavior. What ends up determining how much memory is pre-accepted versus being done from the guest? Is that just a normal part of setting up a TDX guest, like from the qemu cmdline? Or, is there some convention with the virtual firmware?