Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp4973225imw; Tue, 19 Jul 2022 17:39:26 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sVLb3BsMVrsK8a6wEUZr4+jVvbNCqRrJa1y8b7F5xfiusNH4+RRcd0a1/ZHVlky/4ywQ0o X-Received: by 2002:a05:6402:2b93:b0:43a:5aad:73c2 with SMTP id fj19-20020a0564022b9300b0043a5aad73c2mr5290139edb.300.1658277566347; Tue, 19 Jul 2022 17:39:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658277566; cv=none; d=google.com; s=arc-20160816; b=KBjiFSIO3qi1BVf/S3q9vaNh6YtntdmMqvd7it26gRiT+rsViGHJGM1J+/yQmpVOrV GCGilhRwZRIFHYTeLX/qoUzb6WXrBfqzp/Zh+8CTnAT3IAxhOAU3WsHa12rG6GTt/9co I2zuGKlrXydoPyFovyjmsyhiWqa2RyDrtCugs4LrM7FgdmJn+Npu3ZVeOupA+0bH8O6t G4am0yKiAtLjBAc9WXyJODBJ+dNzJ/1jqM9n7MKiAmdp8KO1GQzmlu2UBi2Vialeyl50 dwpRg6QgAGkG7c2bJ8N+r7VUmonu0XRObzl72KtLacaZVEkbrvP6m1ySCU0RNNWQmOI9 ux4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=AXFCfDqvLrq9o9WRcAb2bry5GNfeEVn8GlJpnRDObuY=; b=F4+ZKkLzc4JJpkex9lR3lMmwMCzv+6I0VrAETYm0dL78WJ6MevYz/5fgTNhwUJrelm 1ZNJIno93RPJoXP0iNFSabYycYvOokOcTGE/bXNDhIQFtBI5h01T/P43C12z4r24iAh1 w+RP38/Y8JVrSNlOtWfiRh/HqX/RC5q2F+ewn7zMvdlbVlNnsJU86YTfh0HNvYFxPMNc NSr3Kx1IZlHms1WJnIbSu0IznZ5/95Kre5jUyw8IYVW3w75+tbpuUIL5zDn56wmI9oq6 FRfzJ/HjczCmXSVnVupGLudFYUWja+uQJLiiQRcD2HJJ29PFIvkPqmsiG1e/nlMOk8r/ UMtA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="hpR/vH1V"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mp33-20020a1709071b2100b006ff8cd702e8si22483022ejc.29.2022.07.19.17.38.52; Tue, 19 Jul 2022 17:39:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="hpR/vH1V"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235832AbiGTA0f (ORCPT + 99 others); Tue, 19 Jul 2022 20:26:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231709AbiGTA0e (ORCPT ); Tue, 19 Jul 2022 20:26:34 -0400 Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB7E237FBA for ; Tue, 19 Jul 2022 17:26:33 -0700 (PDT) Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-31caffa4a45so157941207b3.3 for ; Tue, 19 Jul 2022 17:26:33 -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=AXFCfDqvLrq9o9WRcAb2bry5GNfeEVn8GlJpnRDObuY=; b=hpR/vH1V8plhuaqeiB0LitY272ggX3bQv0nXd6Y1BK7Bwal8MhI8mqq1jAQjbvj/Wo O+/3MIyG9XbRVzS8JgrWNKl87KDU6Eq1+d1hFiW/qgjlFVU/J2bUcja0vmliWIdV5cuy GLJRr5o1CbYd4rnWtvQyI+ssrUm7QlB+1im8tGLur7pQHEb16hOL5YLtLdcWkvaBrqGN ruD1N7GI152c4a0egyQ0lm3qMW8V5wX3VU1CVrCka/cNse9swyafctm8jQaUghqoZjUS ijtU/SJd0WILD2FWaGsfSjESFK4FhyzJ4ayaWMpNsX4UC6eKmD70XnRuMyaoaZu5tHTK 29UA== 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=AXFCfDqvLrq9o9WRcAb2bry5GNfeEVn8GlJpnRDObuY=; b=jAfy0zVEa/U8W/xMEa2NeATKrSkQ5Gg3M9ns9WH/V5lJ4zW14+aS0X7xbcYotFOoRD Yb1AeiO0JTpyetYwbXRQUqTyWhrNOPwaxUHnuJkK5UT0hbPLsuYVY1lqMhi6ZyOthx4d ztyWsE/kWhiPaKYPSlBfPpnW1weG31q7YlYm8WhlpmB52hHLm7RYEMx/c8ywzskdieVT YzmehgFpIN/0wpghZftertVkAGwp/5Awqv6vMSQZcjReYhfMtkQwwiBQlb/ibWCZMaT8 4mxgd0s1eWNfskxxJTB9owsfnKVSw0teQqOpbf8MIGuqZEOyMaKCHk6416P1I5Fcjvor JrCQ== X-Gm-Message-State: AJIora9NVZIFQvixkZn/NwYZqUvYv8N3gfw7tbDZl8pZ9dIgiKRb/ZtT PNGypkmzGsXn7pma7Pn+b124qO8A309ZRsWv/AuRog== X-Received: by 2002:a81:49c6:0:b0:31c:7f19:a5f0 with SMTP id w189-20020a8149c6000000b0031c7f19a5f0mr38675292ywa.385.1658276792919; Tue, 19 Jul 2022 17:26:32 -0700 (PDT) MIME-Version: 1.0 References: <20220627223808.ihgy3epdx6ofll43@black.fi.intel.com> <20220718172159.4vwjzrfthelovcty@black.fi.intel.com> <22d54786-bc12-ecc5-2b37-cbaa56090aa8@intel.com> In-Reply-To: <22d54786-bc12-ecc5-2b37-cbaa56090aa8@intel.com> From: Marc Orr Date: Tue, 19 Jul 2022 17:26:21 -0700 Message-ID: Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory To: Dave Hansen Cc: Borislav Petkov , Ard Biesheuvel , Dionna Amalie Glaze , "Kirill A. Shutemov" , Peter Gonda , 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 , Mike Rapoport , David Hildenbrand , Marcelo Cerri , tim.gardner@canonical.com, Khalid ElMously , philip.cox@canonical.com, "the arch/x86 maintainers" , Linux Memory Management List , linux-coco@lists.linux.dev, linux-efi , LKML , "Yao, Jiewen" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 19, 2022 at 3:02 PM Dave Hansen wrote: > > On 7/19/22 14:50, Borislav Petkov wrote: > > On Tue, Jul 19, 2022 at 02:35:45PM -0700, Dave Hansen wrote: > >> They're trying to design something that can (forever) handle guests that > >> might not be able to accept memory. > > Wait, what? > > > > If you can't modify those guests to teach them to accept memory, how do > > you add TDX or SNP guest support to them? > > Mainline today, for instance, doesn't have unaccepted memory support for > TDX or SEV-SNP guests. But, they both still boot fine because folks > either configure it on the host side not to *have* any unaccepted > memory. Or, they just live with the small (4GB??) amount of > pre-accepted memory, which is fine for testing things. For us (Google cloud), "1. Deal with that at the host level configuration" looks like: https://cloud.google.com/compute/docs/images/create-delete-deprecate-private-images#guest-os-features In other words, we have to tag images with "feature tags" to distinguish which images have kernels that support which features. Part of the reason we need to do it this way is that we use a single guest firmware (i.e., guest UEFI) that lives outside of the image. These feature tags are a mess to keep track of. All that being said, I can totally see the upstream perspective being "not our problem". It's hard to argue with that :-). A few more thoughts: - If the guest-side patches weren't upstream before this patch set to handle unaccepted memory, you're all definitely right, that this isn't a real issue. (Maybe it still isn't...) - Do we anticipate (many) more features for confidential compute in the future that require code in both the guest FW and guest kernel? If yes, then designing a FW-kernel feature negotiation could be useful beyond this situation. - Dave's suggestion to "2. Boot some intermediate thing like a bootloader that does acceptance ..." is pretty clever! So if upstream thinks this FW-kernel negotiation is not a good direction, maybe we (Google) can pursue this idea to avoid introducing yet another tag on our images. Thank you all for this discussion. Thanks, Marc