From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 496997C for ; Fri, 24 Jun 2022 17:47:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656092866; x=1687628866; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=shiV5Ay7GQ2Tu/mMj01l+eBCIevTWE/G5toVrHbXBHM=; b=btafN/P26gOL70qYu3508Depm7xGwVB1BOuS/OEjzauNePbkvmfzkVHH pEyg7Slr9Xw9YOKSvn0pozNlmrc4MQ6OGZQ5hH/27pZP+x0lclSU1x4wl pE1Qi+WThdR3pLcbXY13fZqTzW0Y/L8pb0puxI4LxCEVYg+d7YchIJXG+ LXtLSpsdP72vWgirQYnmvD0DLOvE9D/cT3RB7RPPTa76J9fjA8hA6BQR6 jVr1S6jeYqSD9IiOGD5aO/vnlOUtWmC9PNw6lFAmnuVwzygeXA76KSyQ+ soEXTcLBND8HgJ2VNQti54d46NIBWDbSiEH/vpw07K2tLLAjQRGYwDsEa A==; X-IronPort-AV: E=McAfee;i="6400,9594,10388"; a="261476089" X-IronPort-AV: E=Sophos;i="5.92,218,1650956400"; d="scan'208";a="261476089" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga107.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 Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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 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?