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 56B2EC433EF for ; Tue, 19 Jul 2022 21:37:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B79326B0072; Tue, 19 Jul 2022 17:37:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B28B06B0073; Tue, 19 Jul 2022 17:37:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9EFD46B0074; Tue, 19 Jul 2022 17:37:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 902916B0072 for ; Tue, 19 Jul 2022 17:37:34 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 649BD12036F for ; Tue, 19 Jul 2022 21:37:34 +0000 (UTC) X-FDA: 79705161228.28.6C0682D Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf15.hostedemail.com (Postfix) with ESMTP id 67657A007B for ; Tue, 19 Jul 2022 21:37:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658266653; x=1689802653; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=lZfxsCoZwidUXvUg1h38BCfji1GHOSEqDIubN9Z3IFE=; b=RCOHFXAfq7NghWi7PIZQKeH+NCKtVDEV+g255eSuk9bneL3Vr4HR8pix eASy4/UNpO74rNwdz/RBL+ov9vImRbzUrdgNPcmOs0tJHC7jHPXS+Uz9e C8AdQCk8Zapw5j8YY1X64jORzbEJudMyCFNUI3evrm2MuLG6hcXVYYwLn y6MsIGI0Lc6ykNtXFNqLEjCRQ+YYC2IaFX6lhAknTpv1ihGHFeUcxi8Tx wg6Y0EsNwM8gbs9PaK+OwDFt1muE1cRRFXQUv6/SaZLR0mrOXKP5fXY6E BjoTeqbaa5vXVv/0NADdCkY4g82GiOkwZk1kKqn9Fl1MsT9/Ezvy+PJNT g==; X-IronPort-AV: E=McAfee;i="6400,9594,10413"; a="350598685" X-IronPort-AV: E=Sophos;i="5.92,285,1650956400"; d="scan'208";a="350598685" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Jul 2022 14:35:50 -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 ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=RCOHFXAf; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf15.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.100) smtp.mailfrom=dave.hansen@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658266654; 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=zgdOM0wPW0ivyCAr+kbCmn0ubaFCxgd61DTDUsJxxuo=; b=noVu9ac3EQ/MDe0GVLXPYsBXzauPxBDpAu3SM0QLlIjpjejF9LbUlD7nyVky0fntZnixhS 6LfaeOIWwMF+D5UVADqDQ+jjyoiiTMc8UCgvS3WjPRslKOaxtlafhvgquRxNjdmZn3KDKO Y21HhddAjKan9yXrd20265cjMoX8U0U= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658266654; a=rsa-sha256; cv=none; b=ENo9/wPnQfzbGrJrDQKN2+EFtTjEmHgHO6cMhcfe24ol6zjJVNG2ahyzNkEFGNN0++kc2w UK7x3nmcReM9Q5P+Gw4L0tXljtTZgNziNIaHrk8Bib8gPeG6+Sha7knDv0cFQmB6cpqzFT DI/mtHz++Mge7waKQ03j3OyeGixUQ0o= X-Stat-Signature: czqzwyqs45txg8dbghpxdis5obegyntr X-Rspamd-Queue-Id: 67657A007B X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=RCOHFXAf; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf15.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.100) smtp.mailfrom=dave.hansen@intel.com X-Rspamd-Server: rspam11 X-HE-Tag: 1658266653-95920 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 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.