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 D9205C433EF for ; Tue, 19 Jul 2022 21:51:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3DC596B0072; Tue, 19 Jul 2022 17:51:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 38C396B0073; Tue, 19 Jul 2022 17:51:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2539B6B0074; Tue, 19 Jul 2022 17:51:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 15BCD6B0072 for ; Tue, 19 Jul 2022 17:51:08 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D6A96C02D3 for ; Tue, 19 Jul 2022 21:51:07 +0000 (UTC) X-FDA: 79705195374.03.64272B1 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf05.hostedemail.com (Postfix) with ESMTP id 3B314100069 for ; Tue, 19 Jul 2022 21:51:07 +0000 (UTC) Received: from zn.tnic (p200300ea97297609329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9729:7609:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 9B7301EC0645; Tue, 19 Jul 2022 23:51:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1658267461; h=from:from: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; bh=RiLRSeSrQbdMG2zQCqhnnPnmcRmrvC4CXHKDD5x+nVw=; b=hiCRIz2M+wi07p91BD9LK8bIexysFg9QoRVs5JmpL35MTXXCvCLiMLaulnJEKVj3fURGNF rHSHSsauaNe8BSd93KjcwtyB5cY3MkeqYoNU7bNOhpex7K0HvwpSXxDwpY6IzywYQSemv9 nLaNM9g+XIpBA/eYS4hizIgojlpANOM= Date: Tue, 19 Jul 2022 23:50:57 +0200 From: Borislav Petkov To: Dave Hansen Cc: Ard Biesheuvel , Dionna Amalie Glaze , "Kirill A. Shutemov" , Peter Gonda , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , 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 Cerri , tim.gardner@canonical.com, Khalid ElMously , philip.cox@canonical.com, the arch/x86 maintainers , Linux Memory Management List , linux-coco@lists.linux.dev, linux-efi , LKML , "Yao, Jiewen" Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory Message-ID: References: <20220627223808.ihgy3epdx6ofll43@black.fi.intel.com> <20220718172159.4vwjzrfthelovcty@black.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=hiCRIz2M; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf05.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658267467; 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=RiLRSeSrQbdMG2zQCqhnnPnmcRmrvC4CXHKDD5x+nVw=; b=5L13Ttx9AqlgSG/AMDd0kZZVxWtwsUCCOWaOZmoAp8mh8ACPgx3QcjRYTjPglvQXcD7g4l nqkdhxGK6ue3zLCdAA3q06iPCGwStuPYsQEi0uRhlRYYQfw+hrXCwTSSd3kvJsJeqp/EaB pg7bLH//vqt7GK0N7dPLqu1rrfvbLgc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658267467; a=rsa-sha256; cv=none; b=e7sbtZ4wLPo6V2F4eYgh0+vEBu3fT4WpVLwvMHZyYDfhGnB16VvhTYwq2ZYNl6XHDQuMKm A9lUR4AhjLkPtjz2pYA3WSalSvmhYz5CJ5slHU+gtSqPJyTTghzhm07qNPToTMjnz2Nfgo 0+LCrYz36klecMINfrpLUrl55+eR6qQ= X-Rspamd-Queue-Id: 3B314100069 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=hiCRIz2M; dmarc=pass (policy=none) header.from=alien8.de; spf=pass (imf05.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: ks4eeojr48gtdgbjxwqd36curug336kx X-HE-Tag: 1658267467-553400 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 Tue, Jul 19, 2022 at 02:35:45PM -0700, Dave Hansen wrote: > They're trying to design something that can (forever) handle guests that > might not be able to accept memory. Wait, what? If you can't modify those guests to teach them to accept memory, how do you add TDX or SNP guest support to them? I.e., you need to modify the guests and then you can add memory acceptance. Basically, your point below... > It's based on the idea that *something* needs to assume control and > EFI doesn't have enough information to assume control. > > I wish we didn't need all this complexity, though. > > There are three entities that can influence how much memory is accepted: > > 1. The host > 2. The guest firmware > 3. The guest kernel (or bootloader or something after the firmware) > > This whole thread is about how #2 and #3 talk to each other and make > sure *someone* does it. > > I kinda think we should just take the guest firmware out of the picture. > There are only going to be a few versions of the kernel that can boot > under TDX (or SEV-SNP) and *can't* handle unaccepted memory. It seems a > bit silly to design this whole interface for a few versions of the OS > that TDX folks tell me can't be used anyway. > > I think we should just say if you want to run an OS that doesn't have > unaccepted memory support, you can either: > > 1. Deal with that at the host level configuration > 2. Boot some intermediate thing like a bootloader that does acceptance > before running the stupid^Wunenlightended OS > 3. Live with the 4GB of pre-accepted memory you get with no OS work. > > Yeah, this isn't convenient for some hosts. But, really, this is > preferable to doing an EFI/OS dance until the end of time. Ack. Definitely. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette