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 B9D8BC43334 for ; Fri, 24 Jun 2022 17:16:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3628C8E023B; Fri, 24 Jun 2022 13:16:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 310CF8E020E; Fri, 24 Jun 2022 13:16:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FF3D8E023B; Fri, 24 Jun 2022 13:16:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 0CEB58E020E for ; Fri, 24 Jun 2022 13:16:28 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D415320CC8 for ; Fri, 24 Jun 2022 17:16:27 +0000 (UTC) X-FDA: 79613783214.01.11AC87A Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by imf08.hostedemail.com (Postfix) with ESMTP id 4F93D1600B2 for ; Fri, 24 Jun 2022 17:16:07 +0000 (UTC) Received: by mail-lj1-f177.google.com with SMTP id a11so3484566ljb.5 for ; Fri, 24 Jun 2022 10:16:07 -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=h7TLEeCFth7PheP9Vjw0eOfwGgWMcwKrKSrdpGrebWY=; b=IU3rG809nvHZOZvyEcynZb5cx8uhkr0QKQGEbHpM7aM3INwbrTUi+sJoYs+poBe5yp SUxlrL0gk2U5l9Tl1uRgX2Nvd+9OoDaDB+rrpLWMA0+YwmNGiX1IXzrNmkjxDMe9VIPF DJpA0UjxRjtbScKgaEKHhW7ppvN09yvXNsrNVzUhjEdkni1H9IjXu4Cqtxh2Dm8+7aRH LmaYAiHtbI1K235l7U6bwe38YtQjXSw1g0zhcNTQaALYl2nxJaEA70C6ZTI3HaFVPIiB 80IC0gWVvBSre5Xp3FBbIEwP1uT9dAn+VU8gMLbLK3/QoV2/fGqIq9mRE892Iuk4TWZS FE2A== 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=h7TLEeCFth7PheP9Vjw0eOfwGgWMcwKrKSrdpGrebWY=; b=dqmzWVe6Qazeb4V1mRcBo3CEeF2DeWCEMaWpvQADtl3uuoyGLoLpJhBWxsyRoCYs39 0fSHXyk0hUviuivZlhpSzIO1soWxT5KGPBWlW9oI1KxSdemtbVmm1bliQJanCyDlSslK SBvPNWdjG31NYbVa9162DbfVuuMnssACw7Q6SadTO8BILsKjiCMUiWbTV/v570laDcLK 1f3KJVUQaQ2b49emKtkDVb0R155enVPwVPLeiZDXqmo3hp2KxQa4tp5B1hpm+auQtIfy dqHd2n3p+pBDbl4zcCMSmscEs7kROBUsxDGJGPw4ts5vl5E6nb8LN/++wR7nfFV95GKD tArg== X-Gm-Message-State: AJIora9zpIUVXkVRGwQSxpNPHPKK6PL1qMnGEjzUd6slesTl0nel4Exj GW4mpY6tZd7x3aSErDIzftaomudhoRJuy42lFVAhiw== X-Google-Smtp-Source: AGRyM1t8yYXv52NYU8Eipze+F/p8oqSexP7qPbPFFLxQEI0Uh3d5+Lj1NFdceTfhcMwRr7ETcSSU7a0q88R1auWwSy8= X-Received: by 2002:a2e:b911:0:b0:25a:9942:4171 with SMTP id b17-20020a2eb911000000b0025a99424171mr9602ljb.426.1656090965474; Fri, 24 Jun 2022 10:16:05 -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:15:53 -0600 Message-ID: Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory To: Dave Hansen Cc: Marc Orr , "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" X-Stat-Signature: 33ndh8ukpcq8otw64hiisyrsxtdxjdfs X-Rspamd-Queue-Id: 4F93D1600B2 X-Rspam-User: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=IU3rG809; spf=temperror (imf08.hostedemail.com: error in processing during lookup of pgonda@google.com: DNS error) smtp.mailfrom=pgonda@google.com; dmarc=temperror reason="query timed out" header.from=google.com (policy=temperror) X-Rspamd-Server: rspam02 X-HE-Tag: 1656090967-26063 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: >> > Peter, is your enter key broken? You seem to be typing all your text in >> > a single unreadable paragraph. Sorry I will try to format better in the future. >> > 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. That's right. Given that the first round of SNP guest patches are in but this work to support unaccepted memory for SNP is not we assume we will have distros that support SNP without this "unaccepted memory" feature. On Fri, Jun 24, 2022 at 11: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"? > Yes, I'm sorry I was mistaken. If FW uses unaccepted memory but the kernel doesn't support it the VM should still boot but will fail to utilize all of its given RAM. >> > 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. Providing customers with an easy to use product is a problem for us the cloud provider, encoding foot-guns doesn't sound like what's best for the user here. I wanted to bring this up here since it seems like a problem most vendors/users of SNP and TDX would run into. We can of course figure this out internally if no one else sees this as an issue.