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 73EE0C43334 for ; Fri, 24 Jun 2022 17:47:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 085E18E025A; Fri, 24 Jun 2022 13:47:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 00EB88E0244; Fri, 24 Jun 2022 13:47:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCBF18E025A; Fri, 24 Jun 2022 13:47:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C9A878E0244 for ; Fri, 24 Jun 2022 13:47:53 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id A695760830 for ; Fri, 24 Jun 2022 17:47:53 +0000 (UTC) X-FDA: 79613862426.07.849F172 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf01.hostedemail.com (Postfix) with ESMTP id CE15140018 for ; Fri, 24 Jun 2022 17:47:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656092872; x=1687628872; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=shiV5Ay7GQ2Tu/mMj01l+eBCIevTWE/G5toVrHbXBHM=; b=b4YYZo/tp+ZQfSP9Jtlhgr6d1fT6B9QfWeSKpAFe5yUycLkMOENaLh9d FuMYHn9NMbDRx+OQXiBc7y/koJvqsA8FZO5yAhtSXrTh2giq6XUxASgFS XAy4ujZnI9a8OTykvWb4auLe0WTQfjeSn4kHvpuQITztmKzTlCermgNyt VhYe2mBMttf6+GjgxxRgUvMDYwqXWa15ML5QwwHKKdXdQD7BUKvO116MX mbXd2VH+Amn/XPPZUrTmcyEZwvuHDClr82xOo/E9Ygly8JjMDn3Tlchvb irTt5U2TICKb27GVPlOTTVVkqmpmWhT+EPc2KEHfsM6D1SzbXcs3dl0uI g==; X-IronPort-AV: E=McAfee;i="6400,9594,10388"; a="278599408" X-IronPort-AV: E=Sophos;i="5.92,218,1650956400"; d="scan'208";a="278599408" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2022 10:47:45 -0700 X-IronPort-AV: E=Sophos;i="5.92,218,1650956400"; d="scan'208";a="731410181" Received: from mdedeogl-mobl.amr.corp.intel.com (HELO [10.209.126.186]) ([10.209.126.186]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2022 10:47:43 -0700 Message-ID: <1e7ad728-d796-c84d-b7ba-b96d8f9fcd0c@intel.com> Date: Fri, 24 Jun 2022 10:47:09 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory Content-Language: en-US To: Marc Orr Cc: Peter Gonda , "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 References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <5af19000-4482-7eb9-f158-0a461891f087@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656092873; a=rsa-sha256; cv=none; b=i6hUPzXCCeEWczUGELo1Ig5lUI+onNa1Qj+NCcDthpWLkS7DZQLnt/W1PVZoodmL1GhcFg 7cahl1wDmisqcGvamKWM9C6EPGGfeTX9guncr4ETyTxOGxm5j+1+3Elmp6k14FVA+l+EmG 6tgoxldWX0zw4kfrQR4jfzjdlpSh1Vg= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="b4YYZo/t"; spf=none (imf01.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656092873; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=EGWDGyrrQIL4AEMstHJtCfAVLeedRjNxRUNOHPRZxcE=; b=KAkNWIXFkKnbMeqbrI0F1L/yjoH1QUmmyH1zXR6RQChCTt5ky+J3UZHR2RIndj4E7Ae0zp /4mmzDYRbPn1lLuL9XtA3ojWtRhQHSQdsm0uMZzRuSY3zS9kYdn76PRrqZAMIiJ7cRlKow 1cfS8Nat7K7ezDIol60bfEoQejszX2I= X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: CE15140018 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="b4YYZo/t"; spf=none (imf01.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Stat-Signature: xdk4w35sak5ht4wq7mdshn8d78m8bd59 X-HE-Tag: 1656092872-682715 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 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. 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?