From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 F37554C75 for ; Tue, 19 Jul 2022 21:39:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658266747; x=1689802747; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=lZfxsCoZwidUXvUg1h38BCfji1GHOSEqDIubN9Z3IFE=; b=LuVjm/E1Ate/De+fSQE6GnDR3XEPQddQIM1fGDQ92xqQbt9gsVN5kS09 Y48sJj9lJ3avBxIRfM2oTuJhHuDOch/lYs2vK8pKmtIvBHXlmoZZ7JA7V lSLmbd6kCO4OlmuhkqFyl7WOdgEeI7ceqMnEUOpe1ALJ/07Ll+Qil1CJi vryxUnfuO7Icq/wisv8+f5sdWdLzFq4Qy7sn6obadNEKS0KhwiRk6v5YM E4OJDV9y5uP4FCIZ4TsUDSFCouLWua0lsnjVCgVwlFkOf4DYhFl7Ypeq9 dtj/Qz8i0047K3/JnnQRm4aN1XFvgjgCRrlYiTuLlyR6VAHEJukkn2aCY A==; X-IronPort-AV: E=McAfee;i="6400,9594,10413"; a="312306308" X-IronPort-AV: E=Sophos;i="5.92,285,1650956400"; d="scan'208";a="312306308" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jul 2022 14:35:47 -0700 X-IronPort-AV: E=Sophos;i="5.92,285,1650956400"; d="scan'208";a="687272611" Received: from twliston-mobl1.amr.corp.intel.com (HELO [10.212.132.190]) ([10.212.132.190]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jul 2022 14:35:45 -0700 Message-ID: Date: Tue, 19 Jul 2022 14:35:45 -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: Borislav Petkov , Ard Biesheuvel Cc: 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" References: <20220627223808.ihgy3epdx6ofll43@black.fi.intel.com> <20220718172159.4vwjzrfthelovcty@black.fi.intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 7/19/22 14:23, Borislav Petkov wrote: > On Tue, Jul 19, 2022 at 10:45:06PM +0200, Ard Biesheuvel wrote: >> So let's define a way for the EFI stub to signal to the firmware >> (before EBS()) that it will take control of accepting memory. The >> 'bootloader that calls EBS()' case can invent something along the >> lines of what has been proposed in this thread to infer the >> capabilities of the kernel (and decide what to signal to the >> firmware). But we have no need for this additional complexity on >> Linux. > To tell you the truth, I've been perusing this thread from the sidelines > and am wondering why does this need this special dance at all? > > If EFI takes control of accepting memory, then when the guest kernel > boots, it'll find all memory accepted and not do anything. > > If EFI doesn't accept memory, then the guest kernel will boot and do the > accepting itself. > > So either I'm missing something or we're overengineering this for no > good reason... They're trying to design something that can (forever) handle guests that might not be able to accept memory. 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.