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 598C4C433EF for ; Sat, 23 Jul 2022 11:14:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51F956B0071; Sat, 23 Jul 2022 07:14:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A7716B0073; Sat, 23 Jul 2022 07:14:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 320C86B0074; Sat, 23 Jul 2022 07:14:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1F81E6B0071 for ; Sat, 23 Jul 2022 07:14:21 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EDD3B140F5C for ; Sat, 23 Jul 2022 11:14:20 +0000 (UTC) X-FDA: 79718105880.08.FCFA708 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id 7A5CF14008C for ; Sat, 23 Jul 2022 11:14:20 +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 9E0B160909 for ; Sat, 23 Jul 2022 11:14:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10453C341CB for ; Sat, 23 Jul 2022 11:14:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658574859; bh=unUMya6BPYpKOwprp7McozAEYE9y437U/0E90Qn/PR4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Idm4+tMyOetJHMHm/JAVCocTOpDhH/4+H8/qgaG+NFgUICBZPSdxOWI37JM3gj4jD V/OvQrda6hV48GHEYYyJr2xsCS8G0WxITIICAUzHNOeUZHGM8byaEfem/GklOYd5gH JvghH3cTxQxj28q6wqE6BgHdL5BWoCOKeQD8R3DFh9Y9y2hrqspCAFre0Q7odymkit PbfzEelwOOQoCJa+SsljsBScBGvZh0aG6+dBH7mGbVmOQ0OV1xq+h5inC3QVGFjkIl B3CNOrcxJO9NYFM0Lzb9ojZddR7wJ5tbrspEtad7+ovslybBfnYDXxmHSdkrls8L8o /yiwejtDXqhMA== Received: by mail-ot1-f45.google.com with SMTP id l9-20020a056830268900b006054381dd35so5140618otu.4 for ; Sat, 23 Jul 2022 04:14:19 -0700 (PDT) X-Gm-Message-State: AJIora+zTTtwtvlzOPmP+y6yOuKW0kz6gDOvjwugQ+OyOzLl9wMUyeV9 fU95YTTEPRf5sQzR6L65DJ8BxsjLYfOuLQp4jtE= X-Google-Smtp-Source: AGRyM1toSHzLLGvC9FLzuNt3t1myK6Yjo1zRCx/Yq65wM9j6V/TSj8mKNgSzLkZMi7xH4yhMSuJHvm32vnmmswjz4II= X-Received: by 2002:a05:6830:441f:b0:61c:a5bb:9c6a with SMTP id q31-20020a056830441f00b0061ca5bb9c6amr1524623otv.265.1658574858208; Sat, 23 Jul 2022 04:14:18 -0700 (PDT) MIME-Version: 1.0 References: <20220627223808.ihgy3epdx6ofll43@black.fi.intel.com> <20220718172159.4vwjzrfthelovcty@black.fi.intel.com> <22d54786-bc12-ecc5-2b37-cbaa56090aa8@intel.com> In-Reply-To: From: Ard Biesheuvel Date: Sat, 23 Jul 2022 13:14:07 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCHv7 00/14] mm, x86/cc: Implement support for unaccepted memory To: Dave Hansen Cc: Marc Orr , Borislav Petkov , 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" Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658574860; a=rsa-sha256; cv=none; b=Sl/SqhXAIJPF0C3SFab40jwWK/YttB7Dhyd9jj5mHWcxav0eG9BRu4RR4ei1zVWf10AuwV 6TSZ7B0GGGUuKqCEgExS1YJ7tnpoSJOs1CktR0gRXlwlqhs1n2nN1KUKTZm0WLykp3GWe3 ncpVULz/rUjX63lAjtQnIFrL30nW2Fs= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Idm4+tMy; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf26.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=1658574860; 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=+NDFMrWDGNkuDr8EY19VFrxk14BSqPf8mRU4CYwXaEE=; b=gYeoUeDhh355Ya7POu3v8ikwSdyYX2d+cztRxqs21SAt/IANP21NasxUbgKwS7Y1Y7gpSs sqROvglwhiMo+cryAGzwSzdWeiEp6CfosxRdQUCJsgqzRtMpLpuo+4Cl4Kyld/oTQUQMgi 4x0ZEp2bluRUToxUJvsDSErHS7nxU2I= Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Idm4+tMy; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 7A5CF14008C X-Stat-Signature: uqarreyfeyw9398k4bjgj9mupqgf8ost X-HE-Tag: 1658574860-838408 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 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. What I strongly object to is inventing a new bespoke way for the firmware to make inferences about the capabilities of the image by inspecting fields in the file representation of the image (which is not guaranteed by EFI to be identical to its in-memory representation, as, e.g., the PE/COFF header could be omitted by a loader without violating the spec) As for the intermediate thing: yes, that would be a valuable thing to have in OVMF (and I will gladly take EDK2 patches that implement this). However, I'm not sure how you decide whether or not this thing should be active or not, doesn't that just move the problem around?