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 49FD8C43334 for ; Fri, 24 Jun 2022 17:21:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC6548E023D; Fri, 24 Jun 2022 13:21:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B764B8E020E; Fri, 24 Jun 2022 13:21:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A65B28E023D; Fri, 24 Jun 2022 13:21:39 -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 97CD68E020E for ; Fri, 24 Jun 2022 13:21:39 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6B88E648 for ; Fri, 24 Jun 2022 17:21:39 +0000 (UTC) X-FDA: 79613796318.31.50419DA Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) by imf09.hostedemail.com (Postfix) with ESMTP id 0E899140036 for ; Fri, 24 Jun 2022 17:21:38 +0000 (UTC) Received: by mail-lj1-f171.google.com with SMTP id q9so3504591ljp.4 for ; Fri, 24 Jun 2022 10:21:38 -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=JlWbCSGLtoiUV9s5S4I2VF33Zo7YdAO/mkxevgyN3qY=; b=nJBAU9/tj07UZN5FNXK9+/KHQEQgAEeFhyuesPS5GOApEHjX+EZ8Y696xGVH4AETeS ozyG1usKOWwfHkZPditLB7l9QicK4TkDG2HiCWPdki2MlZX1iL4p2yuf1q1Jb071k16n jiePdSJPriiouBDtb9EghNbRp0ss52hqUMfmne9fPcanCttDFory5YyqoHUCWRNAP1ML G72DpjEFAMUtxUL2Kktl2XU6YrKJ2ZxvnZfUghkVW3zPxR9Uv9hUFaLflu9AER3lo/IV eIhOUNmapsoBDrQC9vrn4kpCaBRBhq9RHdMCy6YSNwLoY0lGPtuf9lKqoRHV+rzAh1jV yhCQ== 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=JlWbCSGLtoiUV9s5S4I2VF33Zo7YdAO/mkxevgyN3qY=; b=MAl97HFsdlFRD/O3nH1PZIC1lCjecBsh7zcai6oR0iFTbQ1OvKtxE2xja793sqJHuZ VHBJ4eLMbAQplDsZUXWs4SGSIz5FTQW8udmClFWNh6YS8BbqFGr1pG8CnzW9zN+pnJau sx9EEB63/1qujKnDWVTmsPBCKsVcJgwtSTqZC/Ptcad8dBz30vbrB1SqvtLQCMDaqhll J9kzdLAzt5s0ltnCg3ek0+X5If+P3Tsu4lJZZGFfTJoqGN0Wvkp4c1s1zTJoz8j+dXYP ZMsXtSfqnXwuQ2lGgi7MAD2/DTzpOIW5Pst6SWvBgueCDRCPB4mPwK5VdnUye/3NIAkS 37eA== X-Gm-Message-State: AJIora/REveamMa88M9ZingE1nqt9N/AXR55DkCPXiLUCLZECwtd+XJI vtqUFiV/swWvw2Y10W7nal28jKVGxwZ1V1f81vkecA== X-Google-Smtp-Source: AGRyM1tyq/jv822hk5wlM5QlG82jddLwlvGXpXf/h4elvz2TSVuZgsSFmh+n0GoDKUeq9/eS1bNdObIlvQ1xDik8nts= X-Received: by 2002:a2e:b911:0:b0:25a:9942:4171 with SMTP id b17-20020a2eb911000000b0025a99424171mr18800ljb.426.1656091297292; Fri, 24 Jun 2022 10:21:37 -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: From: Peter Gonda Date: Fri, 24 Jun 2022 11:21:25 -0600 Message-ID: Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory To: Marc Orr Cc: Dave Hansen , "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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656091299; a=rsa-sha256; cv=none; b=lWJ7azpVAiEwYFpYBrkx33C19IlS3kkqZSPrXFkadafA1GKJG3jA2k3yI0P4pSoSs3LMqX QPNepZfpuiGPmODRyx55lzr3pmgcQFMTyek77mx4dJDRHnryMYr/gZjDPZbsOrWsAJ5TvQ IxOHjavYITMv35hXFcd4qCSkCzHPIJI= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="nJBAU9/t"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of pgonda@google.com designates 209.85.208.171 as permitted sender) smtp.mailfrom=pgonda@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656091299; 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=JlWbCSGLtoiUV9s5S4I2VF33Zo7YdAO/mkxevgyN3qY=; b=FLRJcnSPar5/0TZaejUiN5nDuFGHUFwVTYG2ASb/BcSfhIBrm8E1KLhirMzxlY6qVNuECQ jwX8xZsu1eKTfEoYZVMEw6mkItjEyiztfBsx5E/c6EZzqiniY7wWMpPya0JWfueAvsHM4q 3GXFU8QG3D9i+aN3qdw7j2o80uCwZI0= X-Stat-Signature: 9kgaguar8akp3x87j6o3mbyk73ric7tw X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0E899140036 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="nJBAU9/t"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of pgonda@google.com designates 209.85.208.171 as permitted sender) smtp.mailfrom=pgonda@google.com X-HE-Tag: 1656091298-405079 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 11:19 AM Marc Orr wrote: > > On Fri, Jun 24, 2022 at 10:10 AM Dave Hansen wrote: > > > > On 6/24/22 10:06, Marc Orr wrote: > > > 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? > > > > Hold on a sec though... > > > > Is this a matter of > > > > can boot from a guest firmware that doesn't pre-validate all the > > guest memory? > > > > or > > > > can boot from a guest firmware that doesn't pre-validate all the > > guest memory ... with access to all of that guest's RAM? > > > > In other words, are we talking about "fails to boot" or "can't see all > > the RAM"? > > Ah... yeah, you're right, Dave -- I guess it's the latter. The guest > won't have access to all of the memory that the customer is paying > for. But that's still bad. If the customer buys a 96 GB VM and can > only see 4GB because they're kernel doesn't have these patches they're > going to be confused and frustrated. The other error case which might be more confusing to the customer is their kernel does have these patches, there is some misconfiguration and their VM boots slowly because the FW uses the accept all memory approach.