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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37F0CC43334 for ; Tue, 19 Jul 2022 21:37:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238416AbiGSVg6 (ORCPT ); Tue, 19 Jul 2022 17:36:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239758AbiGSVgy (ORCPT ); Tue, 19 Jul 2022 17:36:54 -0400 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1BD205C343; Tue, 19 Jul 2022 14:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658266614; x=1689802614; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=lZfxsCoZwidUXvUg1h38BCfji1GHOSEqDIubN9Z3IFE=; b=TtVDgTX2aNKX+WBJlsBLmOusKL3LgkIdb9dReAcUjpRMidATh4vxBVzM +EhEmFuxYP+zHr55nS9t1guguoacQlNKp/FwELwB6qF4q25dkXHO1Leps 1CygA7v1E9ivn+klNXMPcxhxfc1TyNY4Q/J2MFaI3JKJm4F76ix1KLHvC rT1YMjlTmQ+TDaV0NuDIb0ScDGXwsdQfhieyHaSUj44XT26vru9i/tPb9 jxHjyPMOxkUAuyxQKB185fn8rkqw7XLrgN7epIhj43h2XjznUNlT5VnVd leQaIdTMk+aqFipQEiX0htjQ2AoFlnO5n+gKespYI0lSMisXrUcBAARmR A==; X-IronPort-AV: E=McAfee;i="6400,9594,10413"; a="372916179" X-IronPort-AV: E=Sophos;i="5.92,285,1650956400"; d="scan'208";a="372916179" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jul 2022 14:35:48 -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 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.