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 401A0C433EF for ; Mon, 18 Jul 2022 17:22:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 35B7F6B0072; Mon, 18 Jul 2022 13:22:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 309266B0073; Mon, 18 Jul 2022 13:22:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A8ED6B0074; Mon, 18 Jul 2022 13:22:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 052186B0072 for ; Mon, 18 Jul 2022 13:22:00 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C644660EF5 for ; Mon, 18 Jul 2022 17:21:59 +0000 (UTC) X-FDA: 79700888358.14.71DA954 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf16.hostedemail.com (Postfix) with ESMTP id 87B50180049 for ; Mon, 18 Jul 2022 17:21:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658164918; x=1689700918; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=XQ2y1/VlwCd334Ie2B6PhFqb8Le129sl7rpEk9foass=; b=gAgSRBCQzzC9j6cR1plmLy25MLLwlDHshlQkliuOVHmulqpCPxO/GGot GG1BGDdK5kOIrTgunO2N3h+DNnk+UORdAkj+O3BCh81jBOHcF29dHPldE 9xwHneDrSpCDqYviA4AryTwUUtU2wkgt4v8clTUa2avcoYCfeXMshE/kZ WESbclShyltkm4vn3PxB7B9BXhvskxjr9v2kE+9ytYYu/OXN8G4Jfafkm 6hYvnhYe2H1wgreWmL83Uo5ABN3dcJ3OkaZuBFDcjAX8UaIshZGT6p+hX dC6c5oAde3HPVpyfqjh2rCJlKNwbnZOIshAZBVzn0O7zeOmRluCChWFE9 w==; X-IronPort-AV: E=McAfee;i="6400,9594,10412"; a="266680392" X-IronPort-AV: E=Sophos;i="5.92,281,1650956400"; d="scan'208";a="266680392" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jul 2022 10:21:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,281,1650956400"; d="scan'208";a="655374923" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga008.fm.intel.com with ESMTP; 18 Jul 2022 10:21:50 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 4FE9410E; Mon, 18 Jul 2022 20:21:59 +0300 (EEST) Date: Mon, 18 Jul 2022 20:21:59 +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: <20220718172159.4vwjzrfthelovcty@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> <20220627223808.ihgy3epdx6ofll43@black.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658164919; a=rsa-sha256; cv=none; b=0fcFMRZB2delpRw/ZvsjgCKtTE2CmyyrBdfV6oWyeV6GzheWc4h6lnxiWP2E1elJsupi1J O8DTWHoAFYa21SvaXN0Dw+JsEPG57RMZHgS8ms70FgTvHqKYMj/AnLs7Ytw8D87oLbM6he i94cFyh2iLsXEMWQ/WBAbisidwPqmm0= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=gAgSRBCQ; spf=none (imf16.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.151) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658164919; 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=upYxRyCl4Dv8rb0L1QrfbwkXi78vbU1ziRE0ttlUg4o=; b=oQc3tiSJJMK6ybW5efrFFGEKYHN3VCLMl+/lNfgG9zy+QeWo+23iwLZtpEDLHDo2qcL8QV fLbL1WUHr7tSedcuYdwVgdVnh2l4UdiGp1Wn19+pEvdpCbd+AgCSzlAFbzHG4bSdosrloo Rh3W1pwpJRiXt8FM0oBN4ke7/S0Zi3w= X-Rspamd-Queue-Id: 87B50180049 Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=gAgSRBCQ; spf=none (imf16.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.151) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam05 X-Rspam-User: X-Stat-Signature: ssgw9hjy6dtk3y5h3w3p786g6mh5r6p1 X-HE-Tag: 1658164918-268208 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, Jun 28, 2022 at 07:17:00PM +0200, Ard Biesheuvel wrote: > 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. I've talked with our firmware expert today and I think we have a problem with the approach when kernel declaries support of unaccepted memory. This apporach doesn't work if we include bootloader into the picture: if EBS() called by bootloader we still cannot know if target kernel supports unaccepted memory and we return to the square 1. I think we should make it obvious from a kernel image if it supports unaccepted memory (with UTS_VERSION or other way). Any comments? -- Kirill A. Shutemov