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 5EEE3C43334 for ; Wed, 20 Jul 2022 00:26:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B91F76B0072; Tue, 19 Jul 2022 20:26:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B19E26B0073; Tue, 19 Jul 2022 20:26:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 994976B0074; Tue, 19 Jul 2022 20:26:34 -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 8437E6B0072 for ; Tue, 19 Jul 2022 20:26:34 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 458A312040A for ; Wed, 20 Jul 2022 00:26:34 +0000 (UTC) X-FDA: 79705587108.24.9619051 Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) by imf20.hostedemail.com (Postfix) with ESMTP id DB25E1C0006 for ; Wed, 20 Jul 2022 00:26:33 +0000 (UTC) Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-2ef5380669cso157688237b3.9 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=Ug8hxAWMV0cUXSH2sTGOmbgwTzlmdCzRjOUoR5JoUJ/dSbFnDtm6Xd3JOpYLH5RO4U tDulSkNEO1inYt1cgxYby0ekqCG1uvqO5jZ98g050aBHzbaDSk4vi2P284Ss1bEIPSZJ pNs0WbBG5z2RqdZWyUWQKarwqztk3NgOBuBGMGxYCQKPcP6d+ho89C9ncCRZL0BMBMLK yE6uUH8z7CIIaT3bmmddUUu/E0dxoJurni98iV+5lpPS7vuos6cbW/GkFk718sJuOKiu qwpgsbTMbnMqgBupiBFUH1SlTIAKmsEPNr0IQqKpMG0IbKhLuQ1XQ4h6ED1ebn33rBF2 xBJg== X-Gm-Message-State: AJIora8Mkwg0ZXD5cN9h3p61f7h8fvQ2YrUGSly7evKGHy/9Uc/owpZJ IwQQepSyuq3WaK6iRd+WE9qQvOVVvt10xLv4JXFmEQ== X-Google-Smtp-Source: AGRyM1ucYfvEDqy8c2bJqjvjQcMSu4rDtbwnmg0DLGP5d4Yvdv55/Fz6kUTxYLVBWG5VR5+ybBgntVeWxP1KiCKRMVk= 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" ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="hpR/vH1V"; spf=pass (imf20.hostedemail.com: domain of marcorr@google.com designates 209.85.128.173 as permitted sender) smtp.mailfrom=marcorr@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658276793; 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=AXFCfDqvLrq9o9WRcAb2bry5GNfeEVn8GlJpnRDObuY=; b=B+KaQ4KNqADdlyFXCIIk+77LECveTrFmMuSMrKUlcbqC70fHNHvkoM9o2eHzFwzsUNvS7Z GfecQLQ5yLJDkL9rCmAJdpFSaQYxpdjwoQYumQyDE+kG8HnayWass+K5WbjfzgFzjNzPga 5ltl8duOqr1cjqzC+d/EdnDZ4uaonE8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658276793; a=rsa-sha256; cv=none; b=aHDLwUEoqLd8HCGLdGJpcxB9UINmKdfn02BOuScccaF3BjGo/vnd/8WXd3KczUIrQtt6Fi SU192LCdlG3zTtFJM4qGA+AbSVHaJBWeh+G3ecx12B78vmeOTJKOq7yQglgC3QHCVyUVV4 mA5BlltzEZhCLP2imHIT8kNYIZD1k5s= X-Rspam-User: X-Rspamd-Queue-Id: DB25E1C0006 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="hpR/vH1V"; spf=pass (imf20.hostedemail.com: domain of marcorr@google.com designates 209.85.128.173 as permitted sender) smtp.mailfrom=marcorr@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: rxk3a16ai1m6dgqp3khxgop4e5ao7ty4 X-Rspamd-Server: rspam07 X-HE-Tag: 1658276793-359097 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 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