From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 853317C for ; Fri, 24 Jun 2022 18:14:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656094448; x=1687630448; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=YeV/d+4LsC7Rh9IZcGmWfqXWcLSrc2sIo/Y1Mv7nibY=; b=jEZk3K6haQjd9jA4uc5WEqqDnWUAKVQpGzpwiQcfoWjwLzvvsPv75nQk sn/9ukyF617zwuwPLxRwKNQoPb2OTN0huq+thXQ8dMf7yGNWYDHcyMu0Y y4i+K+5TFu0Xt4VoSfR4DNvOWNGQ2e2wjT4YWwbXzgTdxNP6kjUcmVtgZ UaUgBKFHMGPV/MDekblEsFcxwVpUhEjS1phHM3Ej4OErwHURkcSqFmy+h nVPjkoSP1//V6VbRMWWtFAqR/tbG5mXZc3AAPGVCemfL2+4PoeMwRRUb3 Vbm5MaGuCl8ax9CpJpqS/OIMipyOpjKNPZvDHAN7tGzts/cUNqBHFVq0t w==; X-IronPort-AV: E=McAfee;i="6400,9594,10388"; a="269793558" X-IronPort-AV: E=Sophos;i="5.92,218,1650956400"; d="scan'208";a="269793558" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.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 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: 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 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.