From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 3AACC3229 for ; Mon, 27 Jun 2022 22:38:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656369491; x=1687905491; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=t0fJ1EB2Kg/aNY0pT1VtDftqiRsIkXLbIkW27zDJlwM=; b=CPfbATmW9Zm4BzAXi/M9FkdC7vqEH2pG5wki+TdWq/UGQ0a70ZAC9HnM 148LLZ5N/72El+mwU9f72IGXRsJgQnrPoNHNVpeu7e93z8PDZUxR/91Cd pgIb5+1+JLDhJGpgJ3Kt97zRmOWKgtxeh9tBRAG8CJfksNC07xIUWPxtG 4d31HdQ5R4WCyLX477zpTb1CrHBtLG5coLTwTG/RpTAi9aHFpypzPTuQL Q9u8E46bwYmznBOeql6u5v8/Oll6mdaK0IrfyQ0veSMAuOJwlZBo0U6Et JyK5D19FaGF1kYSxJsWfGG+zZDgccRK5eJ1wFfKfs4fYei5oRQJy/onXh g==; X-IronPort-AV: E=McAfee;i="6400,9594,10391"; a="279123455" X-IronPort-AV: E=Sophos;i="5.92,227,1650956400"; d="scan'208";a="279123455" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jun 2022 15:38:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,227,1650956400"; d="scan'208";a="766943905" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga005.jf.intel.com with ESMTP; 27 Jun 2022 15:38:03 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 1AEF7D9; Tue, 28 Jun 2022 01:38:08 +0300 (EEST) Date: Tue, 28 Jun 2022 01:38:08 +0300 From: "Kirill A. Shutemov" To: Ard Biesheuvel Cc: Peter Gonda , Borislav Petkov , 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 , Dave Hansen , 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 Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory Message-ID: <20220627223808.ihgy3epdx6ofll43@black.fi.intel.com> References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <20220627113019.3q62luiay7izhehr@black.fi.intel.com> <20220627122230.7eetepoufd5w3lxd@black.fi.intel.com> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Jun 27, 2022 at 06:33:51PM +0200, Ard Biesheuvel wrote: > > > > > > > > > > Just as an idea, we can put info into UTS_VERSION which can be read from > > > > > the built bzImage. We have info on SMP and preeption there already. > > > > > > > > > > > > > Instead of hacking this into the binary, couldn't we define a protocol > > > > that the kernel will call from the EFI stub (before EBS()) to identify > > > > itself as an image that understands unaccepted memory, and knows how > > > > to deal with it? > > > > > > > > That way, the firmware can accept all the memory on behalf of the OS > > > > at ExitBootServices() time, unless the OS has indicated there is no > > > > need to do so. > > > > > > I agree it would be better. But I think it would require change to EFI > > > spec, no? > > > > Could this somehow be amended on to the UEFI Specification version 2.9 > > change which added all of the unaccepted memory features? > > > > Why would this need a change in the EFI spec? Not every EFI protocol > needs to be in the spec. My EFI knowledge is shallow. Do we do this in other cases? -- Kirill A. Shutemov