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 153EDC43334 for ; Tue, 28 Jun 2022 17:17:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 89A966B0071; Tue, 28 Jun 2022 13:17:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 84ADF8E0005; Tue, 28 Jun 2022 13:17:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 713258E0001; Tue, 28 Jun 2022 13:17:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 630426B0071 for ; Tue, 28 Jun 2022 13:17:15 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3AF83608E3 for ; Tue, 28 Jun 2022 17:17:15 +0000 (UTC) X-FDA: 79628300430.24.D1A5012 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf07.hostedemail.com (Postfix) with ESMTP id 6C57C400A2 for ; Tue, 28 Jun 2022 17:17:14 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A2D636191F for ; Tue, 28 Jun 2022 17:17:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 12BCAC3411D for ; Tue, 28 Jun 2022 17:17:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1656436633; bh=usxaCMDh/Kg4ZK2P/XBDr6Ic3D5rTWyFphZ3cTcB6/4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=QFUc7IWGaq6zAHxv+aizLOigiBCl2YkN5uV508xzGBlOEm+dPAVHYQ26KOcWSEbtR jocVZVPBGzYiMe7jj2wKX9SDjPU9cMGvEeYNrwkleeKZA+xAtw0OTUTreAqSUtlBmJ 1rAP0EGUqPn60FCv3qd67fDPInobFph2AYLHQJUoNukNHgeBGCuZyN02LCBXzbG5QI +C8mMV6g/KDVWOc9PJQVxdznZYo+EKOpR+XhNNCnGdmvUJRsvbge9rZZJBkrIT6Tm1 QM6Sjxf3Q98rk4aSRzbyzVci6KmuST4pFGbHCqQ02gV/HNTVI9fkbjfG01gv6nTY2k X5C1iOuMpyTtA== Received: by mail-oi1-f173.google.com with SMTP id r82so9386926oig.2 for ; Tue, 28 Jun 2022 10:17:13 -0700 (PDT) X-Gm-Message-State: AJIora+EDyJqf8XBQOrMRJiAwNoMkDWJWP2EDsPLb1s9pgyM830q6Mli 3BTYlK0Nf55KyBiYmn1N5cmKxYeOClDsa81AZNA= X-Google-Smtp-Source: AGRyM1uO0YWjWyCv1x123jP8A9Qhqpz+q8tixxDZLG2jp9eg0NDSehl7NyZDgaKJIJwRmATEZ+y0Qn5hTDIhHYRqYc4= X-Received: by 2002:a05:6808:13c6:b0:335:3e54:94bc with SMTP id d6-20020a05680813c600b003353e5494bcmr421842oiw.228.1656436632278; Tue, 28 Jun 2022 10:17:12 -0700 (PDT) MIME-Version: 1.0 References: <20220614120231.48165-1-kirill.shutemov@linux.intel.com> <20220627113019.3q62luiay7izhehr@black.fi.intel.com> <20220627122230.7eetepoufd5w3lxd@black.fi.intel.com> <20220627223808.ihgy3epdx6ofll43@black.fi.intel.com> In-Reply-To: <20220627223808.ihgy3epdx6ofll43@black.fi.intel.com> From: Ard Biesheuvel Date: Tue, 28 Jun 2022 19:17:00 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory To: "Kirill A. Shutemov" 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 Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656436634; a=rsa-sha256; cv=none; b=6s4fbdszBEq8g912lWmjZX/6+K0cp699It5vY63aTsXWGqMBhghkddAF+GlHf5xk6mfQh5 hbqqbThA9O43e2KHtHkpoEcNmBSp/+BxuMHNYZ3xGf7UWgiMEyUWG2KVTDPuriV5AwBdfC lNVqLeUGz7Itp60O9Zcu1ruoTt5spmQ= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QFUc7IWG; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf07.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656436634; 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=usxaCMDh/Kg4ZK2P/XBDr6Ic3D5rTWyFphZ3cTcB6/4=; b=AzRhGDKL2UUVaNYZeQLJy8uRjOnISAlYsUEZEoHMTyJLnsUxjxhBkB/jWHxoVOFlc7ryva mNyAwA+7SqGTQzOSTaBG465uwAyO57EUxz7jYniRhy3eqZpXVLR5lvPSTkoOsqoldRX/zR EXSmQfVp/weYY22QbQ9OvNzaXgxhIGA= X-Stat-Signature: 9ca7mgpmfr8xid5ttt94ffhji39ecgp6 X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 6C57C400A2 Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QFUc7IWG; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf07.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org X-HE-Tag: 1656436634-503273 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, 28 Jun 2022 at 00:38, Kirill A. Shutemov wrote: > > 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? > The E in EFI means 'extensible' and the whole design of a protocol database using GUIDs as identifiers (which will not collide and therefore need no a priori coordination when defining them) is intended to allow extensions to be defined and implemented in a distributed manner. Of course, it would be fantastic if we can converge on a protocol that all flavors of confidential compute can use, across different OSes, so it is generally good if a protocol is defined in *some* shared specification. But this doesn't have to be the EFI spec.