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 B1A8DC25B07 for ; Tue, 9 Aug 2022 11:36:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 356486B0071; Tue, 9 Aug 2022 07:36:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 303518E0003; Tue, 9 Aug 2022 07:36:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17C5B8E0002; Tue, 9 Aug 2022 07:36:17 -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 06C036B0071 for ; Tue, 9 Aug 2022 07:36:17 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D723A140EE7 for ; Tue, 9 Aug 2022 11:36:16 +0000 (UTC) X-FDA: 79779850752.10.59B325D Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf10.hostedemail.com (Postfix) with ESMTP id 5699AC0167 for ; Tue, 9 Aug 2022 11:36:16 +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 ams.source.kernel.org (Postfix) with ESMTPS id E21E5B81333 for ; Tue, 9 Aug 2022 11:36:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C231C43145 for ; Tue, 9 Aug 2022 11:36:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1660044973; bh=lYmz63lvuOJC10qqhICk6CNKKBSIvT6UEu1+sVeFf/k=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=D8QCs4Zj0JxgBqIzIxwpwwjb22fBVf+C+1AoftP/A8nRz1cQfyn8lFxwji36lncyt JuCkgqsB5cTNUm2lOkZ+6oRB4NTxNI/Re7wpgbTa6hhhqd8wysFp6PM0UUeYJxsEpY c8IWAF8y4FtI9zkEheIKNd37sRY80/IHnVK1T1yXtcYcEu+mfojpviDU70qOZZj3dz t9i1I5caWSJquFPHA/V70vbnzVf5pWmWvxBX4pQzhS1rULsACI6hhhqCgCC/3BsIIV aHDfelJCT2uCk2bj+lnnhqKWF2X+E9f0apbY2qhogUdxg1aKLHFQlocQ3L1+02XJZY eW85zPGCMg86Q== Received: by mail-wm1-f54.google.com with SMTP id 186-20020a1c02c3000000b003a34ac64bdfso6540370wmc.1 for ; Tue, 09 Aug 2022 04:36:13 -0700 (PDT) X-Gm-Message-State: ACgBeo1/TXxG17+FhvTEn2cuSpl+u0uuPyXZn1P1a8bITYKm8d9o5Zea KdGFNs+STUmDLaPqksXO6Alw1Mn8zdrIkMnv6TQ= X-Google-Smtp-Source: AA6agR5YA4d5EiVi8IsQGMnr87dAaHnFiJPv49l2QVm+YXZcWXaPa07a+M4tje74nlRqsJgaMdFnW1wJLZwN8ljidRQ= X-Received: by 2002:a05:600c:509:b0:3a5:2c2:fb40 with SMTP id i9-20020a05600c050900b003a502c2fb40mr18927723wmc.163.1660044971866; Tue, 09 Aug 2022 04:36:11 -0700 (PDT) MIME-Version: 1.0 References: <22d54786-bc12-ecc5-2b37-cbaa56090aa8@intel.com> <20220809111436.kudwg2nprnnsfvuh@box.shutemov.name> In-Reply-To: <20220809111436.kudwg2nprnnsfvuh@box.shutemov.name> From: Ard Biesheuvel Date: Tue, 9 Aug 2022 13:36: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: Dave Hansen , Marc Orr , Borislav Petkov , Dionna Amalie Glaze , 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" Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660044976; 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=jYgfsLg7eaA5z4O87/1nT2DyWMOzD0r1TjDE5hVZRag=; b=C1H8BcQptFQ0R9gKmHF8QvQOVjfCp6edj+fOBz+F6Drd4pN2l5Hu/SQKc8LoHA/rg5E+FB WpqyIIO1wiyCUSuqZbTMH3t9sfr1rLp26neWRR2GbrR4sHibgsGFtWwkJfDc1WBqKxeUTT Ruf/KJVZfzqeD3HsAp7FYTuI5y5tifA= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=D8QCs4Zj; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf10.hostedemail.com: domain of ardb@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660044976; a=rsa-sha256; cv=none; b=7QxkfFzIHJEN81bSgZp5hjR6I7quAMSLQ3HJwb3ZMMBMPINZYnSdEN11RgV13tv2+fzOxY uQ8oQFOsXZkCX0dSrjMOwisTpyBe9jEr1SZbawiKofvVRp0v5JHSfMWpaBEzaLdlp32ozv WHZtfAIxLMcZeHqfcLvxs0uGs2cLJlY= X-Rspamd-Queue-Id: 5699AC0167 Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=D8QCs4Zj; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf10.hostedemail.com: domain of ardb@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=ardb@kernel.org X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: 8ywx96gqp7hd7w75ubj5ed49usxuo31h X-HE-Tag: 1660044976-90474 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, 9 Aug 2022 at 13:11, Kirill A. Shutemov wrote: > > On Sat, Jul 23, 2022 at 01:14:07PM +0200, Ard Biesheuvel wrote: > > On Thu, 21 Jul 2022 at 19:13, Dave Hansen wrote: > > > > > > On 7/19/22 17:26, Marc Orr wrote: > > > > - Dave's suggestion to "2. Boot some intermediate thing like a > > > > bootloader that does acceptance ..." is pretty clever! So if upstream > > > > thinks this FW-kernel negotiation is not a good direction, maybe we > > > > (Google) can pursue this idea to avoid introducing yet another tag on > > > > our images. > > > > > > I'm obviously speaking only for myself here and not for "upstream" as a > > > whole, but I clearly don't like the FW/kernel negotiation thing. It's a > > > permanent pain in our necks to solve a very temporary problem. > > > > EFI is basically our existing embodiment of this fw/kernel negotiation > > thing, and iff we need it, I have no objection to using it for this > > purpose, i.e., to allow the firmware to infer whether or not it should > > accept all available memory on behalf of the OS before exiting boot > > services. But if we don't need this, even better. > > FW/kernel negotiation does not work if there's a boot loader in the middle > that does ExitBootServices(). By the time kernel can announce if it > supports unaccepted memory there's nobody to announce to. > Why would you want to support such bootloaders for TDX anyway? TDX heavily relies on measured boot abstractions and other things that are heavily tied to firmware.