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 9690CC433EF for ; Fri, 24 Jun 2022 18:14:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 23DA38E025E; Fri, 24 Jun 2022 14:14:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EEAD8E0244; Fri, 24 Jun 2022 14:14:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 08F8F8E025E; Fri, 24 Jun 2022 14:14:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id EA05F8E0244 for ; Fri, 24 Jun 2022 14:14:11 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id BF9796066B for ; Fri, 24 Jun 2022 18:14:11 +0000 (UTC) X-FDA: 79613928702.17.6A05A95 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf18.hostedemail.com (Postfix) with ESMTP id D55BB1C0096 for ; Fri, 24 Jun 2022 18:14:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656094450; x=1687630450; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=YeV/d+4LsC7Rh9IZcGmWfqXWcLSrc2sIo/Y1Mv7nibY=; b=Hwil9CpyNJDm+H8A24/+EwglgOq7fprc3XJtL8uO4pbsnqrAtlltV9je YTpRyLhQHci2eeIibp2349LEOsm7+hu2NdQOAftzcHsTisGuDMC1B0PqN ulk1EO8qI6YbSZ1ISBN3ghibkS9MdDglfYDEJ0kR4tRP0aiIxgRA4rC+O b/SnlF5wk4c5sH4EQ+NIcT1EiYUF+dLtH/O71IXybq8Y/nwL0+gAxW08V UBHIcHIs3CxJxFGBkn/2aWbXj/lULWKa8WHMQvmP1oK7iXEV0EyTcEqaE 2JTQ1pUNny4bvLBVD7VLe28h8LnRzsbWhIWekCaHs5c9eE6bqH6FuY0dI w==; X-IronPort-AV: E=McAfee;i="6400,9594,10388"; a="264102025" X-IronPort-AV: E=Sophos;i="5.92,218,1650956400"; d="scan'208";a="264102025" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2022 11:14:07 -0700 X-IronPort-AV: E=Sophos;i="5.92,218,1650956400"; d="scan'208";a="731418689" 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 11:14:05 -0700 Message-ID: Date: Fri, 24 Jun 2022 11:13:30 -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: Peter Gonda 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 References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <5af19000-4482-7eb9-f158-0a461891f087@intel.com> <1e7ad728-d796-c84d-b7ba-b96d8f9fcd0c@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Hwil9Cpy; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf18.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=dave.hansen@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656094450; a=rsa-sha256; cv=none; b=1yySNP0FutBYEMqT+wYVGXXUQKQCpBl7zvXBRAqv3aAq+VrQVVyvhq0wuFVj0HSCPBJNbq X+tD2nbWT6+xMdGyra1yAKl49UgvVKd8sP4JoAW0heS+ISTmS4E9Cow2Ml0v0mzINPB5Z1 paGAEpB8zQQemUQz9IUm3FbqTVwJHBs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656094450; 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=fuSOFbs1yD49rU0jJT6lBsJbR7XhEHn4XjdQfAwjJp8=; b=QaoTBfS1XQwFqd9HekCkj3j8VtQJhEuxsAg6fM6G3gt51MJTA2fYbYLPfb8/g9NC8sEwr2 lCItHZxWxEVDZ4fvshmQc5el3glJuuSmNgdEbkDXxS2KbyfXI7GLtQ9r4eP7NNWT0AMCLC XWkVcAuYiVbG3miOM9EovZM+YF7Lmlc= X-Stat-Signature: cgf3h7qzjsqdc76neyns9fezz5pj9oyk X-Rspamd-Server: rspam08 X-Rspam-User: X-Rspamd-Queue-Id: D55BB1C0096 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Hwil9Cpy; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf18.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=dave.hansen@intel.com X-HE-Tag: 1656094449-544780 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 11:10, Peter Gonda wrote: >> 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. Distros could also backport a bare-bones version of this set that doesn't do anything fancy and just synchronously accepts the memory at boot. No bitmap, no page allocator changes. It'll slow boot down, but is better than having no RAM.