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 E4BA0C433EF for ; Fri, 24 Jun 2022 17:06:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5A7F08E0237; Fri, 24 Jun 2022 13:06:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5579E8E020E; Fri, 24 Jun 2022 13:06:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41E208E0237; Fri, 24 Jun 2022 13:06:15 -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 31A2E8E020E for ; Fri, 24 Jun 2022 13:06:15 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 021B0120A8F for ; Fri, 24 Jun 2022 17:06:14 +0000 (UTC) X-FDA: 79613757510.31.D311EF9 Received: from mail-oa1-f54.google.com (mail-oa1-f54.google.com [209.85.160.54]) by imf20.hostedemail.com (Postfix) with ESMTP id 8EA1E1C0036 for ; Fri, 24 Jun 2022 17:06:14 +0000 (UTC) Received: by mail-oa1-f54.google.com with SMTP id 586e51a60fabf-fb6b4da1dfso4608097fac.4 for ; Fri, 24 Jun 2022 10:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CNj4o58y/LRVMbp0gtHvuuSoOAj5isxfmdswamXi6K0=; b=MkHasKomYbS9loFCR6yTgyya6gyA2jpz6NNZRyQJYKW4oQSuwwSFc1O0+9Y+CzVHeJ dfcbWHWh7ZpyY02ZnLqvS+K041Ci2tw2whaK9HXsVT7xwvRN5EhYbREV9vyu61bEYxD9 x4+WcBWjeolE1wF1pC28AoFAkMEgKTSAxMIdHv44bGNEwO+xqjOe7zTfiqp7UiqiTfz/ gvurZnvU3fxi2A85ArS8/AFoXKBNZX/FIAVVnmdeDQ7aOQL6q2IkW+7VMJtWYlJeByP7 1ZkZz9Xj0jVq9QN3dPDo5lnIRJgUBxo8qghwufYSoWhKD0p+oDVx9N8VmlMJBHbZSsV1 +pog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CNj4o58y/LRVMbp0gtHvuuSoOAj5isxfmdswamXi6K0=; b=jq4MtREfZrR7VnQfAJcFJ47owstGDhy0wBcny4fMoK3DoIgylRaZfW4ljLzGErxgRQ VoDfzySHelkIMsoAFy74ADS0z9QS5DnF2nghjSGw6OYSKPS/kdTshmdOaABl69PUy6pa NLGMMjt9NYw+ktCRriLXpC2WZzhgE/bAMOjoNw9UTNbnvnTZf4k39Kk2/YAbDGy+1yJ+ Eo0LiKkAxBpK3/NXHlAIhWNuKBPx7R2WXDReBXUtU28XxR7DYVI324BI3zNzuWY3D1xL g1HlgTf7OZd4GgBY23LoDbpXbnVNPDoWHoa7PpUOwFukH4GsaZJ8j8k8pNtaBaXhsqeb hT8Q== X-Gm-Message-State: AJIora8NYbEUxXmJX5lmgt2bsqwO9+Yw68341VlbQrMnXccMiwYjkxTW f7/4Iib8fSGWN+JQyyS1QhdYOQ1gg0oQ7MD4iQHA8w== X-Google-Smtp-Source: AGRyM1uYB2KAHIawaPG0CfnwZruheDErv9xure2U4x9mVl2PvkUR8kfcV3fRPgldBIkl5mlqCOXRHDMBi8/CvVVjito= X-Received: by 2002:a05:6870:d620:b0:101:a621:9ea0 with SMTP id a32-20020a056870d62000b00101a6219ea0mr2746901oaq.110.1656090373508; Fri, 24 Jun 2022 10:06:13 -0700 (PDT) MIME-Version: 1.0 References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <5af19000-4482-7eb9-f158-0a461891f087@intel.com> In-Reply-To: <5af19000-4482-7eb9-f158-0a461891f087@intel.com> From: Marc Orr Date: Fri, 24 Jun 2022 10:06:02 -0700 Message-ID: Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory To: Dave Hansen Cc: Peter Gonda , "Kirill A. Shutemov" , Borislav Petkov , 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 , tim.gardner@canonical.com, Khalid ElMously , philip.cox@canonical.com, "the arch/x86 maintainers" , linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, LKML Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=MkHasKom; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of marcorr@google.com designates 209.85.160.54 as permitted sender) smtp.mailfrom=marcorr@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656090374; 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=CNj4o58y/LRVMbp0gtHvuuSoOAj5isxfmdswamXi6K0=; b=hpgbd7cY6QPK+JAud9RxAeQ+VV3cUWCKbMKQpuz6a21KrFn380gG9OpwDRJmJW77wwQFob TWXnPae6/Xv2vDHbD3A/vZsYI7n5qbCuu7/vwhmzxulS2x04KZ+QTkz9N4Hfvqyst8vYbT NimKR5zc50tCroRxK0qBCFH0CtSRLrk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656090374; a=rsa-sha256; cv=none; b=M1ALpDd8MX6oX88+8JP9sDzxUpn46z9RVsK984An9zXZsJAmvr+hwWzkcCaTVhuBZBtUPb TSJANhzRZdyMxWOxi/y3rfjyhW1tuhzYmguh5Z2lFkPvEGy0pnt/AhUz8qFvPvp+pvP58I mKTbMpm9vLg6UBLVUw2ptIHP8ghdMNg= X-Stat-Signature: 75ttsszhtnkgus3btzxzad1cb6mqqmqr X-Rspamd-Queue-Id: 8EA1E1C0036 X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=MkHasKom; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf20.hostedemail.com: domain of marcorr@google.com designates 209.85.160.54 as permitted sender) smtp.mailfrom=marcorr@google.com X-Rspamd-Server: rspam12 X-HE-Tag: 1656090374-517499 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 Fri, Jun 24, 2022 at 9:57 AM Dave Hansen wrote: > > Peter, is your enter key broken? You seem to be typing all your text in > a single unreadable paragraph. > > On 6/24/22 09:37, Peter Gonda wrote: > > if a customer incorrectly labels their image it may fail to boot.. > > You're saying that firmware basically has two choices: > 1. Accept all the memory up front and boot slowly, but reliably > 2. Use thus "unaccepted memory" mechanism, boot fast, but risk that the > VM loses a bunch of memory. > > If the guest can't even boot because of a lack of memory, then the > pre-accepted chunk is probably too small in the first place. > > If the customer screws up, they lose a bunch of the RAM they paid for. > That seems like a rather self-correcting problem to me. I think Peter's point is a little more nuanced than that. Once lazy accept goes into the guest firmware -- without the feature negotiation that Peter is suggesting -- cloud providers now have a bookkeeping problem. Which images have kernels that can boot from a guest firmware that doesn't pre-validate all the guest memory? The way we've been solving similar bookkeeping problems up to now (e.g., Which guest can run with CVM features like TDX/SEV enabled? Which SEV guests can live migrate?) is as follows. We tag images with feature tags. But this is sort of a hack. And not a great one. It's confusing to customers, hard for the cloud service provider to support, and easy to mess up. It would be better if the guest FW knew whether or not the kernel it was going to launch supported lazy accept. That being said, this does seem like a difficult problem to solve, since it's sort of backward from how things work, in that when the guest firmware wants to switch between pre-validating all memory vs. minimizing what it pre-validates, the guest kernel is not running yet! But if there is some way to do this, it would be a huge improvement over the current status quo of pushing the feature negotiation up to the cloud service provider and ultimately the cloud customer.