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 6BCC5C43334 for ; Fri, 24 Jun 2022 18:10:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B3DFD8E025D; Fri, 24 Jun 2022 14:10:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC5C08E0244; Fri, 24 Jun 2022 14:10:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 93F168E025D; Fri, 24 Jun 2022 14:10:19 -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 7D8838E0244 for ; Fri, 24 Jun 2022 14:10:19 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4F4D3650 for ; Fri, 24 Jun 2022 18:10:19 +0000 (UTC) X-FDA: 79613918958.01.A51938E Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf19.hostedemail.com (Postfix) with ESMTP id D9DA01A0011 for ; Fri, 24 Jun 2022 18:10:18 +0000 (UTC) Received: by mail-lf1-f44.google.com with SMTP id c2so5894327lfk.0 for ; Fri, 24 Jun 2022 11:10:18 -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=hcN3XwIcZstb9s64xvU12TX0znKfRFFze9XJS0Qbx3c=; b=i388ivDFxBMUiQA7obdzFBcEsHyr2kSx+7nBsDjM07lnEAK/xcdqGFSUgzgUY2x5hz DEXehsWQSvUsV1Imkd8PWGjk00nG59mSuOc1lCrJJBgRYyUpD1jYVMip2WU88Ju3wXQC 9mMUu5erd6kQecAreB6NiXoTvzd9EWpyT6+hFRSjep65bDfex49cbaRobzUMHHHZ0Z84 eXEGdW5cEkmpQdRIfZYO6ikD12SduftZiMeR9H+O6dCGKcrFYtydLGHlB5ozixdcHDZo Sofuo2cji7slhGZ5UqgKB7QK/oxD3m0HAUfdsQDFVoue1IcLToG3jzOqCB83xL9+874H Tl3Q== 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=hcN3XwIcZstb9s64xvU12TX0znKfRFFze9XJS0Qbx3c=; b=YScXuq/jqpVFrqvmZDBmXHil4fK8mjbrMjEfJ0PaimL8mean/Q2HWXp3qUD+iZhvNW 4mWHz7uRUQ3310b0sc8+u8xnaBxVOBOMktJVlx3MJqt9pdsi0J07AGOND9nXvIcFP7Ug lFUpfR6sAF1VsiXd1U53LmMjAyql65cTSbSb2SsDgkMNmp69oCXX32a5wskRE0qwM7L3 Rd51YtU9xsTKmuodsIvdCyDJdsYONDM6/P4gZsL/8KMQ/rrc6qvsVZGV5Zg1oL0IQCQ7 +DFgmaPvzrn37wn4EFvsbsyObvSu0oogZ67rnBTsxleKuG8BkVN4jToBz0A25K6U4sHd zdxQ== X-Gm-Message-State: AJIora/68aUJb517AEIBz120FltldwqzkhT/zpJfozW76ZVsrj74Tva9 8gnUJiEqT0QRb+m3ScXIBiQr5hzYvlkNEI3SbwJ5/g== X-Google-Smtp-Source: AGRyM1tdkubN4l5CrWuEurB1wstbops6ikfefa6G3OKJ5WraDCy19/A/YOyuGj3Y9SbrsN+Oqd+6FVxlMDlWtFoEghE= X-Received: by 2002:ac2:5974:0:b0:47f:92db:4480 with SMTP id h20-20020ac25974000000b0047f92db4480mr59927lfp.685.1656094217190; Fri, 24 Jun 2022 11:10:17 -0700 (PDT) MIME-Version: 1.0 References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <5af19000-4482-7eb9-f158-0a461891f087@intel.com> <1e7ad728-d796-c84d-b7ba-b96d8f9fcd0c@intel.com> In-Reply-To: <1e7ad728-d796-c84d-b7ba-b96d8f9fcd0c@intel.com> From: Peter Gonda Date: Fri, 24 Jun 2022 12:10:05 -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" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656094218; a=rsa-sha256; cv=none; b=r2ONXHOlicqzybyBzwBDLJ0IkuxfcpvW7TjPHEe6lDe+Zb9FNrg92QyX27J4httb6qrOms SA4fbawpBV0CrGy1bTy5l5PXGvApvJT38Z3AegagMlsNYJhFeo/15EOkwc5LeknIrsVRgd jCtfWJO8P3hZSY9NoY5sYkdJ0it2zx8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=i388ivDF; spf=pass (imf19.hostedemail.com: domain of pgonda@google.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=pgonda@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=1656094218; 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=hcN3XwIcZstb9s64xvU12TX0znKfRFFze9XJS0Qbx3c=; b=mwFDO2bX+XZLf4kJOkl8MD2f0Sq6w6ywMFwqfASurRszEElcR3RZsuqVQMkK+4uBDAbB8x 3TdgcrfoyhO2kX2ngeDeJcGvTeix1pBOFitaQI8tWBk8NaOyz9b2H1SHoPcKwNaKJ/U3mP E6lNYvsQT9G954dEp8I3kwCMgXetxGE= X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: D9DA01A0011 Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=i388ivDF; spf=pass (imf19.hostedemail.com: domain of pgonda@google.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=pgonda@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Stat-Signature: q3dga97h5yywts3zxcx11iar3nssupu4 X-HE-Tag: 1656094218-825365 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:47 AM Dave Hansen wrote: > > On 6/24/22 10:19, Marc Orr wrote: > >> 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. > > They'll at least be a _bit_ less angry and frustrated than if they were > staring at a blank screen. ;) But, yeah, I totally get the point. Ha! Well we do have that issue in some cases. If you try to run an SEV VM with an image that doesn't support SEV you will just get a blank serial screen. If we had something like this back then the FW could have surfaced a nice error to the user but that's history now. > > How big is the window going to be where we have guests that can have > unaccepted memory, but don't have acceptance support? For TDX, it's > looking like it'll probably _just_ be 5.19. Is TDX on 5.19 in shape > that cloud providers can deploy it? Or, is stuff like lack of > attestation a deal breaker? This is complicated because distros don't run upstream linux versions. If I understand correctly (I see some distro emails on here so please correct me) distros normally maintain forks which they backport things into. So I cannot answer this question. It is possible that a hypothetical distro backports only the SNP/TDX initial patches and doesn't take these for many releases. I am more familiar with SNP and it does have some attestation support in the first patch sets. Also I should have been more clear. I don't want to try and hold up this feature but instead discuss a future usability add-on feature. > >