[{"id":3191355,"web_url":"http://patchwork.ozlabs.org/comment/3191355/","msgid":"","list_archive_url":null,"date":"2023-10-02T17:53:56","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":6170,"url":"http://patchwork.ozlabs.org/api/people/6170/","name":"Simon Glass","email":"sjg@chromium.org"},"content":"Hi Rob,\n\nOn Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:\n>\n> It is common to split firmware into 'Platform Init', which does the\n> initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> Thus an handover interface is required between these two pieces.\n>\n> Where UEFI boot-time services are not available, but UEFI firmware is\n> present on either side of this interface, information about memory usage\n> and attributes must be presented to the \"Payload\" in some form.\n>\n> This aims to provide an small schema addition for the memory mapping\n> needed to keep these two pieces working together well.\n>\n> Signed-off-by: Simon Glass \n> ---\n>\n> Changes in v7:\n> - Rename acpi-reclaim to acpi\n> - Drop individual mention of when memory can be reclaimed\n> - Rewrite the item descriptions\n> - Add back the UEFI text (with trepidation)\n\nI am again checking on this series. Can it be applied, please?\n\n\n>\n> Changes in v6:\n> - Drop mention of UEFI\n> - Use compatible strings instead of node names\n>\n> Changes in v5:\n> - Drop the memory-map node (should have done that in v4)\n> - Tidy up schema a bit\n>\n> Changes in v4:\n> - Make use of the reserved-memory node instead of creating a new one\n>\n> Changes in v3:\n> - Reword commit message again\n> - cc a lot more people, from the FFI patch\n> - Split out the attributes into the /memory nodes\n>\n> Changes in v2:\n> - Reword commit message\n>\n> .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> 1 file changed, 71 insertions(+)\n> create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml\n>\n> diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> new file mode 100644\n> index 0000000..f7fbdfd\n> --- /dev/null\n> +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> @@ -0,0 +1,71 @@\n> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause\n> +%YAML 1.2\n> +---\n> +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> +\n> +title: Common memory reservations\n> +\n> +description: |\n> + Specifies that the reserved memory region can be used for the purpose\n> + indicated by its compatible string.\n> +\n> + Clients may reuse this reserved memory if they understand what it is for,\n> + subject to the notes below.\n> +\n> +maintainers:\n> + - Simon Glass \n> +\n> +allOf:\n> + - $ref: reserved-memory.yaml\n> +\n> +properties:\n> + compatible:\n> + description: |\n> + This describes some common memory reservations, with the compatible\n> + string indicating what it is used for:\n> +\n> + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> + the firmware for its use and is required to be saved and restored\n> + across an NVS sleep\n> + boot-code: Contains code used for booting which is not needed by the OS\n> + boot-code: Contains data used for booting which is not needed by the OS\n> + runtime-code: Contains code used for interacting with the system when\n> + running the OS\n> + runtime-data: Contains data used for interacting with the system when\n> + running the OS\n> +\n> + enum:\n> + - acpi\n> + - acpi-nvs\n> + - boot-code\n> + - boot-data\n> + - runtime-code\n> + - runtime-data\n> +\n> + reg:\n> + description: region of memory that is reserved for the purpose indicated\n> + by the compatible string.\n> +\n> +required:\n> + - reg\n> +\n> +unevaluatedProperties: false\n> +\n> +examples:\n> + - |\n> + reserved-memory {\n> + #address-cells = <1>;\n> + #size-cells = <1>;\n> +\n> + reserved@12340000 {\n> + compatible = \"boot-code\";\n> + reg = <0x12340000 0x00800000>;\n> + };\n> +\n> + reserved@43210000 {\n> + compatible = \"boot-data\";\n> + reg = <0x43210000 0x00800000>;\n> + };\n> + };\n> --\n> 2.42.0.515.g380fc7ccd1-goog\n>\n\nRegards,\nSimon","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256\n header.s=google header.b=mqhqjOxX;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org\n header.b=\"mqhqjOxX\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4RzpVZ50myz1ypx\n\tfor ; Tue, 3 Oct 2023 04:54:13 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id EF41886DBC;\n\tMon, 2 Oct 2023 19:54:10 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id 762CB86DF1; Mon, 2 Oct 2023 19:54:10 +0200 (CEST)","from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com\n [IPv6:2a00:1450:4864:20::52e])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 44BFC86DAD\n for ; Mon, 2 Oct 2023 19:54:08 +0200 (CEST)","by mail-ed1-x52e.google.com with SMTP id\n 4fb4d7f45d1cf-53406799540so17249425a12.1\n for ; Mon, 02 Oct 2023 10:54:08 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-9.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,\n SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=no\n autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=chromium.org; s=google; t=1696269248; x=1696874048; darn=lists.denx.de;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=TsD3ZHZijN9S1sfcV2n15VGsYEU63cv+c2MU+o+0ccc=;\n b=mqhqjOxX5QzZ6H65ebs10S0L1bfftcR2jKBGy1QQpmigbOxd7y+Xx0v0V+FiuuBO8V\n zcOxLnIjdVJAoajLcWRu6+tJzqDRZQAvJQwNDTgXl4/lUNzwOwnwsdWUOIvFBrJwLKL5\n bb4hZMq7rYYQfuGMjPpaPQ8Qc5Mb6BZUeR/Do=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1696269248; x=1696874048;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=TsD3ZHZijN9S1sfcV2n15VGsYEU63cv+c2MU+o+0ccc=;\n b=TcKE61zcM2DoORpkzce6EiH4ONpNjzHST6/SqK6BmdPanElhdvyx14BhsFNPHd8FU8\n hL5BnTxX/L/fqZ0LBN4wsJIqu0slIM2CQcOqtKv/9bEYxkd7HyVINAKxeo6qAejUZhet\n vmO3RsCd6SwrjmPSyWyqMxke56nqyqtqsrHEDyWofirRavHSUBHkJRiNav5ktgQT3oBI\n SGSq9SHDGZa4HcrW4pn/vvwtRzGpKyYmnmDTQOZZuljIV95FpVggYr8L98gXVAt7k87P\n P3kyMobUrmti9YlrHOhIRXlCcJGEjJ8ZsodhyUBL8eezOPRx5y6Jlrn6mShD2E0yeD7u\n iXxw==","X-Gm-Message-State":"AOJu0YzKm3iMptTlFRvvNqj1hrvBtdRDg3ailtpnsOugHPg88qQUzQTc\n Z2c3sRd7MbDf7qx4HU/2O0IRYkoCO2Phw+0C44f3kQ==","X-Google-Smtp-Source":"\n AGHT+IEtCxySMkh42I2CvgUj5aqq7h5MglNyXJ6gmXIzyE5bAMfwobhiZlavHruHjwW8M3Pas9ZdXj3GPE0ymKFjY74=","X-Received":"by 2002:a17:906:19:b0:9a3:c4f4:12de with SMTP id\n 25-20020a170906001900b009a3c4f412demr11349374eja.37.1696269247617; Mon, 02\n Oct 2023 10:54:07 -0700 (PDT)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>","In-Reply-To":"<20230926194242.2732127-2-sjg@chromium.org>","From":"Simon Glass ","Date":"Mon, 2 Oct 2023 11:53:56 -0600","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"devicetree@vger.kernel.org","Cc":"Mark Rutland , Rob Herring ,\n Lean Sheng Tan ,\n lkml ,\n Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui , Guo Dong ,\n Tom Rini , ron minnich ,\n Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List , Ard Biesheuvel ","Content-Type":"text/plain; charset=\"UTF-8\"","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3194548,"web_url":"http://patchwork.ozlabs.org/comment/3194548/","msgid":"","list_archive_url":null,"date":"2023-10-06T17:33:20","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":77831,"url":"http://patchwork.ozlabs.org/api/people/77831/","name":"Ard Biesheuvel","email":"ardb@kernel.org"},"content":"On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:\n>\n> Hi Rob,\n>\n> On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:\n> >\n> > It is common to split firmware into 'Platform Init', which does the\n> > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > Thus an handover interface is required between these two pieces.\n> >\n> > Where UEFI boot-time services are not available, but UEFI firmware is\n> > present on either side of this interface, information about memory usage\n> > and attributes must be presented to the \"Payload\" in some form.\n> >\n> > This aims to provide an small schema addition for the memory mapping\n> > needed to keep these two pieces working together well.\n> >\n> > Signed-off-by: Simon Glass \n> > ---\n> >\n> > Changes in v7:\n> > - Rename acpi-reclaim to acpi\n> > - Drop individual mention of when memory can be reclaimed\n> > - Rewrite the item descriptions\n> > - Add back the UEFI text (with trepidation)\n>\n> I am again checking on this series. Can it be applied, please?\n>\n\nApologies for the delay in response. I have been away.\n\n>\n> >\n> > Changes in v6:\n> > - Drop mention of UEFI\n> > - Use compatible strings instead of node names\n> >\n> > Changes in v5:\n> > - Drop the memory-map node (should have done that in v4)\n> > - Tidy up schema a bit\n> >\n> > Changes in v4:\n> > - Make use of the reserved-memory node instead of creating a new one\n> >\n> > Changes in v3:\n> > - Reword commit message again\n> > - cc a lot more people, from the FFI patch\n> > - Split out the attributes into the /memory nodes\n> >\n> > Changes in v2:\n> > - Reword commit message\n> >\n> > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > 1 file changed, 71 insertions(+)\n> > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml\n> >\n> > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > new file mode 100644\n> > index 0000000..f7fbdfd\n> > --- /dev/null\n> > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > @@ -0,0 +1,71 @@\n> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause\n> > +%YAML 1.2\n> > +---\n> > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > +\n> > +title: Common memory reservations\n> > +\n> > +description: |\n> > + Specifies that the reserved memory region can be used for the purpose\n> > + indicated by its compatible string.\n> > +\n> > + Clients may reuse this reserved memory if they understand what it is for,\n> > + subject to the notes below.\n> > +\n> > +maintainers:\n> > + - Simon Glass \n> > +\n> > +allOf:\n> > + - $ref: reserved-memory.yaml\n> > +\n> > +properties:\n> > + compatible:\n> > + description: |\n> > + This describes some common memory reservations, with the compatible\n> > + string indicating what it is used for:\n> > +\n> > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > + the firmware for its use and is required to be saved and restored\n> > + across an NVS sleep\n> > + boot-code: Contains code used for booting which is not needed by the OS\n> > + boot-code: Contains data used for booting which is not needed by the OS\n> > + runtime-code: Contains code used for interacting with the system when\n> > + running the OS\n> > + runtime-data: Contains data used for interacting with the system when\n> > + running the OS\n> > +\n> > + enum:\n> > + - acpi\n> > + - acpi-nvs\n> > + - boot-code\n> > + - boot-data\n> > + - runtime-code\n> > + - runtime-data\n> > +\n\nAs I mentioned a few times already, I don't think these compatibles\nshould be introduced here.\n\nA reserved region has a specific purpose, and the compatible should be\nmore descriptive than the enum above. If the consumer does not\nunderstand this purpose, it should simply treat the memory as reserved\nand not touch it. Alternatively, these regions can be referenced from\nother DT nodes using phandles if needed.\n\n\n> > + reg:\n> > + description: region of memory that is reserved for the purpose indicated\n> > + by the compatible string.\n> > +\n> > +required:\n> > + - reg\n> > +\n> > +unevaluatedProperties: false\n> > +\n> > +examples:\n> > + - |\n> > + reserved-memory {\n> > + #address-cells = <1>;\n> > + #size-cells = <1>;\n> > +\n> > + reserved@12340000 {\n> > + compatible = \"boot-code\";\n> > + reg = <0x12340000 0x00800000>;\n> > + };\n> > +\n> > + reserved@43210000 {\n> > + compatible = \"boot-data\";\n> > + reg = <0x43210000 0x00800000>;\n> > + };\n> > + };\n> > --\n> > 2.42.0.515.g380fc7ccd1-goog\n> >\n>\n> Regards,\n> Simon","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=JLgw/UkC;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=85.214.62.61; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.b=\"JLgw/UkC\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de; spf=pass smtp.mailfrom=ardb@kernel.org"],"Received":["from phobos.denx.de (phobos.denx.de [85.214.62.61])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4S2FsB5x6Hz1yq9\n\tfor ; Sat, 7 Oct 2023 04:33:48 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id CB42B86D41;\n\tFri, 6 Oct 2023 19:33:40 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id 1BB6486C78; Fri, 6 Oct 2023 19:33:39 +0200 (CEST)","from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 250DC86D41\n for ; Fri, 6 Oct 2023 19:33:36 +0200 (CEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by dfw.source.kernel.org (Postfix) with ESMTP id 35A3661425\n for ; Fri, 6 Oct 2023 17:33:34 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id CE199C43395\n for ; Fri, 6 Oct 2023 17:33:33 +0000 (UTC)","by mail-lf1-f45.google.com with SMTP id\n 2adb3069b0e04-5044dd5b561so2928582e87.1\n for ; Fri, 06 Oct 2023 10:33:33 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1696613613;\n bh=4IY5wvH6Tu8PjK8sB+KMGi/o7CRamiSkVLdDByB8yd8=;\n h=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n b=JLgw/UkCyfmsvFHkORbsNApmlFxfQIWwAspg7Fgtj7uPVIWdvAhtw04GGiTbDYQgU\n 1NcRUUKEdX98ooHi0UShUy8PN3FdMPPaykMmKqJK+nG7EdgTbceY7vSGy9qCM1QQvi\n RkkVLS9B7Kv445176PYUUham34401aZOlX6CwIKbjTM1DmC8nNUKjLfabxIW1VcsMF\n id2cn/dFAO1AG1GG+6/5eS2voYp3c+sXJEDLrfjeWZvg42g2KtTaAdrhU8+EOIOswF\n uvVTpmOpUNHgJrjWPfo/NvPCdZb55r9VdDBIIOpd8W4TUMwcV4GxQxdf92GByJiWNL\n CsSL1voPt3ONQ==","X-Gm-Message-State":"AOJu0YzW5HMxY9E0O/zDBR+55+Q+ZP+onB2kU/6yOwzl1ycQJpUpy3wJ\n j0fjVTweeMn2MlL/JWT6oHAqImDcpQyzNDpNpIM=","X-Google-Smtp-Source":"\n AGHT+IG2WFsPGJcnl4fQlvIDX23yxE4FYGH11uyJoLwu4bJYLZExy/cAZV6tzSxf3TqK4KzjOHM+0kg+tpgnDaQV7yU=","X-Received":"by 2002:a19:c217:0:b0:504:7e12:4846 with SMTP id\n l23-20020a19c217000000b005047e124846mr7273243lfc.30.1696613611592; Fri, 06\n Oct 2023 10:33:31 -0700 (PDT)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n ","In-Reply-To":"\n ","From":"Ard Biesheuvel ","Date":"Fri, 6 Oct 2023 19:33:20 +0200","X-Gmail-Original-Message-ID":"\n ","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Simon Glass ","Cc":"devicetree@vger.kernel.org, Mark Rutland ,\n Rob Herring , Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3194582,"web_url":"http://patchwork.ozlabs.org/comment/3194582/","msgid":"","list_archive_url":null,"date":"2023-10-06T18:17:23","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":6170,"url":"http://patchwork.ozlabs.org/api/people/6170/","name":"Simon Glass","email":"sjg@chromium.org"},"content":"Hi Ard,\n\nOn Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel wrote:\n>\n> On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:\n> >\n> > Hi Rob,\n> >\n> > On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:\n> > >\n> > > It is common to split firmware into 'Platform Init', which does the\n> > > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > > Thus an handover interface is required between these two pieces.\n> > >\n> > > Where UEFI boot-time services are not available, but UEFI firmware is\n> > > present on either side of this interface, information about memory usage\n> > > and attributes must be presented to the \"Payload\" in some form.\n> > >\n> > > This aims to provide an small schema addition for the memory mapping\n> > > needed to keep these two pieces working together well.\n> > >\n> > > Signed-off-by: Simon Glass \n> > > ---\n> > >\n> > > Changes in v7:\n> > > - Rename acpi-reclaim to acpi\n> > > - Drop individual mention of when memory can be reclaimed\n> > > - Rewrite the item descriptions\n> > > - Add back the UEFI text (with trepidation)\n> >\n> > I am again checking on this series. Can it be applied, please?\n> >\n>\n> Apologies for the delay in response. I have been away.\n\nOK, I hope you had a nice trip.\n\n>\n> >\n> > >\n> > > Changes in v6:\n> > > - Drop mention of UEFI\n> > > - Use compatible strings instead of node names\n> > >\n> > > Changes in v5:\n> > > - Drop the memory-map node (should have done that in v4)\n> > > - Tidy up schema a bit\n> > >\n> > > Changes in v4:\n> > > - Make use of the reserved-memory node instead of creating a new one\n> > >\n> > > Changes in v3:\n> > > - Reword commit message again\n> > > - cc a lot more people, from the FFI patch\n> > > - Split out the attributes into the /memory nodes\n> > >\n> > > Changes in v2:\n> > > - Reword commit message\n> > >\n> > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > > 1 file changed, 71 insertions(+)\n> > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml\n> > >\n> > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > new file mode 100644\n> > > index 0000000..f7fbdfd\n> > > --- /dev/null\n> > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > @@ -0,0 +1,71 @@\n> > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause\n> > > +%YAML 1.2\n> > > +---\n> > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > > +\n> > > +title: Common memory reservations\n> > > +\n> > > +description: |\n> > > + Specifies that the reserved memory region can be used for the purpose\n> > > + indicated by its compatible string.\n> > > +\n> > > + Clients may reuse this reserved memory if they understand what it is for,\n> > > + subject to the notes below.\n> > > +\n> > > +maintainers:\n> > > + - Simon Glass \n> > > +\n> > > +allOf:\n> > > + - $ref: reserved-memory.yaml\n> > > +\n> > > +properties:\n> > > + compatible:\n> > > + description: |\n> > > + This describes some common memory reservations, with the compatible\n> > > + string indicating what it is used for:\n> > > +\n> > > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > > + the firmware for its use and is required to be saved and restored\n> > > + across an NVS sleep\n> > > + boot-code: Contains code used for booting which is not needed by the OS\n> > > + boot-code: Contains data used for booting which is not needed by the OS\n> > > + runtime-code: Contains code used for interacting with the system when\n> > > + running the OS\n> > > + runtime-data: Contains data used for interacting with the system when\n> > > + running the OS\n> > > +\n> > > + enum:\n> > > + - acpi\n> > > + - acpi-nvs\n> > > + - boot-code\n> > > + - boot-data\n> > > + - runtime-code\n> > > + - runtime-data\n> > > +\n>\n> As I mentioned a few times already, I don't think these compatibles\n> should be introduced here.\n>\n> A reserved region has a specific purpose, and the compatible should be\n> more descriptive than the enum above. If the consumer does not\n> understand this purpose, it should simply treat the memory as reserved\n> and not touch it. Alternatively, these regions can be referenced from\n> other DT nodes using phandles if needed.\n\nWe still need some description of what these regions are used for, so\nthat the payload can use the correct regions. I do not have any other\nsolution to this problem. We are in v7 at present. At least explain\nwhere you want the compatible strings to be introduced.\n\nWhat sort of extra detail are you looking for? Please be specific and\npreferably add some suggestions so I can close this out ASAP.\n\n>\n>\n> > > + reg:\n> > > + description: region of memory that is reserved for the purpose indicated\n> > > + by the compatible string.\n> > > +\n> > > +required:\n> > > + - reg\n> > > +\n> > > +unevaluatedProperties: false\n> > > +\n> > > +examples:\n> > > + - |\n> > > + reserved-memory {\n> > > + #address-cells = <1>;\n> > > + #size-cells = <1>;\n> > > +\n> > > + reserved@12340000 {\n> > > + compatible = \"boot-code\";\n> > > + reg = <0x12340000 0x00800000>;\n> > > + };\n> > > +\n> > > + reserved@43210000 {\n> > > + compatible = \"boot-data\";\n> > > + reg = <0x43210000 0x00800000>;\n> > > + };\n> > > + };\n> > > --\n> > > 2.42.0.515.g380fc7ccd1-goog\n\nRegards,\nSimon","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256\n header.s=google header.b=HJXIEaQ/;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=85.214.62.61; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org\n header.b=\"HJXIEaQ/\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com"],"Received":["from phobos.denx.de (phobos.denx.de [85.214.62.61])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4S2Gr357tDz1yqF\n\tfor ; Sat, 7 Oct 2023 05:17:53 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 0479886B89;\n\tFri, 6 Oct 2023 20:17:49 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id CFC8C86B8F; Fri, 6 Oct 2023 20:17:47 +0200 (CEST)","from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com\n [IPv6:2607:f8b0:4864:20::112d])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 5435B86B42\n for ; Fri, 6 Oct 2023 20:17:45 +0200 (CEST)","by mail-yw1-x112d.google.com with SMTP id\n 00721157ae682-59e77e4f707so30210687b3.0\n for ; Fri, 06 Oct 2023 11:17:45 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-9.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,\n SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=no\n autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=chromium.org; s=google; t=1696616264; x=1697221064; darn=lists.denx.de;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=N1kuvdFzr7bMP1IyvjWvGqylFglQ5IsaUBjLbA0R1mM=;\n b=HJXIEaQ/jItaWOmg5gFGdvBhyimSr1FR6I+j+wMQHqRrcD9Vd9aRHCD+FitRC9qZv3\n C2iqF2aN0iWCRyG8qikocgjWF4yqh2A6EfvzSIN/5Ne30IUozpi2Eoaz5jfGAV+uc4iH\n 4PDlid5QfMcEWbc4kUbIrXVCeDOncJgXzE7hE=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1696616264; x=1697221064;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=N1kuvdFzr7bMP1IyvjWvGqylFglQ5IsaUBjLbA0R1mM=;\n b=sLe1TLUoTQDIWVgFhX2atII8azkrI8rFGeyxEVEWeRjk3qUMj6e1o8IZN9CoXKzhPd\n b5ajVOfyWQEh54Hw4Pu6B7TSv09eG8mmqtaEYjHqgW55MRfuUpPl7kPoOefMWg/KdIoU\n ZycweptnYq8qhevFvEWwS0BQhbrR6Gi7BfEKi/CTfVfA+tyQoW/us4vcoT1BRQUbrsn7\n ElaBGv/CRL+Svdjpqd8R791eHzublmYnarSqufZHSB7GHSdEP590bNPFZKjZLMjbIQoC\n +YQRdRMfPi0Jr1yHy31s0BSCOKCkQnlMZ8yu+nY3tgJ6Jwvfi8sjFn1tY7YWYNqoLtLj\n Seeg==","X-Gm-Message-State":"AOJu0Yz3Ex8vJU63JHSrvPMFHdVNnAULNxRNc5FsMfHsT/RLVsAsirgQ\n +LIvQ/oLWiTRI+GuKq0g9OHHC6wy5ma1y0GecKnUlg==","X-Google-Smtp-Source":"\n AGHT+IGIR7IRjqzwhRUNpXjT8dLojncj3fRT3VJBx9+8GCPm7ydQ54cLXAEYShIToVA6nQy5pwi/6OxP9yHrPkR3CRA=","X-Received":"by 2002:a81:6d47:0:b0:59f:81c4:631a with SMTP id\n i68-20020a816d47000000b0059f81c4631amr11073507ywc.24.1696616263670; Fri, 06\n Oct 2023 11:17:43 -0700 (PDT)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n ","In-Reply-To":"\n ","From":"Simon Glass ","Date":"Fri, 6 Oct 2023 12:17:23 -0600","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Ard Biesheuvel ","Cc":"devicetree@vger.kernel.org, Mark Rutland ,\n Rob Herring , Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3194686,"web_url":"http://patchwork.ozlabs.org/comment/3194686/","msgid":"","list_archive_url":null,"date":"2023-10-06T22:59:57","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":77831,"url":"http://patchwork.ozlabs.org/api/people/77831/","name":"Ard Biesheuvel","email":"ardb@kernel.org"},"content":"On Fri, 6 Oct 2023 at 20:17, Simon Glass wrote:\n>\n> Hi Ard,\n>\n> On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel wrote:\n> >\n> > On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:\n> > >\n> > > Hi Rob,\n> > >\n> > > On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:\n> > > >\n> > > > It is common to split firmware into 'Platform Init', which does the\n> > > > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > > > Thus an handover interface is required between these two pieces.\n> > > >\n> > > > Where UEFI boot-time services are not available, but UEFI firmware is\n> > > > present on either side of this interface, information about memory usage\n> > > > and attributes must be presented to the \"Payload\" in some form.\n> > > >\n> > > > This aims to provide an small schema addition for the memory mapping\n> > > > needed to keep these two pieces working together well.\n> > > >\n> > > > Signed-off-by: Simon Glass \n> > > > ---\n> > > >\n> > > > Changes in v7:\n> > > > - Rename acpi-reclaim to acpi\n> > > > - Drop individual mention of when memory can be reclaimed\n> > > > - Rewrite the item descriptions\n> > > > - Add back the UEFI text (with trepidation)\n> > >\n> > > I am again checking on this series. Can it be applied, please?\n> > >\n> >\n> > Apologies for the delay in response. I have been away.\n>\n> OK, I hope you had a nice trip.\n>\n\nThanks, it was wonderful!\n\n> >\n> > >\n> > > >\n> > > > Changes in v6:\n> > > > - Drop mention of UEFI\n> > > > - Use compatible strings instead of node names\n> > > >\n> > > > Changes in v5:\n> > > > - Drop the memory-map node (should have done that in v4)\n> > > > - Tidy up schema a bit\n> > > >\n> > > > Changes in v4:\n> > > > - Make use of the reserved-memory node instead of creating a new one\n> > > >\n> > > > Changes in v3:\n> > > > - Reword commit message again\n> > > > - cc a lot more people, from the FFI patch\n> > > > - Split out the attributes into the /memory nodes\n> > > >\n> > > > Changes in v2:\n> > > > - Reword commit message\n> > > >\n> > > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > > > 1 file changed, 71 insertions(+)\n> > > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > >\n> > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > new file mode 100644\n> > > > index 0000000..f7fbdfd\n> > > > --- /dev/null\n> > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > @@ -0,0 +1,71 @@\n> > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause\n> > > > +%YAML 1.2\n> > > > +---\n> > > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > > > +\n> > > > +title: Common memory reservations\n> > > > +\n> > > > +description: |\n> > > > + Specifies that the reserved memory region can be used for the purpose\n> > > > + indicated by its compatible string.\n> > > > +\n> > > > + Clients may reuse this reserved memory if they understand what it is for,\n> > > > + subject to the notes below.\n> > > > +\n> > > > +maintainers:\n> > > > + - Simon Glass \n> > > > +\n> > > > +allOf:\n> > > > + - $ref: reserved-memory.yaml\n> > > > +\n> > > > +properties:\n> > > > + compatible:\n> > > > + description: |\n> > > > + This describes some common memory reservations, with the compatible\n> > > > + string indicating what it is used for:\n> > > > +\n> > > > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > > > + the firmware for its use and is required to be saved and restored\n> > > > + across an NVS sleep\n> > > > + boot-code: Contains code used for booting which is not needed by the OS\n> > > > + boot-code: Contains data used for booting which is not needed by the OS\n> > > > + runtime-code: Contains code used for interacting with the system when\n> > > > + running the OS\n> > > > + runtime-data: Contains data used for interacting with the system when\n> > > > + running the OS\n> > > > +\n> > > > + enum:\n> > > > + - acpi\n> > > > + - acpi-nvs\n> > > > + - boot-code\n> > > > + - boot-data\n> > > > + - runtime-code\n> > > > + - runtime-data\n> > > > +\n> >\n> > As I mentioned a few times already, I don't think these compatibles\n> > should be introduced here.\n> >\n> > A reserved region has a specific purpose, and the compatible should be\n> > more descriptive than the enum above. If the consumer does not\n> > understand this purpose, it should simply treat the memory as reserved\n> > and not touch it. Alternatively, these regions can be referenced from\n> > other DT nodes using phandles if needed.\n>\n> We still need some description of what these regions are used for, so\n> that the payload can use the correct regions. I do not have any other\n> solution to this problem. We are in v7 at present. At least explain\n> where you want the compatible strings to be introduced.\n>\n\nMy point is really that by themselves, these regions are not usable by\neither a payload or an OS that consumes this information. Unless there\nis some other information being provided (via DT I imagine) that\ndescribes how these things are supposed to be used, they are nothing\nmore than memory reservations that should be honored, and providing\nthis arbitrary set of labels is unnecessary.\n\n> What sort of extra detail are you looking for? Please be specific and\n> preferably add some suggestions so I can close this out ASAP.\n>\n\nA payload or OS can do nothing with a memory reservation called\n'runtime-code' it it doesn't know what is inside. So there is another\nDT node somewhere that describes this, and that can simply point to\nthis region (via a phandle) if it needs to describe the\ncorrespondence. This is more idiomatic for DT afaik (but I am not the\nexpert). But more importantly, it avoids overloading some vague\nlabels with behavior (e.g., executable permissions for code regions)\nthat should only be displayed for regions with a particular use,\nrather than for a ill defined class of reservations the purpose of\nwhich is not clear.\n\nWhat I am trying to avoid is the OS ending up being forced to consume\nthis information in parallel to the EFI memory map, and having to\nreconcile them. I'd be much happier if this gets contributed to a spec\nthat only covers firmware-to-firmware, and is prevented from leaking\ninto the OS facing interface.\n\n\n\n> >\n> >\n> > > > + reg:\n> > > > + description: region of memory that is reserved for the purpose indicated\n> > > > + by the compatible string.\n> > > > +\n> > > > +required:\n> > > > + - reg\n> > > > +\n> > > > +unevaluatedProperties: false\n> > > > +\n> > > > +examples:\n> > > > + - |\n> > > > + reserved-memory {\n> > > > + #address-cells = <1>;\n> > > > + #size-cells = <1>;\n> > > > +\n> > > > + reserved@12340000 {\n> > > > + compatible = \"boot-code\";\n> > > > + reg = <0x12340000 0x00800000>;\n> > > > + };\n> > > > +\n> > > > + reserved@43210000 {\n> > > > + compatible = \"boot-data\";\n> > > > + reg = <0x43210000 0x00800000>;\n> > > > + };\n> > > > + };\n> > > > --\n> > > > 2.42.0.515.g380fc7ccd1-goog\n>\n> Regards,\n> Simon","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=k5/VSAnW;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=85.214.62.61; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.b=\"k5/VSAnW\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de; spf=pass smtp.mailfrom=ardb@kernel.org"],"Received":["from phobos.denx.de (phobos.denx.de [85.214.62.61])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4S2P613S1sz1yqF\n\tfor ; Sat, 7 Oct 2023 10:00:25 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 5B7C886D3C;\n\tSat, 7 Oct 2023 01:00:18 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id 7596486E37; Sat, 7 Oct 2023 01:00:16 +0200 (CEST)","from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 48CA886D30\n for ; Sat, 7 Oct 2023 01:00:13 +0200 (CEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by dfw.source.kernel.org (Postfix) with ESMTP id 0105C6129D\n for ; Fri, 6 Oct 2023 23:00:11 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id A395AC433C9\n for ; Fri, 6 Oct 2023 23:00:10 +0000 (UTC)","by mail-lf1-f43.google.com with SMTP id\n 2adb3069b0e04-50435a9f800so3404015e87.2\n for ; Fri, 06 Oct 2023 16:00:10 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS autolearn=ham autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1696633210;\n bh=k8j0XLQXjQQJNDui+0jlFZl+AAfuXhuCpn9vIwWl/cE=;\n h=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n b=k5/VSAnWHKDBM+aIaW9QONktl0tgBQMkfEMqxBot4G6+wPYt1Z4J99Em95YUTDseY\n jGYDjY/mNJfz3h6IDzruMe+TCkQuBvsV+78ssBXvhZDthyjlPQaQJC4AanULx4jJsm\n udEBGn5mwgluyt40Cb0H4b9Rt4EoHlwr/4tKhZJkwAG5M6AooiUM+qPWQNcq/S02L0\n uXRCHgIoYf95seef8oUkwVjkIy8c3hxlqxiu5kjtgdkWQ1JPziVj7jT/CkmoWqv7dB\n MpKq3AWdGdLHCySq4EF227rhl/LTJuItrLWjF986UZOQrfH6sQpospQwPwBkhWTC0/\n ohcKg3tNSgdvg==","X-Gm-Message-State":"AOJu0YyGMZiqRbgRn6409dX840ONKYPirznpQD/ae/S8+oufoEBiXzaU\n PpMTyw6/gykD7K0o/FPIZLrHWw4M2YZktKyavLo=","X-Google-Smtp-Source":"\n AGHT+IGUwIsnV63UDRYG6J0ZqF0iXQaqHVFbYxtJQSuymsUOMmUxtPl2e5FaMeYVFq286z0ldqJng0iURsW6bIABAWg=","X-Received":"by 2002:a05:6512:68a:b0:502:d743:9fc4 with SMTP id\n t10-20020a056512068a00b00502d7439fc4mr9541254lfe.37.1696633208839; Fri, 06\n Oct 2023 16:00:08 -0700 (PDT)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n ","In-Reply-To":"\n ","From":"Ard Biesheuvel ","Date":"Sat, 7 Oct 2023 00:59:57 +0200","X-Gmail-Original-Message-ID":"\n ","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Simon Glass ","Cc":"devicetree@vger.kernel.org, Mark Rutland ,\n Rob Herring , Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3194699,"web_url":"http://patchwork.ozlabs.org/comment/3194699/","msgid":"","list_archive_url":null,"date":"2023-10-07T00:03:16","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":6170,"url":"http://patchwork.ozlabs.org/api/people/6170/","name":"Simon Glass","email":"sjg@chromium.org"},"content":"Hi Ard,\n\nOn Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel wrote:\n>\n> On Fri, 6 Oct 2023 at 20:17, Simon Glass wrote:\n> >\n> > Hi Ard,\n> >\n> > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel wrote:\n> > >\n> > > On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:\n> > > >\n> > > > Hi Rob,\n> > > >\n> > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:\n> > > > >\n> > > > > It is common to split firmware into 'Platform Init', which does the\n> > > > > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > > > > Thus an handover interface is required between these two pieces.\n> > > > >\n> > > > > Where UEFI boot-time services are not available, but UEFI firmware is\n> > > > > present on either side of this interface, information about memory usage\n> > > > > and attributes must be presented to the \"Payload\" in some form.\n> > > > >\n> > > > > This aims to provide an small schema addition for the memory mapping\n> > > > > needed to keep these two pieces working together well.\n> > > > >\n> > > > > Signed-off-by: Simon Glass \n> > > > > ---\n> > > > >\n> > > > > Changes in v7:\n> > > > > - Rename acpi-reclaim to acpi\n> > > > > - Drop individual mention of when memory can be reclaimed\n> > > > > - Rewrite the item descriptions\n> > > > > - Add back the UEFI text (with trepidation)\n> > > >\n> > > > I am again checking on this series. Can it be applied, please?\n> > > >\n> > >\n> > > Apologies for the delay in response. I have been away.\n> >\n> > OK, I hope you had a nice trip.\n> >\n>\n> Thanks, it was wonderful!\n>\n> > >\n> > > >\n> > > > >\n> > > > > Changes in v6:\n> > > > > - Drop mention of UEFI\n> > > > > - Use compatible strings instead of node names\n> > > > >\n> > > > > Changes in v5:\n> > > > > - Drop the memory-map node (should have done that in v4)\n> > > > > - Tidy up schema a bit\n> > > > >\n> > > > > Changes in v4:\n> > > > > - Make use of the reserved-memory node instead of creating a new one\n> > > > >\n> > > > > Changes in v3:\n> > > > > - Reword commit message again\n> > > > > - cc a lot more people, from the FFI patch\n> > > > > - Split out the attributes into the /memory nodes\n> > > > >\n> > > > > Changes in v2:\n> > > > > - Reword commit message\n> > > > >\n> > > > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > > > > 1 file changed, 71 insertions(+)\n> > > > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > >\n> > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > new file mode 100644\n> > > > > index 0000000..f7fbdfd\n> > > > > --- /dev/null\n> > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > @@ -0,0 +1,71 @@\n> > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause\n> > > > > +%YAML 1.2\n> > > > > +---\n> > > > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > > > > +\n> > > > > +title: Common memory reservations\n> > > > > +\n> > > > > +description: |\n> > > > > + Specifies that the reserved memory region can be used for the purpose\n> > > > > + indicated by its compatible string.\n> > > > > +\n> > > > > + Clients may reuse this reserved memory if they understand what it is for,\n> > > > > + subject to the notes below.\n> > > > > +\n> > > > > +maintainers:\n> > > > > + - Simon Glass \n> > > > > +\n> > > > > +allOf:\n> > > > > + - $ref: reserved-memory.yaml\n> > > > > +\n> > > > > +properties:\n> > > > > + compatible:\n> > > > > + description: |\n> > > > > + This describes some common memory reservations, with the compatible\n> > > > > + string indicating what it is used for:\n> > > > > +\n> > > > > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > > > > + the firmware for its use and is required to be saved and restored\n> > > > > + across an NVS sleep\n> > > > > + boot-code: Contains code used for booting which is not needed by the OS\n> > > > > + boot-code: Contains data used for booting which is not needed by the OS\n> > > > > + runtime-code: Contains code used for interacting with the system when\n> > > > > + running the OS\n> > > > > + runtime-data: Contains data used for interacting with the system when\n> > > > > + running the OS\n> > > > > +\n> > > > > + enum:\n> > > > > + - acpi\n> > > > > + - acpi-nvs\n> > > > > + - boot-code\n> > > > > + - boot-data\n> > > > > + - runtime-code\n> > > > > + - runtime-data\n> > > > > +\n> > >\n> > > As I mentioned a few times already, I don't think these compatibles\n> > > should be introduced here.\n> > >\n> > > A reserved region has a specific purpose, and the compatible should be\n> > > more descriptive than the enum above. If the consumer does not\n> > > understand this purpose, it should simply treat the memory as reserved\n> > > and not touch it. Alternatively, these regions can be referenced from\n> > > other DT nodes using phandles if needed.\n> >\n> > We still need some description of what these regions are used for, so\n> > that the payload can use the correct regions. I do not have any other\n> > solution to this problem. We are in v7 at present. At least explain\n> > where you want the compatible strings to be introduced.\n> >\n>\n> My point is really that by themselves, these regions are not usable by\n> either a payload or an OS that consumes this information. Unless there\n> is some other information being provided (via DT I imagine) that\n> describes how these things are supposed to be used, they are nothing\n> more than memory reservations that should be honored, and providing\n> this arbitrary set of labels is unnecessary.\n>\n> > What sort of extra detail are you looking for? Please be specific and\n> > preferably add some suggestions so I can close this out ASAP.\n> >\n>\n> A payload or OS can do nothing with a memory reservation called\n> 'runtime-code' it it doesn't know what is inside. So there is another\n> DT node somewhere that describes this, and that can simply point to\n> this region (via a phandle) if it needs to describe the\n> correspondence. This is more idiomatic for DT afaik (but I am not the\n> expert). But more importantly, it avoids overloading some vague\n> labels with behavior (e.g., executable permissions for code regions)\n> that should only be displayed for regions with a particular use,\n> rather than for a ill defined class of reservations the purpose of\n> which is not clear.\n>\n> What I am trying to avoid is the OS ending up being forced to consume\n> this information in parallel to the EFI memory map, and having to\n> reconcile them. I'd be much happier if this gets contributed to a spec\n> that only covers firmware-to-firmware, and is prevented from leaking\n> into the OS facing interface.\n\nI don't know about \"another DT node\". We don't have one at present.\n\nThere is already a note in the DT spec about this:\n\n> 3.5.4 /reserved-memory and UEFI\n\n> When booting via [UEFI], static /reserved-memory regions must also be listed in the system memory map obtained\n> via the GetMemoryMap() UEFI boot time service as defined in [UEFI] ยง 7.2. The reserved memory regions need to be\n> included in the UEFI memory map to protect against allocations by UEFI applications.\n>\n> Reserved regions with the no-map property must be listed in the memory map with type EfiReservedMemoryType. All\n> other reserved regions must be listed with type EfiBootServicesData.\n>\n> Dynamic reserved memory regions must not be listed in the [UEFI] memory map because they are allocated by the OS\n> after exiting firmware boot services.\n\nI don't fully understand what all that means, but does it cover your concern?\n\nRegards,\nSimon","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256\n header.s=google header.b=LKlO4pJS;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org\n header.b=\"LKlO4pJS\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4S2QWf5yDtz1yqF\n\tfor ; Sat, 7 Oct 2023 11:04:12 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 2B3CE86D65;\n\tSat, 7 Oct 2023 02:03:46 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id A140486CEC; Sat, 7 Oct 2023 02:03:37 +0200 (CEST)","from mail-ej1-x631.google.com (mail-ej1-x631.google.com\n [IPv6:2a00:1450:4864:20::631])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 64CAD8695F\n for ; Sat, 7 Oct 2023 02:03:33 +0200 (CEST)","by mail-ej1-x631.google.com with SMTP id\n a640c23a62f3a-9b29186e20aso472473166b.2\n for ; Fri, 06 Oct 2023 17:03:33 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-9.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,\n SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=no\n autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=chromium.org; s=google; t=1696637013; x=1697241813; darn=lists.denx.de;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=uDcsQIEmgkQ2z2v3WWS4XEV0ph0sL9LSX0+s7n0YMh4=;\n b=LKlO4pJSQvmjdoq6NiE8Luwpy11YwiaTl4Jc2LfO+v+roSSAI6hUWZcHXFd8/+LpOg\n fl0thl9YbovMREfXOSShmzxRwwSK5C+pt1v9HkLtZ/n8X1fXtJZODL8qlQNG8o+PgoZm\n uyziL3JImfw9hp6fSdHsxRRD4eelS13aONyUQ=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1696637013; x=1697241813;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc\n :subject:date:message-id:reply-to;\n bh=uDcsQIEmgkQ2z2v3WWS4XEV0ph0sL9LSX0+s7n0YMh4=;\n b=G1Z4fPgcTOK0qieK9dj0dFNhJWy5wPf3+LgiccoxeMtBo8oHxSu+T4yR6J7U4tBNI4\n CktjXc/LKwe4PMVYtyIksNJmIpbyucJebdkx1HpHBG7Dt1Nb6C8a05YaVjUeaEaYjN+V\n FVYFNhrhrdpy9p01hCPmi1+O/jSKq/fq8RTOnpsHiqjP7GgSq91zqAyvdF4RhkgnSUiD\n q/Vis3GoCpKUZVgz3GZRTwDiemKLzcBDJziGtc1vFABIGLscRALUDxJUkclL8VKy7Mg8\n yERcezemsT8ts8KeFzfTEew/buzkw7VNyXtwPRu7CwWjGSV1PN4CiuAVPiTNMy7aSDZG\n 2NQw==","X-Gm-Message-State":"AOJu0YwkHj5nqan/z8rcJyjg1ex3DaOEFk+S8ffaBMPTtxMlx+gB1Ein\n KHLzNaYL046aeU/78l4GX5C6ADLEN99zn/pFCkxbhQ==","X-Google-Smtp-Source":"\n AGHT+IHICfBlh5Jn9KCKxlRJo8KnQizgtIiA61TtzHAjgOF4pLzWyegSnBlNZCq/yTtUnR27UDOzc7A1CepkEFmMBc8=","X-Received":"by 2002:a17:906:3284:b0:9b8:e670:657b with SMTP id\n 4-20020a170906328400b009b8e670657bmr8851025ejw.64.1696637012708; Fri, 06 Oct\n 2023 17:03:32 -0700 (PDT)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n ","In-Reply-To":"\n ","From":"Simon Glass ","Date":"Fri, 6 Oct 2023 18:03:16 -0600","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Ard Biesheuvel ","Cc":"devicetree@vger.kernel.org, Mark Rutland ,\n Rob Herring , Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3195725,"web_url":"http://patchwork.ozlabs.org/comment/3195725/","msgid":"","list_archive_url":null,"date":"2023-10-09T20:14:08","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":6170,"url":"http://patchwork.ozlabs.org/api/people/6170/","name":"Simon Glass","email":"sjg@chromium.org"},"content":"Hi all,\n\nOn Fri, 6 Oct 2023 at 18:03, Simon Glass wrote:\n>\n> Hi Ard,\n>\n> On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel wrote:\n> >\n> > On Fri, 6 Oct 2023 at 20:17, Simon Glass wrote:\n> > >\n> > > Hi Ard,\n> > >\n> > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel wrote:\n> > > >\n> > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:\n> > > > >\n> > > > > Hi Rob,\n> > > > >\n> > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:\n> > > > > >\n> > > > > > It is common to split firmware into 'Platform Init', which does the\n> > > > > > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > > > > > Thus an handover interface is required between these two pieces.\n> > > > > >\n> > > > > > Where UEFI boot-time services are not available, but UEFI firmware is\n> > > > > > present on either side of this interface, information about memory usage\n> > > > > > and attributes must be presented to the \"Payload\" in some form.\n> > > > > >\n> > > > > > This aims to provide an small schema addition for the memory mapping\n> > > > > > needed to keep these two pieces working together well.\n> > > > > >\n> > > > > > Signed-off-by: Simon Glass \n> > > > > > ---\n> > > > > >\n> > > > > > Changes in v7:\n> > > > > > - Rename acpi-reclaim to acpi\n> > > > > > - Drop individual mention of when memory can be reclaimed\n> > > > > > - Rewrite the item descriptions\n> > > > > > - Add back the UEFI text (with trepidation)\n> > > > >\n> > > > > I am again checking on this series. Can it be applied, please?\n> > > > >\n> > > >\n> > > > Apologies for the delay in response. I have been away.\n> > >\n> > > OK, I hope you had a nice trip.\n> > >\n> >\n> > Thanks, it was wonderful!\n> >\n> > > >\n> > > > >\n> > > > > >\n> > > > > > Changes in v6:\n> > > > > > - Drop mention of UEFI\n> > > > > > - Use compatible strings instead of node names\n> > > > > >\n> > > > > > Changes in v5:\n> > > > > > - Drop the memory-map node (should have done that in v4)\n> > > > > > - Tidy up schema a bit\n> > > > > >\n> > > > > > Changes in v4:\n> > > > > > - Make use of the reserved-memory node instead of creating a new one\n> > > > > >\n> > > > > > Changes in v3:\n> > > > > > - Reword commit message again\n> > > > > > - cc a lot more people, from the FFI patch\n> > > > > > - Split out the attributes into the /memory nodes\n> > > > > >\n> > > > > > Changes in v2:\n> > > > > > - Reword commit message\n> > > > > >\n> > > > > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > > > > > 1 file changed, 71 insertions(+)\n> > > > > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > >\n> > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > new file mode 100644\n> > > > > > index 0000000..f7fbdfd\n> > > > > > --- /dev/null\n> > > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > @@ -0,0 +1,71 @@\n> > > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause\n> > > > > > +%YAML 1.2\n> > > > > > +---\n> > > > > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > > > > > +\n> > > > > > +title: Common memory reservations\n> > > > > > +\n> > > > > > +description: |\n> > > > > > + Specifies that the reserved memory region can be used for the purpose\n> > > > > > + indicated by its compatible string.\n> > > > > > +\n> > > > > > + Clients may reuse this reserved memory if they understand what it is for,\n> > > > > > + subject to the notes below.\n> > > > > > +\n> > > > > > +maintainers:\n> > > > > > + - Simon Glass \n> > > > > > +\n> > > > > > +allOf:\n> > > > > > + - $ref: reserved-memory.yaml\n> > > > > > +\n> > > > > > +properties:\n> > > > > > + compatible:\n> > > > > > + description: |\n> > > > > > + This describes some common memory reservations, with the compatible\n> > > > > > + string indicating what it is used for:\n> > > > > > +\n> > > > > > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > > > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > > > > > + the firmware for its use and is required to be saved and restored\n> > > > > > + across an NVS sleep\n> > > > > > + boot-code: Contains code used for booting which is not needed by the OS\n> > > > > > + boot-code: Contains data used for booting which is not needed by the OS\n> > > > > > + runtime-code: Contains code used for interacting with the system when\n> > > > > > + running the OS\n> > > > > > + runtime-data: Contains data used for interacting with the system when\n> > > > > > + running the OS\n> > > > > > +\n> > > > > > + enum:\n> > > > > > + - acpi\n> > > > > > + - acpi-nvs\n> > > > > > + - boot-code\n> > > > > > + - boot-data\n> > > > > > + - runtime-code\n> > > > > > + - runtime-data\n> > > > > > +\n> > > >\n> > > > As I mentioned a few times already, I don't think these compatibles\n> > > > should be introduced here.\n> > > >\n> > > > A reserved region has a specific purpose, and the compatible should be\n> > > > more descriptive than the enum above. If the consumer does not\n> > > > understand this purpose, it should simply treat the memory as reserved\n> > > > and not touch it. Alternatively, these regions can be referenced from\n> > > > other DT nodes using phandles if needed.\n> > >\n> > > We still need some description of what these regions are used for, so\n> > > that the payload can use the correct regions. I do not have any other\n> > > solution to this problem. We are in v7 at present. At least explain\n> > > where you want the compatible strings to be introduced.\n> > >\n> >\n> > My point is really that by themselves, these regions are not usable by\n> > either a payload or an OS that consumes this information. Unless there\n> > is some other information being provided (via DT I imagine) that\n> > describes how these things are supposed to be used, they are nothing\n> > more than memory reservations that should be honored, and providing\n> > this arbitrary set of labels is unnecessary.\n> >\n> > > What sort of extra detail are you looking for? Please be specific and\n> > > preferably add some suggestions so I can close this out ASAP.\n> > >\n> >\n> > A payload or OS can do nothing with a memory reservation called\n> > 'runtime-code' it it doesn't know what is inside. So there is another\n> > DT node somewhere that describes this, and that can simply point to\n> > this region (via a phandle) if it needs to describe the\n> > correspondence. This is more idiomatic for DT afaik (but I am not the\n> > expert). But more importantly, it avoids overloading some vague\n> > labels with behavior (e.g., executable permissions for code regions)\n> > that should only be displayed for regions with a particular use,\n> > rather than for a ill defined class of reservations the purpose of\n> > which is not clear.\n> >\n> > What I am trying to avoid is the OS ending up being forced to consume\n> > this information in parallel to the EFI memory map, and having to\n> > reconcile them. I'd be much happier if this gets contributed to a spec\n> > that only covers firmware-to-firmware, and is prevented from leaking\n> > into the OS facing interface.\n>\n> I don't know about \"another DT node\". We don't have one at present.\n>\n> There is already a note in the DT spec about this:\n>\n> > 3.5.4 /reserved-memory and UEFI\n>\n> > When booting via [UEFI], static /reserved-memory regions must also be listed in the system memory map obtained\n> > via the GetMemoryMap() UEFI boot time service as defined in [UEFI] ยง 7.2. The reserved memory regions need to be\n> > included in the UEFI memory map to protect against allocations by UEFI applications.\n> >\n> > Reserved regions with the no-map property must be listed in the memory map with type EfiReservedMemoryType. All\n> > other reserved regions must be listed with type EfiBootServicesData.\n> >\n> > Dynamic reserved memory regions must not be listed in the [UEFI] memory map because they are allocated by the OS\n> > after exiting firmware boot services.\n>\n> I don't fully understand what all that means, but does it cover your concern?\n\nI have reread the discussion on this memory-reservation problem,\nseveral dozen emails at this point. I believe we have covered\neverything.\n\nFor now we will go with the binding in this patch. I hope it can be\napplied soon, or if not, someone can send a different proposal to meet\nthe requirements.\n\nRegards,\nSimon","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256\n header.s=google header.b=J9rM5nF6;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org\n header.b=\"J9rM5nF6\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4S49HC2B1fz1ypX\n\tfor ; Tue, 10 Oct 2023 07:14:30 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 8BB9186C58;\n\tMon, 9 Oct 2023 22:14:27 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id 141C986BD0; Mon, 9 Oct 2023 22:14:25 +0200 (CEST)","from mail-ed1-x530.google.com (mail-ed1-x530.google.com\n [IPv6:2a00:1450:4864:20::530])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id D07C08642D\n for ; Mon, 9 Oct 2023 22:14:20 +0200 (CEST)","by mail-ed1-x530.google.com with SMTP id\n 4fb4d7f45d1cf-5363227cc80so8067572a12.3\n for ; Mon, 09 Oct 2023 13:14:20 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-9.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,\n SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=no\n autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=chromium.org; s=google; t=1696882460; x=1697487260; darn=lists.denx.de;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=1uXQa/ZJEUdrojO5Aa4jqc3aw9/PZXqCTxGgZi3gBeY=;\n b=J9rM5nF6CIrR4lQElhkn4zp/wSd/eKBCvQUvZ+wW+a5kpprf9CCZooZ4i2tYm2GmMN\n SYHMO643r7722f2HP0TyNlIT+t2MBXq1LngCnT0TDag//ez+pufVwTIMVVX/7M8E6WAw\n E/Qi9OV8c07qARz93n6oFmYNeqA7DZaJ+/eDM=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1696882460; x=1697487260;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc\n :subject:date:message-id:reply-to;\n bh=1uXQa/ZJEUdrojO5Aa4jqc3aw9/PZXqCTxGgZi3gBeY=;\n b=Q9T5gJU7GZw1MHBK/z36jghmCzFAwytoWaqsxnqA5pU53//M18NlhgPDuVeBEZRQCV\n HQfpY+peREOw13cVDIKGhU3x6x/5TG1MCHjSwGCLvRl7f+2kZfOzKslDjbQ75Ul2mljN\n +w3cs3GD09O/xmcp9ZCN+mwaa91xg9VobswggiJ4v8Gi5Y2Ryu5Bn54ZihoDrVaTZGN5\n mqHckVtzfuTPGTSZ9aTIglDeVYFgAg06b2vsPLGf+jyzm7IyaaozrKR1L4N7OmlTfEE+\n QoFaseY4wY9iyOowfrnsRs1xi9/VcrCAcnCDaghoy/ct06Tqg+0rxWbgf2/zCBWj6VgE\n Eh4A==","X-Gm-Message-State":"AOJu0Yyp9g1EuZfphYJAhy3FjMzGVGynrvmDTbts2fuCpTLTwLZiTE/P\n 0eyirqao5z8SEXqN27MwSZbRpfQLHLYfEySGu8wyMA==","X-Google-Smtp-Source":"\n AGHT+IFDWJjckfskC1B6/f5654aTGjBi2cIOSwQzya/T2F9iuEa5b2KYet9co1B2GIPdNo7j/JwjDyd82T613LqkAcw=","X-Received":"by 2002:a17:907:2ccf:b0:9a1:f73b:90ce with SMTP id\n hg15-20020a1709072ccf00b009a1f73b90cemr14217955ejc.54.1696882460035; Mon, 09\n Oct 2023 13:14:20 -0700 (PDT)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n ","In-Reply-To":"\n ","From":"Simon Glass ","Date":"Mon, 9 Oct 2023 14:14:08 -0600","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Ard Biesheuvel ","Cc":"devicetree@vger.kernel.org, Mark Rutland ,\n Rob Herring , Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3197479,"web_url":"http://patchwork.ozlabs.org/comment/3197479/","msgid":"","list_archive_url":null,"date":"2023-10-11T20:40:02","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":77831,"url":"http://patchwork.ozlabs.org/api/people/77831/","name":"Ard Biesheuvel","email":"ardb@kernel.org"},"content":"On Sat, 7 Oct 2023 at 02:03, Simon Glass wrote:\n>\n> Hi Ard,\n>\n> On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel wrote:\n> >\n> > On Fri, 6 Oct 2023 at 20:17, Simon Glass wrote:\n> > >\n> > > Hi Ard,\n> > >\n> > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel wrote:\n> > > >\n> > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:\n> > > > >\n> > > > > Hi Rob,\n> > > > >\n> > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:\n> > > > > >\n> > > > > > It is common to split firmware into 'Platform Init', which does the\n> > > > > > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > > > > > Thus an handover interface is required between these two pieces.\n> > > > > >\n> > > > > > Where UEFI boot-time services are not available, but UEFI firmware is\n> > > > > > present on either side of this interface, information about memory usage\n> > > > > > and attributes must be presented to the \"Payload\" in some form.\n> > > > > >\n> > > > > > This aims to provide an small schema addition for the memory mapping\n> > > > > > needed to keep these two pieces working together well.\n> > > > > >\n> > > > > > Signed-off-by: Simon Glass \n> > > > > > ---\n> > > > > >\n> > > > > > Changes in v7:\n> > > > > > - Rename acpi-reclaim to acpi\n> > > > > > - Drop individual mention of when memory can be reclaimed\n> > > > > > - Rewrite the item descriptions\n> > > > > > - Add back the UEFI text (with trepidation)\n> > > > >\n> > > > > I am again checking on this series. Can it be applied, please?\n> > > > >\n> > > >\n> > > > Apologies for the delay in response. I have been away.\n> > >\n> > > OK, I hope you had a nice trip.\n> > >\n> >\n> > Thanks, it was wonderful!\n> >\n> > > >\n> > > > >\n> > > > > >\n> > > > > > Changes in v6:\n> > > > > > - Drop mention of UEFI\n> > > > > > - Use compatible strings instead of node names\n> > > > > >\n> > > > > > Changes in v5:\n> > > > > > - Drop the memory-map node (should have done that in v4)\n> > > > > > - Tidy up schema a bit\n> > > > > >\n> > > > > > Changes in v4:\n> > > > > > - Make use of the reserved-memory node instead of creating a new one\n> > > > > >\n> > > > > > Changes in v3:\n> > > > > > - Reword commit message again\n> > > > > > - cc a lot more people, from the FFI patch\n> > > > > > - Split out the attributes into the /memory nodes\n> > > > > >\n> > > > > > Changes in v2:\n> > > > > > - Reword commit message\n> > > > > >\n> > > > > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > > > > > 1 file changed, 71 insertions(+)\n> > > > > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > >\n> > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > new file mode 100644\n> > > > > > index 0000000..f7fbdfd\n> > > > > > --- /dev/null\n> > > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > @@ -0,0 +1,71 @@\n> > > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause\n> > > > > > +%YAML 1.2\n> > > > > > +---\n> > > > > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > > > > > +\n> > > > > > +title: Common memory reservations\n> > > > > > +\n> > > > > > +description: |\n> > > > > > + Specifies that the reserved memory region can be used for the purpose\n> > > > > > + indicated by its compatible string.\n> > > > > > +\n> > > > > > + Clients may reuse this reserved memory if they understand what it is for,\n> > > > > > + subject to the notes below.\n> > > > > > +\n> > > > > > +maintainers:\n> > > > > > + - Simon Glass \n> > > > > > +\n> > > > > > +allOf:\n> > > > > > + - $ref: reserved-memory.yaml\n> > > > > > +\n> > > > > > +properties:\n> > > > > > + compatible:\n> > > > > > + description: |\n> > > > > > + This describes some common memory reservations, with the compatible\n> > > > > > + string indicating what it is used for:\n> > > > > > +\n> > > > > > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > > > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > > > > > + the firmware for its use and is required to be saved and restored\n> > > > > > + across an NVS sleep\n> > > > > > + boot-code: Contains code used for booting which is not needed by the OS\n> > > > > > + boot-code: Contains data used for booting which is not needed by the OS\n> > > > > > + runtime-code: Contains code used for interacting with the system when\n> > > > > > + running the OS\n> > > > > > + runtime-data: Contains data used for interacting with the system when\n> > > > > > + running the OS\n> > > > > > +\n> > > > > > + enum:\n> > > > > > + - acpi\n> > > > > > + - acpi-nvs\n> > > > > > + - boot-code\n> > > > > > + - boot-data\n> > > > > > + - runtime-code\n> > > > > > + - runtime-data\n> > > > > > +\n> > > >\n> > > > As I mentioned a few times already, I don't think these compatibles\n> > > > should be introduced here.\n> > > >\n> > > > A reserved region has a specific purpose, and the compatible should be\n> > > > more descriptive than the enum above. If the consumer does not\n> > > > understand this purpose, it should simply treat the memory as reserved\n> > > > and not touch it. Alternatively, these regions can be referenced from\n> > > > other DT nodes using phandles if needed.\n> > >\n> > > We still need some description of what these regions are used for, so\n> > > that the payload can use the correct regions. I do not have any other\n> > > solution to this problem. We are in v7 at present. At least explain\n> > > where you want the compatible strings to be introduced.\n> > >\n> >\n> > My point is really that by themselves, these regions are not usable by\n> > either a payload or an OS that consumes this information. Unless there\n> > is some other information being provided (via DT I imagine) that\n> > describes how these things are supposed to be used, they are nothing\n> > more than memory reservations that should be honored, and providing\n> > this arbitrary set of labels is unnecessary.\n> >\n> > > What sort of extra detail are you looking for? Please be specific and\n> > > preferably add some suggestions so I can close this out ASAP.\n> > >\n> >\n> > A payload or OS can do nothing with a memory reservation called\n> > 'runtime-code' it it doesn't know what is inside. So there is another\n> > DT node somewhere that describes this, and that can simply point to\n> > this region (via a phandle) if it needs to describe the\n> > correspondence. This is more idiomatic for DT afaik (but I am not the\n> > expert). But more importantly, it avoids overloading some vague\n> > labels with behavior (e.g., executable permissions for code regions)\n> > that should only be displayed for regions with a particular use,\n> > rather than for a ill defined class of reservations the purpose of\n> > which is not clear.\n> >\n> > What I am trying to avoid is the OS ending up being forced to consume\n> > this information in parallel to the EFI memory map, and having to\n> > reconcile them. I'd be much happier if this gets contributed to a spec\n> > that only covers firmware-to-firmware, and is prevented from leaking\n> > into the OS facing interface.\n>\n> I don't know about \"another DT node\". We don't have one at present.\n>\n> There is already a note in the DT spec about this:\n>\n> > 3.5.4 /reserved-memory and UEFI\n>\n> > When booting via [UEFI], static /reserved-memory regions must also be listed in the system memory map obtained\n> > via the GetMemoryMap() UEFI boot time service as defined in [UEFI] ยง 7.2. The reserved memory regions need to be\n> > included in the UEFI memory map to protect against allocations by UEFI applications.\n> >\n> > Reserved regions with the no-map property must be listed in the memory map with type EfiReservedMemoryType. All\n> > other reserved regions must be listed with type EfiBootServicesData.\n> >\n> > Dynamic reserved memory regions must not be listed in the [UEFI] memory map because they are allocated by the OS\n> > after exiting firmware boot services.\n>\n> I don't fully understand what all that means, but does it cover your concern?\n>\n\nI don't fully agree with the wording here, but apparently there is\nsome awareness here of the concerns I raised.\n\nInterestingly, 'when booting via UEFI' becomes a bit ambiguous now,\ngiven that DT is passed from stage to stage, and not every handover is\nbooting via UEFI. In general, I think the introduction of bindings\nthat cover areas other than the handover from the final boot loader to\nthe OS may create some more confusion later on, but I'll leave it up\nto the DT bindings maintainer to reason about that.\n\nIf you are dead set on introducing these items (and I note that you\nstill have not provided an actual example of how a PI -> payload\nhandover would make use of runtime-code or boot-code reservations), I\nwon't keep standing in your way.\n\nThanks for the discussion, and apologies for dragging this out.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=QrOIIgod;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.b=\"QrOIIgod\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de; spf=pass smtp.mailfrom=ardb@kernel.org"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4S5QVb4B06z1ypX\n\tfor ; Thu, 12 Oct 2023 08:13:41 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 792C686D85;\n\tWed, 11 Oct 2023 22:45:17 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id 90C5386CA1; Wed, 11 Oct 2023 22:41:58 +0200 (CEST)","from dfw.source.kernel.org (dfw.source.kernel.org\n [IPv6:2604:1380:4641:c500::1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 24C2D86B7A\n for ; Wed, 11 Oct 2023 22:40:56 +0200 (CEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by dfw.source.kernel.org (Postfix) with ESMTP id D584161988\n for ; Wed, 11 Oct 2023 20:40:15 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 83AF7C433CB\n for ; Wed, 11 Oct 2023 20:40:15 +0000 (UTC)","by mail-lf1-f49.google.com with SMTP id\n 2adb3069b0e04-5068dab8c00so408613e87.0\n for ; Wed, 11 Oct 2023 13:40:15 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS autolearn=ham autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1697056815;\n bh=8L5mXgJHZV0x1PMI3MCpHodGYPRdonPcTU4tFSKPg/g=;\n h=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n b=QrOIIgodWJOdpY6O5VZgof/a//29t0nzABmW+7z82j47UpXNZ4GLczHKF08ca2yHV\n cmFjzuojFU3Apr7fbL4yexD8/yTXJH7qFzBw8t6940OTYB+Gexcdm1/BJDW7Is6Jhs\n 1AZUuxJjmQBbEQb4Iid/0eI9mRjK7c79dpmx91ZJnW3X1aBh0twEptjaIhwdNTiU+6\n 1WjMLrDEx/iVfgiujG+M06i/7Ehi/ggxsJCSviXawcYXyye4cf3UE/BE4zKH4dZmCT\n /tnCUGZQNjAVcBpnFOOZJHN63AuwMVphQB5z+eT4PlTIHKLjI0KtZRTQ6AbKlMk70i\n QquwesXiDCvfA==","X-Gm-Message-State":"AOJu0Ywvf52kDi3VJLnbNjTeD9/Llr2Kn3/fuy6S97K/3uHa0QCpcCns\n 5SAvBlSVf+Qom4lbwnHtSkSbbO3P+null2rvw78=","X-Google-Smtp-Source":"\n AGHT+IHQ62Gr7p4zlUczVxkcGxszjmTDmRGC0aE+SwxQcshlalF+lD+86JdoH0aKJLHW5Rbj9z4dRv/jeaZgPWyT1PY=","X-Received":"by 2002:a05:6512:3902:b0:502:fdca:2eab with SMTP id\n a2-20020a056512390200b00502fdca2eabmr15087253lfu.37.1697056813622; Wed, 11\n Oct 2023 13:40:13 -0700 (PDT)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n ","In-Reply-To":"\n ","From":"Ard Biesheuvel ","Date":"Wed, 11 Oct 2023 22:40:02 +0200","X-Gmail-Original-Message-ID":"\n ","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Simon Glass ","Cc":"devicetree@vger.kernel.org, Mark Rutland ,\n Rob Herring , Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3199141,"web_url":"http://patchwork.ozlabs.org/comment/3199141/","msgid":"","list_archive_url":null,"date":"2023-10-13T20:42:00","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring","email":"robh@kernel.org"},"content":"On Fri, Oct 6, 2023 at 7:03โ€ฏPM Simon Glass wrote:\n>\n> Hi Ard,\n>\n> On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel wrote:\n> >\n> > On Fri, 6 Oct 2023 at 20:17, Simon Glass wrote:\n> > >\n> > > Hi Ard,\n> > >\n> > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel wrote:\n> > > >\n> > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:\n> > > > >\n> > > > > Hi Rob,\n> > > > >\n> > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:\n> > > > > >\n> > > > > > It is common to split firmware into 'Platform Init', which does the\n> > > > > > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > > > > > Thus an handover interface is required between these two pieces.\n> > > > > >\n> > > > > > Where UEFI boot-time services are not available, but UEFI firmware is\n> > > > > > present on either side of this interface, information about memory usage\n> > > > > > and attributes must be presented to the \"Payload\" in some form.\n> > > > > >\n> > > > > > This aims to provide an small schema addition for the memory mapping\n> > > > > > needed to keep these two pieces working together well.\n> > > > > >\n> > > > > > Signed-off-by: Simon Glass \n> > > > > > ---\n> > > > > >\n> > > > > > Changes in v7:\n> > > > > > - Rename acpi-reclaim to acpi\n> > > > > > - Drop individual mention of when memory can be reclaimed\n> > > > > > - Rewrite the item descriptions\n> > > > > > - Add back the UEFI text (with trepidation)\n> > > > >\n> > > > > I am again checking on this series. Can it be applied, please?\n> > > > >\n> > > >\n> > > > Apologies for the delay in response. I have been away.\n> > >\n> > > OK, I hope you had a nice trip.\n> > >\n> >\n> > Thanks, it was wonderful!\n> >\n> > > >\n> > > > >\n> > > > > >\n> > > > > > Changes in v6:\n> > > > > > - Drop mention of UEFI\n> > > > > > - Use compatible strings instead of node names\n> > > > > >\n> > > > > > Changes in v5:\n> > > > > > - Drop the memory-map node (should have done that in v4)\n> > > > > > - Tidy up schema a bit\n> > > > > >\n> > > > > > Changes in v4:\n> > > > > > - Make use of the reserved-memory node instead of creating a new one\n> > > > > >\n> > > > > > Changes in v3:\n> > > > > > - Reword commit message again\n> > > > > > - cc a lot more people, from the FFI patch\n> > > > > > - Split out the attributes into the /memory nodes\n> > > > > >\n> > > > > > Changes in v2:\n> > > > > > - Reword commit message\n> > > > > >\n> > > > > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > > > > > 1 file changed, 71 insertions(+)\n> > > > > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > >\n> > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > new file mode 100644\n> > > > > > index 0000000..f7fbdfd\n> > > > > > --- /dev/null\n> > > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > @@ -0,0 +1,71 @@\n> > > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause\n> > > > > > +%YAML 1.2\n> > > > > > +---\n> > > > > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > > > > > +\n> > > > > > +title: Common memory reservations\n> > > > > > +\n> > > > > > +description: |\n> > > > > > + Specifies that the reserved memory region can be used for the purpose\n> > > > > > + indicated by its compatible string.\n> > > > > > +\n> > > > > > + Clients may reuse this reserved memory if they understand what it is for,\n> > > > > > + subject to the notes below.\n> > > > > > +\n> > > > > > +maintainers:\n> > > > > > + - Simon Glass \n> > > > > > +\n> > > > > > +allOf:\n> > > > > > + - $ref: reserved-memory.yaml\n> > > > > > +\n> > > > > > +properties:\n> > > > > > + compatible:\n> > > > > > + description: |\n> > > > > > + This describes some common memory reservations, with the compatible\n> > > > > > + string indicating what it is used for:\n> > > > > > +\n> > > > > > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > > > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > > > > > + the firmware for its use and is required to be saved and restored\n> > > > > > + across an NVS sleep\n> > > > > > + boot-code: Contains code used for booting which is not needed by the OS\n> > > > > > + boot-code: Contains data used for booting which is not needed by the OS\n> > > > > > + runtime-code: Contains code used for interacting with the system when\n> > > > > > + running the OS\n> > > > > > + runtime-data: Contains data used for interacting with the system when\n> > > > > > + running the OS\n> > > > > > +\n> > > > > > + enum:\n> > > > > > + - acpi\n> > > > > > + - acpi-nvs\n> > > > > > + - boot-code\n> > > > > > + - boot-data\n> > > > > > + - runtime-code\n> > > > > > + - runtime-data\n> > > > > > +\n> > > >\n> > > > As I mentioned a few times already, I don't think these compatibles\n> > > > should be introduced here.\n> > > >\n> > > > A reserved region has a specific purpose, and the compatible should be\n> > > > more descriptive than the enum above. If the consumer does not\n> > > > understand this purpose, it should simply treat the memory as reserved\n> > > > and not touch it. Alternatively, these regions can be referenced from\n> > > > other DT nodes using phandles if needed.\n> > >\n> > > We still need some description of what these regions are used for, so\n> > > that the payload can use the correct regions. I do not have any other\n> > > solution to this problem. We are in v7 at present. At least explain\n> > > where you want the compatible strings to be introduced.\n> > >\n> >\n> > My point is really that by themselves, these regions are not usable by\n> > either a payload or an OS that consumes this information. Unless there\n> > is some other information being provided (via DT I imagine) that\n> > describes how these things are supposed to be used, they are nothing\n> > more than memory reservations that should be honored, and providing\n> > this arbitrary set of labels is unnecessary.\n> >\n> > > What sort of extra detail are you looking for? Please be specific and\n> > > preferably add some suggestions so I can close this out ASAP.\n> > >\n> >\n> > A payload or OS can do nothing with a memory reservation called\n> > 'runtime-code' it it doesn't know what is inside.\n\nAgreed. The question is WHAT runtime-code? The compatible needs to answer that.\n\nFor example, we have 'ramoops' as a compatible in reserved memory.\nThat tells us *exactly* what's there. We know how to parse it. If we\nknow ramoops is not supported, then we know we can toss it out and\nreclaim the memory.\n\n\n> > So there is another\n> > DT node somewhere that describes this, and that can simply point to\n> > this region (via a phandle) if it needs to describe the\n> > correspondence. This is more idiomatic for DT afaik (but I am not the\n> > expert).\n\nI don't see why we need that indirection.\n\n> > But more importantly, it avoids overloading some vague\n> > labels with behavior (e.g., executable permissions for code regions)\n> > that should only be displayed for regions with a particular use,\n> > rather than for a ill defined class of reservations the purpose of\n> > which is not clear.\n> >\n> > What I am trying to avoid is the OS ending up being forced to consume\n> > this information in parallel to the EFI memory map, and having to\n> > reconcile them. I'd be much happier if this gets contributed to a spec\n> > that only covers firmware-to-firmware, and is prevented from leaking\n> > into the OS facing interface.\n>\n> I don't know about \"another DT node\". We don't have one at present.\n>\n> There is already a note in the DT spec about this:\n>\n> > 3.5.4 /reserved-memory and UEFI\n>\n> > When booting via [UEFI], static /reserved-memory regions must also be listed in the system memory map obtained\n> > via the GetMemoryMap() UEFI boot time service as defined in [UEFI] ยง 7.2. The reserved memory regions need to be\n> > included in the UEFI memory map to protect against allocations by UEFI applications.\n> >\n> > Reserved regions with the no-map property must be listed in the memory map with type EfiReservedMemoryType. All\n> > other reserved regions must be listed with type EfiBootServicesData.\n> >\n> > Dynamic reserved memory regions must not be listed in the [UEFI] memory map because they are allocated by the OS\n> > after exiting firmware boot services.\n>\n> I don't fully understand what all that means, but does it cover your concern?\n\nThis section is purely about using UEFI mechanisms to load and boot\nthe OS. If we're not talking about this stage of booting, then none of\nthis applies.\n\nRob","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=a9MZmd4W;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.b=\"a9MZmd4W\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de; spf=pass smtp.mailfrom=robh@kernel.org"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4S6dkD1WDPz1yqj\n\tfor ; Sat, 14 Oct 2023 07:42:58 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id F0DB886EC4;\n\tFri, 13 Oct 2023 22:42:42 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id 1211186ED3; Fri, 13 Oct 2023 22:42:34 +0200 (CEST)","from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 0162586EB9\n for ; Fri, 13 Oct 2023 22:42:16 +0200 (CEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by dfw.source.kernel.org (Postfix) with ESMTP id 3E4FA621E4\n for ; Fri, 13 Oct 2023 20:42:15 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 9A418C43391\n for ; Fri, 13 Oct 2023 20:42:14 +0000 (UTC)","by mail-lf1-f43.google.com with SMTP id\n 2adb3069b0e04-5079fa1bbf8so631964e87.0\n for ; Fri, 13 Oct 2023 13:42:14 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS autolearn=ham autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1697229734;\n bh=QedSm7IKkC09g8K3qwvy20LU//M50NwLS1IxJ9WwyJI=;\n h=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n b=a9MZmd4WNOULw62DDrmkoCcloPckNv8puimcdTStZjSnlgKOeJLg7w214syisdfw7\n +EDhLsRxSBmYSDWYJ0853Fqtm3q1bx12EecKRKn0ltWrvWBeZKCVI6YeUK2cq7aTi/\n eemXY0FqN+FFSEclNZhAVBYPGQ4yOaQ811nYuPY6zexB7sEZPqDr4jJAq+e2Bu/3tn\n IHmhTE9wC3Goa6HtdgSkw2PAqshQ0RLwvE4fXR5JKO7y0X7xvKnhdtyS1rHHo6kVZa\n LEWgHxSxNXcw0CEdtsOwwj9EWOEiWlFZNS9/5+spyCkXqXtuzksCuJe4OTcXEXmYxX\n cJhnG6Rr5GxKA==","X-Gm-Message-State":"AOJu0YybD7FNwKJV71uM5uOvSI9SrQFM8pNnZztbpfpCKQ3x3DwjZ2Ta\n YmAtZMXD1He0Qn20WR8bsxBLbnz9XXWH/p3NzQ==","X-Google-Smtp-Source":"\n AGHT+IFkOrZNk8wWFwlBJcf/yE0XhIdqYph8oMA9Z+tuzUogoVeyAPSThh8ZpntpX2Q8yFyz3XaeAQLdLNs3D7Bw9PU=","X-Received":"by 2002:ac2:5f55:0:b0:502:ffff:feff with SMTP id\n 21-20020ac25f55000000b00502fffffeffmr20811060lfz.58.1697229732643; Fri, 13\n Oct 2023 13:42:12 -0700 (PDT)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n ","In-Reply-To":"\n ","From":"Rob Herring ","Date":"Fri, 13 Oct 2023 15:42:00 -0500","X-Gmail-Original-Message-ID":"\n ","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Simon Glass ","Cc":"Ard Biesheuvel , devicetree@vger.kernel.org,\n Mark Rutland ,\n Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3199148,"web_url":"http://patchwork.ozlabs.org/comment/3199148/","msgid":"","list_archive_url":null,"date":"2023-10-13T21:09:15","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":6170,"url":"http://patchwork.ozlabs.org/api/people/6170/","name":"Simon Glass","email":"sjg@chromium.org"},"content":"Hi Rob,\n\nOn Fri, 13 Oct 2023 at 13:42, Rob Herring wrote:\n>\n> On Fri, Oct 6, 2023 at 7:03โ€ฏPM Simon Glass wrote:\n> >\n> > Hi Ard,\n> >\n> > On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel wrote:\n> > >\n> > > On Fri, 6 Oct 2023 at 20:17, Simon Glass wrote:\n> > > >\n> > > > Hi Ard,\n> > > >\n> > > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel wrote:\n> > > > >\n> > > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:\n> > > > > >\n> > > > > > Hi Rob,\n> > > > > >\n> > > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:\n> > > > > > >\n> > > > > > > It is common to split firmware into 'Platform Init', which does the\n> > > > > > > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > > > > > > Thus an handover interface is required between these two pieces.\n> > > > > > >\n> > > > > > > Where UEFI boot-time services are not available, but UEFI firmware is\n> > > > > > > present on either side of this interface, information about memory usage\n> > > > > > > and attributes must be presented to the \"Payload\" in some form.\n> > > > > > >\n> > > > > > > This aims to provide an small schema addition for the memory mapping\n> > > > > > > needed to keep these two pieces working together well.\n> > > > > > >\n> > > > > > > Signed-off-by: Simon Glass \n> > > > > > > ---\n> > > > > > >\n> > > > > > > Changes in v7:\n> > > > > > > - Rename acpi-reclaim to acpi\n> > > > > > > - Drop individual mention of when memory can be reclaimed\n> > > > > > > - Rewrite the item descriptions\n> > > > > > > - Add back the UEFI text (with trepidation)\n> > > > > >\n> > > > > > I am again checking on this series. Can it be applied, please?\n> > > > > >\n> > > > >\n> > > > > Apologies for the delay in response. I have been away.\n> > > >\n> > > > OK, I hope you had a nice trip.\n> > > >\n> > >\n> > > Thanks, it was wonderful!\n> > >\n> > > > >\n> > > > > >\n> > > > > > >\n> > > > > > > Changes in v6:\n> > > > > > > - Drop mention of UEFI\n> > > > > > > - Use compatible strings instead of node names\n> > > > > > >\n> > > > > > > Changes in v5:\n> > > > > > > - Drop the memory-map node (should have done that in v4)\n> > > > > > > - Tidy up schema a bit\n> > > > > > >\n> > > > > > > Changes in v4:\n> > > > > > > - Make use of the reserved-memory node instead of creating a new one\n> > > > > > >\n> > > > > > > Changes in v3:\n> > > > > > > - Reword commit message again\n> > > > > > > - cc a lot more people, from the FFI patch\n> > > > > > > - Split out the attributes into the /memory nodes\n> > > > > > >\n> > > > > > > Changes in v2:\n> > > > > > > - Reword commit message\n> > > > > > >\n> > > > > > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > > > > > > 1 file changed, 71 insertions(+)\n> > > > > > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > >\n> > > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > new file mode 100644\n> > > > > > > index 0000000..f7fbdfd\n> > > > > > > --- /dev/null\n> > > > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > @@ -0,0 +1,71 @@\n> > > > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause\n> > > > > > > +%YAML 1.2\n> > > > > > > +---\n> > > > > > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > > > > > > +\n> > > > > > > +title: Common memory reservations\n> > > > > > > +\n> > > > > > > +description: |\n> > > > > > > + Specifies that the reserved memory region can be used for the purpose\n> > > > > > > + indicated by its compatible string.\n> > > > > > > +\n> > > > > > > + Clients may reuse this reserved memory if they understand what it is for,\n> > > > > > > + subject to the notes below.\n> > > > > > > +\n> > > > > > > +maintainers:\n> > > > > > > + - Simon Glass \n> > > > > > > +\n> > > > > > > +allOf:\n> > > > > > > + - $ref: reserved-memory.yaml\n> > > > > > > +\n> > > > > > > +properties:\n> > > > > > > + compatible:\n> > > > > > > + description: |\n> > > > > > > + This describes some common memory reservations, with the compatible\n> > > > > > > + string indicating what it is used for:\n> > > > > > > +\n> > > > > > > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > > > > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > > > > > > + the firmware for its use and is required to be saved and restored\n> > > > > > > + across an NVS sleep\n> > > > > > > + boot-code: Contains code used for booting which is not needed by the OS\n> > > > > > > + boot-code: Contains data used for booting which is not needed by the OS\n> > > > > > > + runtime-code: Contains code used for interacting with the system when\n> > > > > > > + running the OS\n> > > > > > > + runtime-data: Contains data used for interacting with the system when\n> > > > > > > + running the OS\n> > > > > > > +\n> > > > > > > + enum:\n> > > > > > > + - acpi\n> > > > > > > + - acpi-nvs\n> > > > > > > + - boot-code\n> > > > > > > + - boot-data\n> > > > > > > + - runtime-code\n> > > > > > > + - runtime-data\n> > > > > > > +\n> > > > >\n> > > > > As I mentioned a few times already, I don't think these compatibles\n> > > > > should be introduced here.\n> > > > >\n> > > > > A reserved region has a specific purpose, and the compatible should be\n> > > > > more descriptive than the enum above. If the consumer does not\n> > > > > understand this purpose, it should simply treat the memory as reserved\n> > > > > and not touch it. Alternatively, these regions can be referenced from\n> > > > > other DT nodes using phandles if needed.\n> > > >\n> > > > We still need some description of what these regions are used for, so\n> > > > that the payload can use the correct regions. I do not have any other\n> > > > solution to this problem. We are in v7 at present. At least explain\n> > > > where you want the compatible strings to be introduced.\n> > > >\n> > >\n> > > My point is really that by themselves, these regions are not usable by\n> > > either a payload or an OS that consumes this information. Unless there\n> > > is some other information being provided (via DT I imagine) that\n> > > describes how these things are supposed to be used, they are nothing\n> > > more than memory reservations that should be honored, and providing\n> > > this arbitrary set of labels is unnecessary.\n> > >\n> > > > What sort of extra detail are you looking for? Please be specific and\n> > > > preferably add some suggestions so I can close this out ASAP.\n> > > >\n> > >\n> > > A payload or OS can do nothing with a memory reservation called\n> > > 'runtime-code' it it doesn't know what is inside.\n>\n> Agreed. The question is WHAT runtime-code? The compatible needs to answer that.\n>\n> For example, we have 'ramoops' as a compatible in reserved memory.\n> That tells us *exactly* what's there. We know how to parse it. If we\n> know ramoops is not supported, then we know we can toss it out and\n> reclaim the memory.\n\nSo if we said:\n\n compatible = \"runtime-code-efi\"\n\nwould that be OK? We seem to be in catch 22 here, because if I don't\nmention EFI unhappy, but if I do, Ard is unhappy.\n\nWhat about the boottime code....you want to know which project it is from?\n\n+ - acpi\n+ - acpi-nvs\n\nThose two should be enough info, right?\n\n+ - boot-code\n+ - boot-data\n\nFor these, they don't pertain to the OS, so perhaps they are OK? In\nany case, using a generic term like this makes some sense to me. We\ncan always add a new compatible like \"efi-boottime-services\" later. It\nmay be that the boottime services would be handled by the payload, so\nnot needed in all cases.\n\n+ - runtime-code\n+ - runtime-data\n\nSee above.\n\n>\n>\n> > > So there is another\n> > > DT node somewhere that describes this, and that can simply point to\n> > > this region (via a phandle) if it needs to describe the\n> > > correspondence. This is more idiomatic for DT afaik (but I am not the\n> > > expert).\n>\n> I don't see why we need that indirection.\n>\n> > > But more importantly, it avoids overloading some vague\n> > > labels with behavior (e.g., executable permissions for code regions)\n> > > that should only be displayed for regions with a particular use,\n> > > rather than for a ill defined class of reservations the purpose of\n> > > which is not clear.\n> > >\n> > > What I am trying to avoid is the OS ending up being forced to consume\n> > > this information in parallel to the EFI memory map, and having to\n> > > reconcile them. I'd be much happier if this gets contributed to a spec\n> > > that only covers firmware-to-firmware, and is prevented from leaking\n> > > into the OS facing interface.\n> >\n> > I don't know about \"another DT node\". We don't have one at present.\n> >\n> > There is already a note in the DT spec about this:\n> >\n> > > 3.5.4 /reserved-memory and UEFI\n> >\n> > > When booting via [UEFI], static /reserved-memory regions must also be listed in the system memory map obtained\n> > > via the GetMemoryMap() UEFI boot time service as defined in [UEFI] ยง 7.2. The reserved memory regions need to be\n> > > included in the UEFI memory map to protect against allocations by UEFI applications.\n> > >\n> > > Reserved regions with the no-map property must be listed in the memory map with type EfiReservedMemoryType. All\n> > > other reserved regions must be listed with type EfiBootServicesData.\n> > >\n> > > Dynamic reserved memory regions must not be listed in the [UEFI] memory map because they are allocated by the OS\n> > > after exiting firmware boot services.\n> >\n> > I don't fully understand what all that means, but does it cover your concern?\n>\n> This section is purely about using UEFI mechanisms to load and boot\n> the OS. If we're not talking about this stage of booting, then none of\n> this applies.\n\nOK\n\nRegards,\nSimon","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256\n header.s=google header.b=C6jQjVEB;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org\n header.b=\"C6jQjVEB\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4S6fYb71Jlz1ypX\n\tfor ; Sat, 14 Oct 2023 08:20:34 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id EFDE886EF6;\n\tFri, 13 Oct 2023 23:12:57 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id E27AD86EF6; Fri, 13 Oct 2023 23:12:17 +0200 (CEST)","from mail-ej1-x636.google.com (mail-ej1-x636.google.com\n [IPv6:2a00:1450:4864:20::636])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 3631A86F16\n for ; Fri, 13 Oct 2023 23:09:33 +0200 (CEST)","by mail-ej1-x636.google.com with SMTP id\n a640c23a62f3a-99bdeae1d0aso405969666b.1\n for ; Fri, 13 Oct 2023 14:09:33 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-9.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,\n SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=no\n autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=chromium.org; s=google; t=1697231373; x=1697836173; darn=lists.denx.de;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=vXEzu9S4cTD1Jlef4EbosXRYiSQebTwp28XSIMu0qBA=;\n b=C6jQjVEB5a0+XGm/GM0gpu7p5yOz53zU+EKW+qV4mVOlDudft/17rYkNNfIEA5oeOA\n Pfjb4Cy1Vn2AaOk+XdDMLwvrrWDjgX4w+R00XckgpTBIefKtgb8Pp68OUVYcVFvK9SvC\n +Y+NoTeGPAlpBYODazqYvTaVvlp0XNHWkf44c=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1697231373; x=1697836173;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc\n :subject:date:message-id:reply-to;\n bh=vXEzu9S4cTD1Jlef4EbosXRYiSQebTwp28XSIMu0qBA=;\n b=v+yNrXIbeU/Fq1Owgej/ozR5Pb+Xv5LJCxZs9GDvVpvyShtGavyHkJhQ+GgamoEgvt\n jxzNngYkK4WCssNIYdNQLi+zM60gPy9hLfX/TUYKX6MqVK1wBoHQc8OmmatXJLTAhGJp\n VBtgNaqXRuEr6pI890uIKrJohc//xcri+AQc4jRUd88pSm5ePs5LfkHm5wB1r7fLUbdG\n sYywdI9/8R3z4kCOnJO8bI71UFjYjuf7oFos96sAqIq/PjaCdhXahz3a/xpQjTVmOJoD\n aC+yAX1ZZxU/ihg1C6FWsnGGsIlKpx6m7utwA/omdDXAiDPNiUxfncViPrOkGYryLzfQ\n QdRQ==","X-Gm-Message-State":"AOJu0YxqepJ9RYO+6dZzuIRtaJN6zcCGGJUEv5P8gd/eD3gATmn46Gs/\n nFHSGPEVuPEwagxjPJ+vkMUTKQGip/4RtibX/YntCw==","X-Google-Smtp-Source":"\n AGHT+IHmxjxpI1dzCqOIpM4CdU2WHdn17ADIZsaY2gUSzuoMBzjvaHGwQccnyUNZpYlp75gD2PzN046fNA3cYMBv4C0=","X-Received":"by 2002:a17:906:314f:b0:9b0:169b:eece with SMTP id\n e15-20020a170906314f00b009b0169beecemr24735226eje.40.1697231372221; Fri, 13\n Oct 2023 14:09:32 -0700 (PDT)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Simon Glass ","Date":"Fri, 13 Oct 2023 14:09:15 -0700","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Rob Herring ","Cc":"Ard Biesheuvel , devicetree@vger.kernel.org,\n Mark Rutland ,\n Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3200141,"web_url":"http://patchwork.ozlabs.org/comment/3200141/","msgid":"","list_archive_url":null,"date":"2023-10-16T16:50:00","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring","email":"robh@kernel.org"},"content":"On Fri, Oct 13, 2023 at 4:09โ€ฏPM Simon Glass wrote:\n>\n> Hi Rob,\n>\n> On Fri, 13 Oct 2023 at 13:42, Rob Herring wrote:\n> >\n> > On Fri, Oct 6, 2023 at 7:03โ€ฏPM Simon Glass wrote:\n> > >\n> > > Hi Ard,\n> > >\n> > > On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel wrote:\n> > > >\n> > > > On Fri, 6 Oct 2023 at 20:17, Simon Glass wrote:\n> > > > >\n> > > > > Hi Ard,\n> > > > >\n> > > > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel wrote:\n> > > > > >\n> > > > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:\n> > > > > > >\n> > > > > > > Hi Rob,\n> > > > > > >\n> > > > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:\n> > > > > > > >\n> > > > > > > > It is common to split firmware into 'Platform Init', which does the\n> > > > > > > > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > > > > > > > Thus an handover interface is required between these two pieces.\n> > > > > > > >\n> > > > > > > > Where UEFI boot-time services are not available, but UEFI firmware is\n> > > > > > > > present on either side of this interface, information about memory usage\n> > > > > > > > and attributes must be presented to the \"Payload\" in some form.\n> > > > > > > >\n> > > > > > > > This aims to provide an small schema addition for the memory mapping\n> > > > > > > > needed to keep these two pieces working together well.\n> > > > > > > >\n> > > > > > > > Signed-off-by: Simon Glass \n> > > > > > > > ---\n> > > > > > > >\n> > > > > > > > Changes in v7:\n> > > > > > > > - Rename acpi-reclaim to acpi\n> > > > > > > > - Drop individual mention of when memory can be reclaimed\n> > > > > > > > - Rewrite the item descriptions\n> > > > > > > > - Add back the UEFI text (with trepidation)\n> > > > > > >\n> > > > > > > I am again checking on this series. Can it be applied, please?\n> > > > > > >\n> > > > > >\n> > > > > > Apologies for the delay in response. I have been away.\n> > > > >\n> > > > > OK, I hope you had a nice trip.\n> > > > >\n> > > >\n> > > > Thanks, it was wonderful!\n> > > >\n> > > > > >\n> > > > > > >\n> > > > > > > >\n> > > > > > > > Changes in v6:\n> > > > > > > > - Drop mention of UEFI\n> > > > > > > > - Use compatible strings instead of node names\n> > > > > > > >\n> > > > > > > > Changes in v5:\n> > > > > > > > - Drop the memory-map node (should have done that in v4)\n> > > > > > > > - Tidy up schema a bit\n> > > > > > > >\n> > > > > > > > Changes in v4:\n> > > > > > > > - Make use of the reserved-memory node instead of creating a new one\n> > > > > > > >\n> > > > > > > > Changes in v3:\n> > > > > > > > - Reword commit message again\n> > > > > > > > - cc a lot more people, from the FFI patch\n> > > > > > > > - Split out the attributes into the /memory nodes\n> > > > > > > >\n> > > > > > > > Changes in v2:\n> > > > > > > > - Reword commit message\n> > > > > > > >\n> > > > > > > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > > > > > > > 1 file changed, 71 insertions(+)\n> > > > > > > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > >\n> > > > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > > new file mode 100644\n> > > > > > > > index 0000000..f7fbdfd\n> > > > > > > > --- /dev/null\n> > > > > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > > @@ -0,0 +1,71 @@\n> > > > > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause\n> > > > > > > > +%YAML 1.2\n> > > > > > > > +---\n> > > > > > > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > > > > > > > +\n> > > > > > > > +title: Common memory reservations\n> > > > > > > > +\n> > > > > > > > +description: |\n> > > > > > > > + Specifies that the reserved memory region can be used for the purpose\n> > > > > > > > + indicated by its compatible string.\n> > > > > > > > +\n> > > > > > > > + Clients may reuse this reserved memory if they understand what it is for,\n> > > > > > > > + subject to the notes below.\n> > > > > > > > +\n> > > > > > > > +maintainers:\n> > > > > > > > + - Simon Glass \n> > > > > > > > +\n> > > > > > > > +allOf:\n> > > > > > > > + - $ref: reserved-memory.yaml\n> > > > > > > > +\n> > > > > > > > +properties:\n> > > > > > > > + compatible:\n> > > > > > > > + description: |\n> > > > > > > > + This describes some common memory reservations, with the compatible\n> > > > > > > > + string indicating what it is used for:\n> > > > > > > > +\n> > > > > > > > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > > > > > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > > > > > > > + the firmware for its use and is required to be saved and restored\n> > > > > > > > + across an NVS sleep\n> > > > > > > > + boot-code: Contains code used for booting which is not needed by the OS\n> > > > > > > > + boot-code: Contains data used for booting which is not needed by the OS\n> > > > > > > > + runtime-code: Contains code used for interacting with the system when\n> > > > > > > > + running the OS\n> > > > > > > > + runtime-data: Contains data used for interacting with the system when\n> > > > > > > > + running the OS\n> > > > > > > > +\n> > > > > > > > + enum:\n> > > > > > > > + - acpi\n> > > > > > > > + - acpi-nvs\n> > > > > > > > + - boot-code\n> > > > > > > > + - boot-data\n> > > > > > > > + - runtime-code\n> > > > > > > > + - runtime-data\n> > > > > > > > +\n> > > > > >\n> > > > > > As I mentioned a few times already, I don't think these compatibles\n> > > > > > should be introduced here.\n> > > > > >\n> > > > > > A reserved region has a specific purpose, and the compatible should be\n> > > > > > more descriptive than the enum above. If the consumer does not\n> > > > > > understand this purpose, it should simply treat the memory as reserved\n> > > > > > and not touch it. Alternatively, these regions can be referenced from\n> > > > > > other DT nodes using phandles if needed.\n> > > > >\n> > > > > We still need some description of what these regions are used for, so\n> > > > > that the payload can use the correct regions. I do not have any other\n> > > > > solution to this problem. We are in v7 at present. At least explain\n> > > > > where you want the compatible strings to be introduced.\n> > > > >\n> > > >\n> > > > My point is really that by themselves, these regions are not usable by\n> > > > either a payload or an OS that consumes this information. Unless there\n> > > > is some other information being provided (via DT I imagine) that\n> > > > describes how these things are supposed to be used, they are nothing\n> > > > more than memory reservations that should be honored, and providing\n> > > > this arbitrary set of labels is unnecessary.\n> > > >\n> > > > > What sort of extra detail are you looking for? Please be specific and\n> > > > > preferably add some suggestions so I can close this out ASAP.\n> > > > >\n> > > >\n> > > > A payload or OS can do nothing with a memory reservation called\n> > > > 'runtime-code' it it doesn't know what is inside.\n> >\n> > Agreed. The question is WHAT runtime-code? The compatible needs to answer that.\n> >\n> > For example, we have 'ramoops' as a compatible in reserved memory.\n> > That tells us *exactly* what's there. We know how to parse it. If we\n> > know ramoops is not supported, then we know we can toss it out and\n> > reclaim the memory.\n>\n> So if we said:\n>\n> compatible = \"runtime-code-efi\"\n>\n> would that be OK? We seem to be in catch 22 here, because if I don't\n> mention EFI unhappy, but if I do, Ard is unhappy.\n\nBetter yes, because then it is for something specific. However, AIUI,\nthat's setup for the OS and defining that region is already defined by\nthe EFI memory map. That's Ard's issue. If there's a need outside of\nthe EFI to OS handoff, then you need to define what that usecase looks\nlike. Describe the problem rather than present your solution.\n\nIf this is all specific to EDK2 then it should say that rather than\n'efi'. I imagine Ard would be happier with something tied to EDK2 than\n*all* UEFI. Though maybe the problem could be any implementation? IDK.\nMaybe it's TF-A that needs to define where the EFI runtime services\nregion is and that needs to be passed all the way thru to the EFI\nimplementation? So again, define the problem.\n\n> What about the boottime code....you want to know which project it is from?\n\nI think it is the same.\n\n>\n> + - acpi\n> + - acpi-nvs\n>\n> Those two should be enough info, right?\n\nI think so. NVS is not a term I've heard in relation to ACPI, but that\nmay just be my limited ACPI knowledge.\n\n> + - boot-code\n> + - boot-data\n>\n> For these, they don't pertain to the OS, so perhaps they are OK?\n\nHard to tell that just from the name... 'boot' could be any component\ninvolved in booting including the OS.\n\n> In\n> any case, using a generic term like this makes some sense to me. We\n> can always add a new compatible like \"efi-boottime-services\" later. It\n> may be that the boottime services would be handled by the payload, so\n> not needed in all cases.\n\nWhy later? You have a specific use in mind and I imagine Ard has\nthoughts on that.\n\nRob","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=kdctiWPs;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=85.214.62.61; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.b=\"kdctiWPs\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de; spf=pass smtp.mailfrom=robh@kernel.org"],"Received":["from phobos.denx.de (phobos.denx.de [85.214.62.61])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4S8NQT1m6mz1ypX\n\tfor ; Tue, 17 Oct 2023 03:50:25 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 229F286335;\n\tMon, 16 Oct 2023 18:50:23 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id F39C6869EB; Mon, 16 Oct 2023 18:50:19 +0200 (CEST)","from ams.source.kernel.org (ams.source.kernel.org\n [IPv6:2604:1380:4601:e00::1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 9676F86335\n for ; Mon, 16 Oct 2023 18:50:17 +0200 (CEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by ams.source.kernel.org (Postfix) with ESMTP id 0453DB817DC\n for ; Mon, 16 Oct 2023 16:50:17 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 72F84C433CC\n for ; Mon, 16 Oct 2023 16:50:15 +0000 (UTC)","by mail-lf1-f48.google.com with SMTP id\n 2adb3069b0e04-507b18cf2e1so1321522e87.3\n for ; Mon, 16 Oct 2023 09:50:15 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS autolearn=ham autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1697475015;\n bh=dAiKiJ+A2fpb0mLWyNJE2TtPMgp+in9hGPhvRQTEtuQ=;\n h=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n b=kdctiWPs2y7Lz+TZmeMB0DOIBMP61yBLXLVmyF87TTZnSDkxujpPENKah2VqvinD6\n IHPb3wO3hGQJvFWaEz2zkkPXkCJYeXR0rP11GUHfbB6+qbBvFHbtI3Be+VxrXfeyBm\n vyVq0erm2KaG+DSX9IZqhTQoS1zrFJTjxEe6WeZRxFF24WRAnwKVHN5W+YdI6r5IGO\n 26gDNo+khYpkLCLx9DYqTQlDSSHH2uSAMv+O/o/GXh4ndehLZOweaiS+Zln7gY368H\n UlvuHdK+68QG+JpeLRHu6y+nKMM8lf2SiprBMgChwCGOo1meI89KhTsC8wovuwvGuJ\n s1dtl6dJgsSbg==","X-Gm-Message-State":"AOJu0YzJm0ujJ54Ad6tE9PrU9DnvXmcZlBi8Taos7sO3AgAQlrRLwSaq\n OO5uba9GSOobSopVJiYDt1ZjTizBpfjcQ9H7OQ==","X-Google-Smtp-Source":"\n AGHT+IGM6ATskDC+wE0Jj52XLiSQ5V+QcPN2ssobzitpeqE5zVNrtXglWBLAi3+Qzk+UorHEFgyOGPTrV+s2OD8+mn8=","X-Received":"by 2002:ac2:53a8:0:b0:507:a650:991d with SMTP id\n j8-20020ac253a8000000b00507a650991dmr5207518lfh.58.1697475013438; Mon, 16 Oct\n 2023 09:50:13 -0700 (PDT)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Rob Herring ","Date":"Mon, 16 Oct 2023 11:50:00 -0500","X-Gmail-Original-Message-ID":"\n ","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Simon Glass ","Cc":"Ard Biesheuvel , devicetree@vger.kernel.org,\n Mark Rutland ,\n Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3200322,"web_url":"http://patchwork.ozlabs.org/comment/3200322/","msgid":"","list_archive_url":null,"date":"2023-10-16T21:54:56","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":6170,"url":"http://patchwork.ozlabs.org/api/people/6170/","name":"Simon Glass","email":"sjg@chromium.org"},"content":"Hi Rob,\n\nOn Mon, 16 Oct 2023 at 10:50, Rob Herring wrote:\n>\n> On Fri, Oct 13, 2023 at 4:09โ€ฏPM Simon Glass wrote:\n> >\n> > Hi Rob,\n> >\n> > On Fri, 13 Oct 2023 at 13:42, Rob Herring wrote:\n> > >\n> > > On Fri, Oct 6, 2023 at 7:03โ€ฏPM Simon Glass wrote:\n> > > >\n> > > > Hi Ard,\n> > > >\n> > > > On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel wrote:\n> > > > >\n> > > > > On Fri, 6 Oct 2023 at 20:17, Simon Glass wrote:\n> > > > > >\n> > > > > > Hi Ard,\n> > > > > >\n> > > > > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel wrote:\n> > > > > > >\n> > > > > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:\n> > > > > > > >\n> > > > > > > > Hi Rob,\n> > > > > > > >\n> > > > > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:\n> > > > > > > > >\n> > > > > > > > > It is common to split firmware into 'Platform Init', which does the\n> > > > > > > > > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > > > > > > > > Thus an handover interface is required between these two pieces.\n> > > > > > > > >\n> > > > > > > > > Where UEFI boot-time services are not available, but UEFI firmware is\n> > > > > > > > > present on either side of this interface, information about memory usage\n> > > > > > > > > and attributes must be presented to the \"Payload\" in some form.\n> > > > > > > > >\n> > > > > > > > > This aims to provide an small schema addition for the memory mapping\n> > > > > > > > > needed to keep these two pieces working together well.\n> > > > > > > > >\n> > > > > > > > > Signed-off-by: Simon Glass \n> > > > > > > > > ---\n> > > > > > > > >\n> > > > > > > > > Changes in v7:\n> > > > > > > > > - Rename acpi-reclaim to acpi\n> > > > > > > > > - Drop individual mention of when memory can be reclaimed\n> > > > > > > > > - Rewrite the item descriptions\n> > > > > > > > > - Add back the UEFI text (with trepidation)\n> > > > > > > >\n> > > > > > > > I am again checking on this series. Can it be applied, please?\n> > > > > > > >\n> > > > > > >\n> > > > > > > Apologies for the delay in response. I have been away.\n> > > > > >\n> > > > > > OK, I hope you had a nice trip.\n> > > > > >\n> > > > >\n> > > > > Thanks, it was wonderful!\n> > > > >\n> > > > > > >\n> > > > > > > >\n> > > > > > > > >\n> > > > > > > > > Changes in v6:\n> > > > > > > > > - Drop mention of UEFI\n> > > > > > > > > - Use compatible strings instead of node names\n> > > > > > > > >\n> > > > > > > > > Changes in v5:\n> > > > > > > > > - Drop the memory-map node (should have done that in v4)\n> > > > > > > > > - Tidy up schema a bit\n> > > > > > > > >\n> > > > > > > > > Changes in v4:\n> > > > > > > > > - Make use of the reserved-memory node instead of creating a new one\n> > > > > > > > >\n> > > > > > > > > Changes in v3:\n> > > > > > > > > - Reword commit message again\n> > > > > > > > > - cc a lot more people, from the FFI patch\n> > > > > > > > > - Split out the attributes into the /memory nodes\n> > > > > > > > >\n> > > > > > > > > Changes in v2:\n> > > > > > > > > - Reword commit message\n> > > > > > > > >\n> > > > > > > > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > > > > > > > > 1 file changed, 71 insertions(+)\n> > > > > > > > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > > >\n> > > > > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > > > new file mode 100644\n> > > > > > > > > index 0000000..f7fbdfd\n> > > > > > > > > --- /dev/null\n> > > > > > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > > > @@ -0,0 +1,71 @@\n> > > > > > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause\n> > > > > > > > > +%YAML 1.2\n> > > > > > > > > +---\n> > > > > > > > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > > > > > > > > +\n> > > > > > > > > +title: Common memory reservations\n> > > > > > > > > +\n> > > > > > > > > +description: |\n> > > > > > > > > + Specifies that the reserved memory region can be used for the purpose\n> > > > > > > > > + indicated by its compatible string.\n> > > > > > > > > +\n> > > > > > > > > + Clients may reuse this reserved memory if they understand what it is for,\n> > > > > > > > > + subject to the notes below.\n> > > > > > > > > +\n> > > > > > > > > +maintainers:\n> > > > > > > > > + - Simon Glass \n> > > > > > > > > +\n> > > > > > > > > +allOf:\n> > > > > > > > > + - $ref: reserved-memory.yaml\n> > > > > > > > > +\n> > > > > > > > > +properties:\n> > > > > > > > > + compatible:\n> > > > > > > > > + description: |\n> > > > > > > > > + This describes some common memory reservations, with the compatible\n> > > > > > > > > + string indicating what it is used for:\n> > > > > > > > > +\n> > > > > > > > > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > > > > > > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > > > > > > > > + the firmware for its use and is required to be saved and restored\n> > > > > > > > > + across an NVS sleep\n> > > > > > > > > + boot-code: Contains code used for booting which is not needed by the OS\n> > > > > > > > > + boot-code: Contains data used for booting which is not needed by the OS\n> > > > > > > > > + runtime-code: Contains code used for interacting with the system when\n> > > > > > > > > + running the OS\n> > > > > > > > > + runtime-data: Contains data used for interacting with the system when\n> > > > > > > > > + running the OS\n> > > > > > > > > +\n> > > > > > > > > + enum:\n> > > > > > > > > + - acpi\n> > > > > > > > > + - acpi-nvs\n> > > > > > > > > + - boot-code\n> > > > > > > > > + - boot-data\n> > > > > > > > > + - runtime-code\n> > > > > > > > > + - runtime-data\n> > > > > > > > > +\n> > > > > > >\n> > > > > > > As I mentioned a few times already, I don't think these compatibles\n> > > > > > > should be introduced here.\n> > > > > > >\n> > > > > > > A reserved region has a specific purpose, and the compatible should be\n> > > > > > > more descriptive than the enum above. If the consumer does not\n> > > > > > > understand this purpose, it should simply treat the memory as reserved\n> > > > > > > and not touch it. Alternatively, these regions can be referenced from\n> > > > > > > other DT nodes using phandles if needed.\n> > > > > >\n> > > > > > We still need some description of what these regions are used for, so\n> > > > > > that the payload can use the correct regions. I do not have any other\n> > > > > > solution to this problem. We are in v7 at present. At least explain\n> > > > > > where you want the compatible strings to be introduced.\n> > > > > >\n> > > > >\n> > > > > My point is really that by themselves, these regions are not usable by\n> > > > > either a payload or an OS that consumes this information. Unless there\n> > > > > is some other information being provided (via DT I imagine) that\n> > > > > describes how these things are supposed to be used, they are nothing\n> > > > > more than memory reservations that should be honored, and providing\n> > > > > this arbitrary set of labels is unnecessary.\n> > > > >\n> > > > > > What sort of extra detail are you looking for? Please be specific and\n> > > > > > preferably add some suggestions so I can close this out ASAP.\n> > > > > >\n> > > > >\n> > > > > A payload or OS can do nothing with a memory reservation called\n> > > > > 'runtime-code' it it doesn't know what is inside.\n> > >\n> > > Agreed. The question is WHAT runtime-code? The compatible needs to answer that.\n> > >\n> > > For example, we have 'ramoops' as a compatible in reserved memory.\n> > > That tells us *exactly* what's there. We know how to parse it. If we\n> > > know ramoops is not supported, then we know we can toss it out and\n> > > reclaim the memory.\n> >\n> > So if we said:\n> >\n> > compatible = \"runtime-code-efi\"\n> >\n> > would that be OK? We seem to be in catch 22 here, because if I don't\n> > mention EFI unhappy, but if I do, Ard is unhappy.\n>\n> Better yes, because then it is for something specific. However, AIUI,\n> that's setup for the OS and defining that region is already defined by\n> the EFI memory map. That's Ard's issue. If there's a need outside of\n> the EFI to OS handoff,\n\nThere is a need. Here is part of the commit message again. If there is\nsomething else you need to know, please ask.\n\n>>>>\nIt is common to split firmware into 'Platform Init', which does the\ninitial hardware setup and a \"Payload\" which selects the OS to be booted.\nThus an handover interface is required between these two pieces.\n\nWhere UEFI boot-time services are not available, but UEFI firmware is\npresent on either side of this interface, information about memory usage\nand attributes must be presented to the \"Payload\" in some form.\n<<<\n\n> then you need to define what that usecase looks\n> like. Describe the problem rather than present your solution.\n>\n> If this is all specific to EDK2 then it should say that rather than\n> 'efi'. I imagine Ard would be happier with something tied to EDK2 than\n> *all* UEFI. Though maybe the problem could be any implementation? IDK.\n> Maybe it's TF-A that needs to define where the EFI runtime services\n> region is and that needs to be passed all the way thru to the EFI\n> implementation? So again, define the problem.\n\nIt is not specific to EDK2. Imagine this boot sequence:\n\n- Platform Init (U-Boot) starts up\n- U-Boot uses its platform knowledge to sets some ACPI tables and put\nvarious things in memory\n- U-Boot sets up some runtime code and data for the OS\n- U-Boot jumps to the Tianocore payload **\n- Payload (Tianocore) wants to know where the ACPI tables are, for example\n- Tianocore needs to provide boot services to the OS, so needs to know\nthe memory map, etc.\n\n** At this point we want to use DT to pass the required information.\n\nOf course, Platform Init could be coreboot or Tianocore or some\nstrange private binary. Payload could be U-Boot or something else.\nThat is the point of this effort, to build interoperability.\n\n>\n> > What about the boottime code....you want to know which project it is from?\n>\n> I think it is the same.\n>\n> >\n> > + - acpi\n> > + - acpi-nvs\n> >\n> > Those two should be enough info, right?\n>\n> I think so. NVS is not a term I've heard in relation to ACPI, but that\n> may just be my limited ACPI knowledge.\n\nPerhaps it is only an Intel thing. It stands for Non-Volatile-Sleeping\nMemory and it has various platform settings in a binary format that is\nnormally SoC-specific.\n\n>\n> > + - boot-code\n> > + - boot-data\n> >\n> > For these, they don't pertain to the OS, so perhaps they are OK?\n>\n> Hard to tell that just from the name... 'boot' could be any component\n> involved in booting including the OS.\n\n suggested that 'boot' should mean booting the OS. If the OS does lots\nof fixup stuff at the start of it, I don't know what that is called.\n\nSo if boot-code is no good, what do you suggest?\n\nAlternatively I could remove these for now, if it will help make progress.\n\n>\n> > In\n> > any case, using a generic term like this makes some sense to me. We\n> > can always add a new compatible like \"efi-boottime-services\" later. It\n> > may be that the boottime services would be handled by the payload, so\n> > not needed in all cases.\n>\n> Why later? You have a specific use in mind and I imagine Ard has\n> thoughts on that.\n\nBecause we don't need it right away, and just want to make some progress.\n\nPerhaps the problem here is that Linux has tied itself up in knots\nwith its EFI stuff and DT fixups and what-not. But this is not that.\nIt is a simple handoff between two pieces of firmware, Platform Init\nand Payload. It has nothing to do with the OS. With Tianocore they are\ntypically combined, but with this usage they are split, and we can\nswap out one project for another on either side of the DT interface.\n\nI do have views on the 'EFI' opt-out with reserved-memory, if you are\ninterested, but that relates to the OS. If you are wanting to place\nsome constraints on /reserved-memory and /memory we could do that\ne.g. that the DT and the map returned by EFI boot services must be\nconsistent. But as it is, the nodes are ignored by the OS when booting\nwith EFI, aren't they?\n\nRegards,\nSimon","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256\n header.s=google header.b=nDjJnnZH;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org\n header.b=\"nDjJnnZH\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4S8WD257jNz20Zj\n\tfor ; Tue, 17 Oct 2023 08:56:50 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id C41B786ECF;\n\tMon, 16 Oct 2023 23:55:47 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id 113E586E7C; Mon, 16 Oct 2023 23:55:20 +0200 (CEST)","from mail-lj1-x232.google.com (mail-lj1-x232.google.com\n [IPv6:2a00:1450:4864:20::232])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id B994C868C0\n for ; Mon, 16 Oct 2023 23:55:14 +0200 (CEST)","by mail-lj1-x232.google.com with SMTP id\n 38308e7fff4ca-2b95d5ee18dso67538271fa.1\n for ; Mon, 16 Oct 2023 14:55:14 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-9.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,\n SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=no\n autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=chromium.org; s=google; t=1697493313; x=1698098113; darn=lists.denx.de;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=tc/P1acb3I8J14trQrv7akNjvswnVV/SQ5E3mgTEuIc=;\n b=nDjJnnZHmJ6xGQCPqiI0V94O9KGTbAziGUDIfalbm1QDMIQ3X6Q7HVpzGMUVV1gxav\n 0DYQod5/pWD7WRY4pPhmLohHjMwXP8hEjt4Gn/CiMUnExgTJ/aJzheHsHjAnb2ZdKh2f\n P8eVE5n8Zc1meby0VgrpqN2XcWwFGX6uqCfy4=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1697493313; x=1698098113;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc\n :subject:date:message-id:reply-to;\n bh=tc/P1acb3I8J14trQrv7akNjvswnVV/SQ5E3mgTEuIc=;\n b=OWbnnhSX+DF//jFmZD2FBDUx62XMiUAxV9JMIPH5lQP0f/0wmGt0cKlwFDLBET55CN\n lpbmSU2zBDMYh7a/K6VT3JizW6ORoBF2nYdTnpdzdbJM/sBu5Ea2lPX+cb02jYrPUTgZ\n Z8m7XfvRgd+2oXbYgXAHYXfW+YpkCZHMKJkd2neW88GCLGPrp7nRirIs90yDtpLx/8ME\n c8uJjsko6X16a2sy25GJSqPDSmdBHIwoMNZhy9BXH4iBG6BRI7zbMcP9UxsLlqccWIrJ\n mV8K80ql/Sq6KSAL+5wqB6DABky4zdqaHacCpiXoWLOZKrD0vXQrQ8E45REtNE2VO4AL\n pbKg==","X-Gm-Message-State":"AOJu0Yz1b5rCugEKwVnQ3CQD0VoVVpk+Kl8KzKKGjYLTu33q0VNjSc43\n w3CTE7y8kSNFJXij8Th+lBXK90Ed0zWuFSysxxSIkA==","X-Google-Smtp-Source":"\n AGHT+IGrwZMQ9sUCx6I8enf1J/AgIX1ksUJw2fuS+bwo/E/oF7a8RXAkSkVW1F5psnfn+q/MivI7/AjfDzYKvoyBFnk=","X-Received":"by 2002:a2e:b0ed:0:b0:2b9:ecab:d924 with SMTP id\n h13-20020a2eb0ed000000b002b9ecabd924mr334866ljl.18.1697493312677; Mon, 16 Oct\n 2023 14:55:12 -0700 (PDT)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Simon Glass ","Date":"Mon, 16 Oct 2023 15:54:56 -0600","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Rob Herring ","Cc":"Ard Biesheuvel , devicetree@vger.kernel.org,\n Mark Rutland ,\n Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3209530,"web_url":"http://patchwork.ozlabs.org/comment/3209530/","msgid":"","list_archive_url":null,"date":"2023-10-31T15:56:08","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":6170,"url":"http://patchwork.ozlabs.org/api/people/6170/","name":"Simon Glass","email":"sjg@chromium.org"},"content":"Hi Rob,\n\nOn Mon, 16 Oct 2023 at 15:54, Simon Glass wrote:\n>\n> Hi Rob,\n>\n> On Mon, 16 Oct 2023 at 10:50, Rob Herring wrote:\n> >\n> > On Fri, Oct 13, 2023 at 4:09โ€ฏPM Simon Glass wrote:\n> > >\n> > > Hi Rob,\n> > >\n> > > On Fri, 13 Oct 2023 at 13:42, Rob Herring wrote:\n> > > >\n> > > > On Fri, Oct 6, 2023 at 7:03โ€ฏPM Simon Glass wrote:\n> > > > >\n> > > > > Hi Ard,\n> > > > >\n> > > > > On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel wrote:\n> > > > > >\n> > > > > > On Fri, 6 Oct 2023 at 20:17, Simon Glass wrote:\n> > > > > > >\n> > > > > > > Hi Ard,\n> > > > > > >\n> > > > > > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel wrote:\n> > > > > > > >\n> > > > > > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:\n> > > > > > > > >\n> > > > > > > > > Hi Rob,\n> > > > > > > > >\n> > > > > > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:\n> > > > > > > > > >\n> > > > > > > > > > It is common to split firmware into 'Platform Init', which does the\n> > > > > > > > > > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > > > > > > > > > Thus an handover interface is required between these two pieces.\n> > > > > > > > > >\n> > > > > > > > > > Where UEFI boot-time services are not available, but UEFI firmware is\n> > > > > > > > > > present on either side of this interface, information about memory usage\n> > > > > > > > > > and attributes must be presented to the \"Payload\" in some form.\n> > > > > > > > > >\n> > > > > > > > > > This aims to provide an small schema addition for the memory mapping\n> > > > > > > > > > needed to keep these two pieces working together well.\n> > > > > > > > > >\n> > > > > > > > > > Signed-off-by: Simon Glass \n> > > > > > > > > > ---\n> > > > > > > > > >\n> > > > > > > > > > Changes in v7:\n> > > > > > > > > > - Rename acpi-reclaim to acpi\n> > > > > > > > > > - Drop individual mention of when memory can be reclaimed\n> > > > > > > > > > - Rewrite the item descriptions\n> > > > > > > > > > - Add back the UEFI text (with trepidation)\n> > > > > > > > >\n> > > > > > > > > I am again checking on this series. Can it be applied, please?\n> > > > > > > > >\n> > > > > > > >\n> > > > > > > > Apologies for the delay in response. I have been away.\n> > > > > > >\n> > > > > > > OK, I hope you had a nice trip.\n> > > > > > >\n> > > > > >\n> > > > > > Thanks, it was wonderful!\n> > > > > >\n> > > > > > > >\n> > > > > > > > >\n> > > > > > > > > >\n> > > > > > > > > > Changes in v6:\n> > > > > > > > > > - Drop mention of UEFI\n> > > > > > > > > > - Use compatible strings instead of node names\n> > > > > > > > > >\n> > > > > > > > > > Changes in v5:\n> > > > > > > > > > - Drop the memory-map node (should have done that in v4)\n> > > > > > > > > > - Tidy up schema a bit\n> > > > > > > > > >\n> > > > > > > > > > Changes in v4:\n> > > > > > > > > > - Make use of the reserved-memory node instead of creating a new one\n> > > > > > > > > >\n> > > > > > > > > > Changes in v3:\n> > > > > > > > > > - Reword commit message again\n> > > > > > > > > > - cc a lot more people, from the FFI patch\n> > > > > > > > > > - Split out the attributes into the /memory nodes\n> > > > > > > > > >\n> > > > > > > > > > Changes in v2:\n> > > > > > > > > > - Reword commit message\n> > > > > > > > > >\n> > > > > > > > > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > > > > > > > > > 1 file changed, 71 insertions(+)\n> > > > > > > > > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > > > >\n> > > > > > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > > > > new file mode 100644\n> > > > > > > > > > index 0000000..f7fbdfd\n> > > > > > > > > > --- /dev/null\n> > > > > > > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > > > > @@ -0,0 +1,71 @@\n> > > > > > > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause\n> > > > > > > > > > +%YAML 1.2\n> > > > > > > > > > +---\n> > > > > > > > > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > > > > > > > > > +\n> > > > > > > > > > +title: Common memory reservations\n> > > > > > > > > > +\n> > > > > > > > > > +description: |\n> > > > > > > > > > + Specifies that the reserved memory region can be used for the purpose\n> > > > > > > > > > + indicated by its compatible string.\n> > > > > > > > > > +\n> > > > > > > > > > + Clients may reuse this reserved memory if they understand what it is for,\n> > > > > > > > > > + subject to the notes below.\n> > > > > > > > > > +\n> > > > > > > > > > +maintainers:\n> > > > > > > > > > + - Simon Glass \n> > > > > > > > > > +\n> > > > > > > > > > +allOf:\n> > > > > > > > > > + - $ref: reserved-memory.yaml\n> > > > > > > > > > +\n> > > > > > > > > > +properties:\n> > > > > > > > > > + compatible:\n> > > > > > > > > > + description: |\n> > > > > > > > > > + This describes some common memory reservations, with the compatible\n> > > > > > > > > > + string indicating what it is used for:\n> > > > > > > > > > +\n> > > > > > > > > > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > > > > > > > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > > > > > > > > > + the firmware for its use and is required to be saved and restored\n> > > > > > > > > > + across an NVS sleep\n> > > > > > > > > > + boot-code: Contains code used for booting which is not needed by the OS\n> > > > > > > > > > + boot-code: Contains data used for booting which is not needed by the OS\n> > > > > > > > > > + runtime-code: Contains code used for interacting with the system when\n> > > > > > > > > > + running the OS\n> > > > > > > > > > + runtime-data: Contains data used for interacting with the system when\n> > > > > > > > > > + running the OS\n> > > > > > > > > > +\n> > > > > > > > > > + enum:\n> > > > > > > > > > + - acpi\n> > > > > > > > > > + - acpi-nvs\n> > > > > > > > > > + - boot-code\n> > > > > > > > > > + - boot-data\n> > > > > > > > > > + - runtime-code\n> > > > > > > > > > + - runtime-data\n> > > > > > > > > > +\n> > > > > > > >\n> > > > > > > > As I mentioned a few times already, I don't think these compatibles\n> > > > > > > > should be introduced here.\n> > > > > > > >\n> > > > > > > > A reserved region has a specific purpose, and the compatible should be\n> > > > > > > > more descriptive than the enum above. If the consumer does not\n> > > > > > > > understand this purpose, it should simply treat the memory as reserved\n> > > > > > > > and not touch it. Alternatively, these regions can be referenced from\n> > > > > > > > other DT nodes using phandles if needed.\n> > > > > > >\n> > > > > > > We still need some description of what these regions are used for, so\n> > > > > > > that the payload can use the correct regions. I do not have any other\n> > > > > > > solution to this problem. We are in v7 at present. At least explain\n> > > > > > > where you want the compatible strings to be introduced.\n> > > > > > >\n> > > > > >\n> > > > > > My point is really that by themselves, these regions are not usable by\n> > > > > > either a payload or an OS that consumes this information. Unless there\n> > > > > > is some other information being provided (via DT I imagine) that\n> > > > > > describes how these things are supposed to be used, they are nothing\n> > > > > > more than memory reservations that should be honored, and providing\n> > > > > > this arbitrary set of labels is unnecessary.\n> > > > > >\n> > > > > > > What sort of extra detail are you looking for? Please be specific and\n> > > > > > > preferably add some suggestions so I can close this out ASAP.\n> > > > > > >\n> > > > > >\n> > > > > > A payload or OS can do nothing with a memory reservation called\n> > > > > > 'runtime-code' it it doesn't know what is inside.\n> > > >\n> > > > Agreed. The question is WHAT runtime-code? The compatible needs to answer that.\n> > > >\n> > > > For example, we have 'ramoops' as a compatible in reserved memory.\n> > > > That tells us *exactly* what's there. We know how to parse it. If we\n> > > > know ramoops is not supported, then we know we can toss it out and\n> > > > reclaim the memory.\n> > >\n> > > So if we said:\n> > >\n> > > compatible = \"runtime-code-efi\"\n> > >\n> > > would that be OK? We seem to be in catch 22 here, because if I don't\n> > > mention EFI unhappy, but if I do, Ard is unhappy.\n> >\n> > Better yes, because then it is for something specific. However, AIUI,\n> > that's setup for the OS and defining that region is already defined by\n> > the EFI memory map. That's Ard's issue. If there's a need outside of\n> > the EFI to OS handoff,\n>\n> There is a need. Here is part of the commit message again. If there is\n> something else you need to know, please ask.\n>\n> >>>>\n> It is common to split firmware into 'Platform Init', which does the\n> initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> Thus an handover interface is required between these two pieces.\n>\n> Where UEFI boot-time services are not available, but UEFI firmware is\n> present on either side of this interface, information about memory usage\n> and attributes must be presented to the \"Payload\" in some form.\n> <<<\n>\n> > then you need to define what that usecase looks\n> > like. Describe the problem rather than present your solution.\n> >\n> > If this is all specific to EDK2 then it should say that rather than\n> > 'efi'. I imagine Ard would be happier with something tied to EDK2 than\n> > *all* UEFI. Though maybe the problem could be any implementation? IDK.\n> > Maybe it's TF-A that needs to define where the EFI runtime services\n> > region is and that needs to be passed all the way thru to the EFI\n> > implementation? So again, define the problem.\n>\n> It is not specific to EDK2. Imagine this boot sequence:\n>\n> - Platform Init (U-Boot) starts up\n> - U-Boot uses its platform knowledge to sets some ACPI tables and put\n> various things in memory\n> - U-Boot sets up some runtime code and data for the OS\n> - U-Boot jumps to the Tianocore payload **\n> - Payload (Tianocore) wants to know where the ACPI tables are, for example\n> - Tianocore needs to provide boot services to the OS, so needs to know\n> the memory map, etc.\n>\n> ** At this point we want to use DT to pass the required information.\n>\n> Of course, Platform Init could be coreboot or Tianocore or some\n> strange private binary. Payload could be U-Boot or something else.\n> That is the point of this effort, to build interoperability.\n>\n> >\n> > > What about the boottime code....you want to know which project it is from?\n> >\n> > I think it is the same.\n> >\n> > >\n> > > + - acpi\n> > > + - acpi-nvs\n> > >\n> > > Those two should be enough info, right?\n> >\n> > I think so. NVS is not a term I've heard in relation to ACPI, but that\n> > may just be my limited ACPI knowledge.\n>\n> Perhaps it is only an Intel thing. It stands for Non-Volatile-Sleeping\n> Memory and it has various platform settings in a binary format that is\n> normally SoC-specific.\n>\n> >\n> > > + - boot-code\n> > > + - boot-data\n> > >\n> > > For these, they don't pertain to the OS, so perhaps they are OK?\n> >\n> > Hard to tell that just from the name... 'boot' could be any component\n> > involved in booting including the OS.\n>\n> suggested that 'boot' should mean booting the OS. If the OS does lots\n> of fixup stuff at the start of it, I don't know what that is called.\n>\n> So if boot-code is no good, what do you suggest?\n>\n> Alternatively I could remove these for now, if it will help make progress.\n>\n> >\n> > > In\n> > > any case, using a generic term like this makes some sense to me. We\n> > > can always add a new compatible like \"efi-boottime-services\" later. It\n> > > may be that the boottime services would be handled by the payload, so\n> > > not needed in all cases.\n> >\n> > Why later? You have a specific use in mind and I imagine Ard has\n> > thoughts on that.\n>\n> Because we don't need it right away, and just want to make some progress.\n>\n> Perhaps the problem here is that Linux has tied itself up in knots\n> with its EFI stuff and DT fixups and what-not. But this is not that.\n> It is a simple handoff between two pieces of firmware, Platform Init\n> and Payload. It has nothing to do with the OS. With Tianocore they are\n> typically combined, but with this usage they are split, and we can\n> swap out one project for another on either side of the DT interface.\n>\n> I do have views on the 'EFI' opt-out with reserved-memory, if you are\n> interested, but that relates to the OS. If you are wanting to place\n> some constraints on /reserved-memory and /memory we could do that\n> e.g. that the DT and the map returned by EFI boot services must be\n> consistent. But as it is, the nodes are ignored by the OS when booting\n> with EFI, aren't they?\n\nCan this be applied, please? If there are further comments, please let me know.\n\nRegards,\nSimon","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256\n header.s=google header.b=JET5itF7;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org\n header.b=\"JET5itF7\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SKZWW6ZsVz1yQ5\n\tfor ; Wed, 1 Nov 2023 02:56:37 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id BA51086FDA;\n\tTue, 31 Oct 2023 16:56:30 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id 2948F86FDA; Tue, 31 Oct 2023 16:56:29 +0100 (CET)","from mail-lf1-x135.google.com (mail-lf1-x135.google.com\n [IPv6:2a00:1450:4864:20::135])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 809008760F\n for ; Tue, 31 Oct 2023 16:56:26 +0100 (CET)","by mail-lf1-x135.google.com with SMTP id\n 2adb3069b0e04-50930f126b1so1417868e87.3\n for ; Tue, 31 Oct 2023 08:56:26 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-9.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,\n SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=ham\n autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=chromium.org; s=google; t=1698767786; x=1699372586; darn=lists.denx.de;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=aHMcOBdFYSE+8bQdxJLdLIEnklj/QhOLRUMvZvnsOnc=;\n b=JET5itF7jHtlbr6SxnpciykD9jWfgg80kmcjVQoqsmFKVW1PxIL2Qxk+8nvps8A6IQ\n cNX55nzPuPMwkfqKFn9yAdxzOPODj1EB+UCxNQXOEVMacXO6gS3vWNE+n3ufaGvzBfMt\n TduykqOlLzJ7xJRfkKwphQvUT1ow2bxWvYrMA=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1698767786; x=1699372586;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc\n :subject:date:message-id:reply-to;\n bh=aHMcOBdFYSE+8bQdxJLdLIEnklj/QhOLRUMvZvnsOnc=;\n b=cJ+TJSIu52dLYECXBS3Zb8gua4HKh1bJdy2h7wzIoYnIvcGqmF4sARIZGiUB2LGG8p\n 9a2vgG4ZpcZ5FIYikntno5QwCF5aaA9oLyzyjvUphTeORZ48KWTeuGwWYSKwo1hCx9eQ\n yf8q//SjzGNM9MPdZj3HliXaWpp/4iMXYuIWbQsAOOqk1SOkn+k2fgHAB8cyyONZnfN1\n JjxVpt6Ai6uYpQLKulecS+idR3eJTLqaF5KHOyOLgD3J26Vz6QaSWrY8v9HrlihJjZDR\n Hb7m9S++xWGSSErx3Ota1bCfr2jf/qyzrU3UbBFvNtOSKf9hKMuK2g9e4GqTS2nbkyS2\n 9qpA==","X-Gm-Message-State":"AOJu0YwES8sl2zaOljpz1M2B45GvgCrMccY01CeMts7fsBpqt/0lVi/g\n U0jgHNg6Q5VNXqYZ+8f+b1i2QZM/tmmRYVNoiaF67w==","X-Google-Smtp-Source":"\n AGHT+IGbUvvv2le05LQXmClEzIoa9JudCW13DGRbovqjMaWYeHnLbrMVVPg93bjaAWyIqR5/AodlwAvye0YUGv26j1M=","X-Received":"by 2002:a05:6512:3b87:b0:508:2b98:d6ce with SMTP id\n g7-20020a0565123b8700b005082b98d6cemr12268778lfv.45.1698767785185; Tue, 31\n Oct 2023 08:56:25 -0700 (PDT)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Simon Glass ","Date":"Tue, 31 Oct 2023 09:56:08 -0600","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Rob Herring ","Cc":"Ard Biesheuvel , devicetree@vger.kernel.org,\n Mark Rutland ,\n Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3213050,"web_url":"http://patchwork.ozlabs.org/comment/3213050/","msgid":"","list_archive_url":null,"date":"2023-11-07T16:57:35","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":6170,"url":"http://patchwork.ozlabs.org/api/people/6170/","name":"Simon Glass","email":"sjg@chromium.org"},"content":"Hi,\n\n\nOn Tue, 31 Oct 2023 at 09:56, Simon Glass wrote:\n>\n> Hi Rob,\n>\n> On Mon, 16 Oct 2023 at 15:54, Simon Glass wrote:\n> >\n> > Hi Rob,\n> >\n> > On Mon, 16 Oct 2023 at 10:50, Rob Herring wrote:\n> > >\n> > > On Fri, Oct 13, 2023 at 4:09โ€ฏPM Simon Glass wrote:\n> > > >\n> > > > Hi Rob,\n> > > >\n> > > > On Fri, 13 Oct 2023 at 13:42, Rob Herring wrote:\n> > > > >\n> > > > > On Fri, Oct 6, 2023 at 7:03โ€ฏPM Simon Glass wrote:\n> > > > > >\n> > > > > > Hi Ard,\n> > > > > >\n> > > > > > On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel wrote:\n> > > > > > >\n> > > > > > > On Fri, 6 Oct 2023 at 20:17, Simon Glass wrote:\n> > > > > > > >\n> > > > > > > > Hi Ard,\n> > > > > > > >\n> > > > > > > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel wrote:\n> > > > > > > > >\n> > > > > > > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:\n> > > > > > > > > >\n> > > > > > > > > > Hi Rob,\n> > > > > > > > > >\n> > > > > > > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:\n> > > > > > > > > > >\n> > > > > > > > > > > It is common to split firmware into 'Platform Init', which does the\n> > > > > > > > > > > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > > > > > > > > > > Thus an handover interface is required between these two pieces.\n> > > > > > > > > > >\n> > > > > > > > > > > Where UEFI boot-time services are not available, but UEFI firmware is\n> > > > > > > > > > > present on either side of this interface, information about memory usage\n> > > > > > > > > > > and attributes must be presented to the \"Payload\" in some form.\n> > > > > > > > > > >\n> > > > > > > > > > > This aims to provide an small schema addition for the memory mapping\n> > > > > > > > > > > needed to keep these two pieces working together well.\n> > > > > > > > > > >\n> > > > > > > > > > > Signed-off-by: Simon Glass \n> > > > > > > > > > > ---\n> > > > > > > > > > >\n> > > > > > > > > > > Changes in v7:\n> > > > > > > > > > > - Rename acpi-reclaim to acpi\n> > > > > > > > > > > - Drop individual mention of when memory can be reclaimed\n> > > > > > > > > > > - Rewrite the item descriptions\n> > > > > > > > > > > - Add back the UEFI text (with trepidation)\n> > > > > > > > > >\n> > > > > > > > > > I am again checking on this series. Can it be applied, please?\n> > > > > > > > > >\n> > > > > > > > >\n> > > > > > > > > Apologies for the delay in response. I have been away.\n> > > > > > > >\n> > > > > > > > OK, I hope you had a nice trip.\n> > > > > > > >\n> > > > > > >\n> > > > > > > Thanks, it was wonderful!\n> > > > > > >\n> > > > > > > > >\n> > > > > > > > > >\n> > > > > > > > > > >\n> > > > > > > > > > > Changes in v6:\n> > > > > > > > > > > - Drop mention of UEFI\n> > > > > > > > > > > - Use compatible strings instead of node names\n> > > > > > > > > > >\n> > > > > > > > > > > Changes in v5:\n> > > > > > > > > > > - Drop the memory-map node (should have done that in v4)\n> > > > > > > > > > > - Tidy up schema a bit\n> > > > > > > > > > >\n> > > > > > > > > > > Changes in v4:\n> > > > > > > > > > > - Make use of the reserved-memory node instead of creating a new one\n> > > > > > > > > > >\n> > > > > > > > > > > Changes in v3:\n> > > > > > > > > > > - Reword commit message again\n> > > > > > > > > > > - cc a lot more people, from the FFI patch\n> > > > > > > > > > > - Split out the attributes into the /memory nodes\n> > > > > > > > > > >\n> > > > > > > > > > > Changes in v2:\n> > > > > > > > > > > - Reword commit message\n> > > > > > > > > > >\n> > > > > > > > > > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > > > > > > > > > > 1 file changed, 71 insertions(+)\n> > > > > > > > > > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > > > > >\n> > > > > > > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > > > > > new file mode 100644\n> > > > > > > > > > > index 0000000..f7fbdfd\n> > > > > > > > > > > --- /dev/null\n> > > > > > > > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > > > > > @@ -0,0 +1,71 @@\n> > > > > > > > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause\n> > > > > > > > > > > +%YAML 1.2\n> > > > > > > > > > > +---\n> > > > > > > > > > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > > > > > > > > > > +\n> > > > > > > > > > > +title: Common memory reservations\n> > > > > > > > > > > +\n> > > > > > > > > > > +description: |\n> > > > > > > > > > > + Specifies that the reserved memory region can be used for the purpose\n> > > > > > > > > > > + indicated by its compatible string.\n> > > > > > > > > > > +\n> > > > > > > > > > > + Clients may reuse this reserved memory if they understand what it is for,\n> > > > > > > > > > > + subject to the notes below.\n> > > > > > > > > > > +\n> > > > > > > > > > > +maintainers:\n> > > > > > > > > > > + - Simon Glass \n> > > > > > > > > > > +\n> > > > > > > > > > > +allOf:\n> > > > > > > > > > > + - $ref: reserved-memory.yaml\n> > > > > > > > > > > +\n> > > > > > > > > > > +properties:\n> > > > > > > > > > > + compatible:\n> > > > > > > > > > > + description: |\n> > > > > > > > > > > + This describes some common memory reservations, with the compatible\n> > > > > > > > > > > + string indicating what it is used for:\n> > > > > > > > > > > +\n> > > > > > > > > > > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > > > > > > > > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > > > > > > > > > > + the firmware for its use and is required to be saved and restored\n> > > > > > > > > > > + across an NVS sleep\n> > > > > > > > > > > + boot-code: Contains code used for booting which is not needed by the OS\n> > > > > > > > > > > + boot-code: Contains data used for booting which is not needed by the OS\n> > > > > > > > > > > + runtime-code: Contains code used for interacting with the system when\n> > > > > > > > > > > + running the OS\n> > > > > > > > > > > + runtime-data: Contains data used for interacting with the system when\n> > > > > > > > > > > + running the OS\n> > > > > > > > > > > +\n> > > > > > > > > > > + enum:\n> > > > > > > > > > > + - acpi\n> > > > > > > > > > > + - acpi-nvs\n> > > > > > > > > > > + - boot-code\n> > > > > > > > > > > + - boot-data\n> > > > > > > > > > > + - runtime-code\n> > > > > > > > > > > + - runtime-data\n> > > > > > > > > > > +\n> > > > > > > > >\n> > > > > > > > > As I mentioned a few times already, I don't think these compatibles\n> > > > > > > > > should be introduced here.\n> > > > > > > > >\n> > > > > > > > > A reserved region has a specific purpose, and the compatible should be\n> > > > > > > > > more descriptive than the enum above. If the consumer does not\n> > > > > > > > > understand this purpose, it should simply treat the memory as reserved\n> > > > > > > > > and not touch it. Alternatively, these regions can be referenced from\n> > > > > > > > > other DT nodes using phandles if needed.\n> > > > > > > >\n> > > > > > > > We still need some description of what these regions are used for, so\n> > > > > > > > that the payload can use the correct regions. I do not have any other\n> > > > > > > > solution to this problem. We are in v7 at present. At least explain\n> > > > > > > > where you want the compatible strings to be introduced.\n> > > > > > > >\n> > > > > > >\n> > > > > > > My point is really that by themselves, these regions are not usable by\n> > > > > > > either a payload or an OS that consumes this information. Unless there\n> > > > > > > is some other information being provided (via DT I imagine) that\n> > > > > > > describes how these things are supposed to be used, they are nothing\n> > > > > > > more than memory reservations that should be honored, and providing\n> > > > > > > this arbitrary set of labels is unnecessary.\n> > > > > > >\n> > > > > > > > What sort of extra detail are you looking for? Please be specific and\n> > > > > > > > preferably add some suggestions so I can close this out ASAP.\n> > > > > > > >\n> > > > > > >\n> > > > > > > A payload or OS can do nothing with a memory reservation called\n> > > > > > > 'runtime-code' it it doesn't know what is inside.\n> > > > >\n> > > > > Agreed. The question is WHAT runtime-code? The compatible needs to answer that.\n> > > > >\n> > > > > For example, we have 'ramoops' as a compatible in reserved memory.\n> > > > > That tells us *exactly* what's there. We know how to parse it. If we\n> > > > > know ramoops is not supported, then we know we can toss it out and\n> > > > > reclaim the memory.\n> > > >\n> > > > So if we said:\n> > > >\n> > > > compatible = \"runtime-code-efi\"\n> > > >\n> > > > would that be OK? We seem to be in catch 22 here, because if I don't\n> > > > mention EFI unhappy, but if I do, Ard is unhappy.\n> > >\n> > > Better yes, because then it is for something specific. However, AIUI,\n> > > that's setup for the OS and defining that region is already defined by\n> > > the EFI memory map. That's Ard's issue. If there's a need outside of\n> > > the EFI to OS handoff,\n> >\n> > There is a need. Here is part of the commit message again. If there is\n> > something else you need to know, please ask.\n> >\n> > >>>>\n> > It is common to split firmware into 'Platform Init', which does the\n> > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > Thus an handover interface is required between these two pieces.\n> >\n> > Where UEFI boot-time services are not available, but UEFI firmware is\n> > present on either side of this interface, information about memory usage\n> > and attributes must be presented to the \"Payload\" in some form.\n> > <<<\n> >\n> > > then you need to define what that usecase looks\n> > > like. Describe the problem rather than present your solution.\n> > >\n> > > If this is all specific to EDK2 then it should say that rather than\n> > > 'efi'. I imagine Ard would be happier with something tied to EDK2 than\n> > > *all* UEFI. Though maybe the problem could be any implementation? IDK.\n> > > Maybe it's TF-A that needs to define where the EFI runtime services\n> > > region is and that needs to be passed all the way thru to the EFI\n> > > implementation? So again, define the problem.\n> >\n> > It is not specific to EDK2. Imagine this boot sequence:\n> >\n> > - Platform Init (U-Boot) starts up\n> > - U-Boot uses its platform knowledge to sets some ACPI tables and put\n> > various things in memory\n> > - U-Boot sets up some runtime code and data for the OS\n> > - U-Boot jumps to the Tianocore payload **\n> > - Payload (Tianocore) wants to know where the ACPI tables are, for example\n> > - Tianocore needs to provide boot services to the OS, so needs to know\n> > the memory map, etc.\n> >\n> > ** At this point we want to use DT to pass the required information.\n> >\n> > Of course, Platform Init could be coreboot or Tianocore or some\n> > strange private binary. Payload could be U-Boot or something else.\n> > That is the point of this effort, to build interoperability.\n> >\n> > >\n> > > > What about the boottime code....you want to know which project it is from?\n> > >\n> > > I think it is the same.\n> > >\n> > > >\n> > > > + - acpi\n> > > > + - acpi-nvs\n> > > >\n> > > > Those two should be enough info, right?\n> > >\n> > > I think so. NVS is not a term I've heard in relation to ACPI, but that\n> > > may just be my limited ACPI knowledge.\n> >\n> > Perhaps it is only an Intel thing. It stands for Non-Volatile-Sleeping\n> > Memory and it has various platform settings in a binary format that is\n> > normally SoC-specific.\n> >\n> > >\n> > > > + - boot-code\n> > > > + - boot-data\n> > > >\n> > > > For these, they don't pertain to the OS, so perhaps they are OK?\n> > >\n> > > Hard to tell that just from the name... 'boot' could be any component\n> > > involved in booting including the OS.\n> >\n> > suggested that 'boot' should mean booting the OS. If the OS does lots\n> > of fixup stuff at the start of it, I don't know what that is called.\n> >\n> > So if boot-code is no good, what do you suggest?\n> >\n> > Alternatively I could remove these for now, if it will help make progress.\n> >\n> > >\n> > > > In\n> > > > any case, using a generic term like this makes some sense to me. We\n> > > > can always add a new compatible like \"efi-boottime-services\" later. It\n> > > > may be that the boottime services would be handled by the payload, so\n> > > > not needed in all cases.\n> > >\n> > > Why later? You have a specific use in mind and I imagine Ard has\n> > > thoughts on that.\n> >\n> > Because we don't need it right away, and just want to make some progress.\n> >\n> > Perhaps the problem here is that Linux has tied itself up in knots\n> > with its EFI stuff and DT fixups and what-not. But this is not that.\n> > It is a simple handoff between two pieces of firmware, Platform Init\n> > and Payload. It has nothing to do with the OS. With Tianocore they are\n> > typically combined, but with this usage they are split, and we can\n> > swap out one project for another on either side of the DT interface.\n> >\n> > I do have views on the 'EFI' opt-out with reserved-memory, if you are\n> > interested, but that relates to the OS. If you are wanting to place\n> > some constraints on /reserved-memory and /memory we could do that\n> > e.g. that the DT and the map returned by EFI boot services must be\n> > consistent. But as it is, the nodes are ignored by the OS when booting\n> > with EFI, aren't they?\n>\n> Can this be applied, please? If there are further comments, please let me know.\n\nAny update, please?\n\nRegards,\nSimon","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256\n header.s=google header.b=gTT5ogct;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org\n header.b=\"gTT5ogct\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SPvYJ1lvsz1yQL\n\tfor ; Wed, 8 Nov 2023 03:58:09 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 2FD76870E7;\n\tTue, 7 Nov 2023 17:58:00 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id F4115871A0; Tue, 7 Nov 2023 17:57:58 +0100 (CET)","from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com\n [IPv6:2a00:1450:4864:20::52b])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id ECE8186EF1\n for ; Tue, 7 Nov 2023 17:57:55 +0100 (CET)","by mail-ed1-x52b.google.com with SMTP id\n 4fb4d7f45d1cf-53e3b8f906fso9916688a12.2\n for ; Tue, 07 Nov 2023 08:57:55 -0800 (PST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-9.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,\n SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_SPF_WL\n autolearn=no autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=chromium.org; s=google; t=1699376275; x=1699981075; darn=lists.denx.de;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=ya+2+6taOcYMazVndyG/Hpkj8Moi4Ilb8BzUHtUH9Hg=;\n b=gTT5ogct3RU/IsR57NeDmXCtleFZmV0FzqqIxKLD5KMWAk/NclKXxOYWmzwfJWOuQO\n YLB8DS31j+iQPwMIpulY6jCiYSBcRjgjjEGw2ggSgS3Vu7ZGdzmunQwUutQSXzM/DFZ6\n A/ctt8TrAs6Gkrft3KxRnJ+powck1miCVxMxI=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1699376275; x=1699981075;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc\n :subject:date:message-id:reply-to;\n bh=ya+2+6taOcYMazVndyG/Hpkj8Moi4Ilb8BzUHtUH9Hg=;\n b=k7135s+FbMN478sBOtkh87JVDdaJJ8fObO0aYC6QYpS3zpqLXM1biUqQ8cwluvuYOi\n HbBf9qRdBoPnkqWbyeAp2ag3pOWyni5450FYTV02a29R0bSKjvyz8+r8igrnpFm5mtif\n 26tOHtyFztiwuvATUNDYiqlykC9gC1SWhCTrsBQJpeFiAGw7f2eOKIf+uPYbdx+dh23F\n eEaBExDLVathnnEIrWfg4MuA5q4fK+0c+csRFDW4c7WiPfeNtQznA8wig3zmg8xTYUPo\n GqLGKd5tQdCAR8BD9z7g++h2joUnH7Xt0XloVGfs7ZqGGwAIhc9cR3HOpzn+3J01isH7\n 8YCw==","X-Gm-Message-State":"AOJu0YwqgBokY2yFe56O/xyfQqPIun2ZABZShiap2dMtU9+zpnHfa9V4\n I4w4QJ8QHpQ6eqVhenbtlb1ELqvI0ahr1COpAzr5Fw==","X-Google-Smtp-Source":"\n AGHT+IFzT0Yj7s8jOoIKBAlADODMM4QqvdtqenEKQJasAwd1/OYnUK4adWGZBt8VZ0rU0oQN8LNfYUrX0n4JLDMBEzc=","X-Received":"by 2002:a50:d0d5:0:b0:542:dcb4:37f with SMTP id\n g21-20020a50d0d5000000b00542dcb4037fmr23411840edf.41.1699376275107; Tue, 07\n Nov 2023 08:57:55 -0800 (PST)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Simon Glass ","Date":"Tue, 7 Nov 2023 09:57:35 -0700","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Rob Herring ","Cc":"Ard Biesheuvel , devicetree@vger.kernel.org,\n Mark Rutland ,\n Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3213082,"web_url":"http://patchwork.ozlabs.org/comment/3213082/","msgid":"","list_archive_url":null,"date":"2023-11-07T18:07:17","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring","email":"robh@kernel.org"},"content":"On Tue, Oct 31, 2023 at 10:56โ€ฏAM Simon Glass wrote:\n>\n> Hi Rob,\n>\n> On Mon, 16 Oct 2023 at 15:54, Simon Glass wrote:\n> >\n> > Hi Rob,\n> >\n> > On Mon, 16 Oct 2023 at 10:50, Rob Herring wrote:\n> > >\n> > > On Fri, Oct 13, 2023 at 4:09โ€ฏPM Simon Glass wrote:\n> > > >\n> > > > Hi Rob,\n> > > >\n> > > > On Fri, 13 Oct 2023 at 13:42, Rob Herring wrote:\n> > > > >\n> > > > > On Fri, Oct 6, 2023 at 7:03โ€ฏPM Simon Glass wrote:\n> > > > > >\n> > > > > > Hi Ard,\n> > > > > >\n> > > > > > On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel wrote:\n> > > > > > >\n> > > > > > > On Fri, 6 Oct 2023 at 20:17, Simon Glass wrote:\n> > > > > > > >\n> > > > > > > > Hi Ard,\n> > > > > > > >\n> > > > > > > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel wrote:\n> > > > > > > > >\n> > > > > > > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass wrote:\n> > > > > > > > > >\n> > > > > > > > > > Hi Rob,\n> > > > > > > > > >\n> > > > > > > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass wrote:\n> > > > > > > > > > >\n> > > > > > > > > > > It is common to split firmware into 'Platform Init', which does the\n> > > > > > > > > > > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > > > > > > > > > > Thus an handover interface is required between these two pieces.\n> > > > > > > > > > >\n> > > > > > > > > > > Where UEFI boot-time services are not available, but UEFI firmware is\n> > > > > > > > > > > present on either side of this interface, information about memory usage\n> > > > > > > > > > > and attributes must be presented to the \"Payload\" in some form.\n> > > > > > > > > > >\n> > > > > > > > > > > This aims to provide an small schema addition for the memory mapping\n> > > > > > > > > > > needed to keep these two pieces working together well.\n> > > > > > > > > > >\n> > > > > > > > > > > Signed-off-by: Simon Glass \n> > > > > > > > > > > ---\n> > > > > > > > > > >\n> > > > > > > > > > > Changes in v7:\n> > > > > > > > > > > - Rename acpi-reclaim to acpi\n> > > > > > > > > > > - Drop individual mention of when memory can be reclaimed\n> > > > > > > > > > > - Rewrite the item descriptions\n> > > > > > > > > > > - Add back the UEFI text (with trepidation)\n> > > > > > > > > >\n> > > > > > > > > > I am again checking on this series. Can it be applied, please?\n> > > > > > > > > >\n> > > > > > > > >\n> > > > > > > > > Apologies for the delay in response. I have been away.\n> > > > > > > >\n> > > > > > > > OK, I hope you had a nice trip.\n> > > > > > > >\n> > > > > > >\n> > > > > > > Thanks, it was wonderful!\n> > > > > > >\n> > > > > > > > >\n> > > > > > > > > >\n> > > > > > > > > > >\n> > > > > > > > > > > Changes in v6:\n> > > > > > > > > > > - Drop mention of UEFI\n> > > > > > > > > > > - Use compatible strings instead of node names\n> > > > > > > > > > >\n> > > > > > > > > > > Changes in v5:\n> > > > > > > > > > > - Drop the memory-map node (should have done that in v4)\n> > > > > > > > > > > - Tidy up schema a bit\n> > > > > > > > > > >\n> > > > > > > > > > > Changes in v4:\n> > > > > > > > > > > - Make use of the reserved-memory node instead of creating a new one\n> > > > > > > > > > >\n> > > > > > > > > > > Changes in v3:\n> > > > > > > > > > > - Reword commit message again\n> > > > > > > > > > > - cc a lot more people, from the FFI patch\n> > > > > > > > > > > - Split out the attributes into the /memory nodes\n> > > > > > > > > > >\n> > > > > > > > > > > Changes in v2:\n> > > > > > > > > > > - Reword commit message\n> > > > > > > > > > >\n> > > > > > > > > > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > > > > > > > > > > 1 file changed, 71 insertions(+)\n> > > > > > > > > > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > > > > >\n> > > > > > > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > > > > > new file mode 100644\n> > > > > > > > > > > index 0000000..f7fbdfd\n> > > > > > > > > > > --- /dev/null\n> > > > > > > > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > > > > > > > > @@ -0,0 +1,71 @@\n> > > > > > > > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause\n> > > > > > > > > > > +%YAML 1.2\n> > > > > > > > > > > +---\n> > > > > > > > > > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > > > > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > > > > > > > > > > +\n> > > > > > > > > > > +title: Common memory reservations\n> > > > > > > > > > > +\n> > > > > > > > > > > +description: |\n> > > > > > > > > > > + Specifies that the reserved memory region can be used for the purpose\n> > > > > > > > > > > + indicated by its compatible string.\n> > > > > > > > > > > +\n> > > > > > > > > > > + Clients may reuse this reserved memory if they understand what it is for,\n> > > > > > > > > > > + subject to the notes below.\n> > > > > > > > > > > +\n> > > > > > > > > > > +maintainers:\n> > > > > > > > > > > + - Simon Glass \n> > > > > > > > > > > +\n> > > > > > > > > > > +allOf:\n> > > > > > > > > > > + - $ref: reserved-memory.yaml\n> > > > > > > > > > > +\n> > > > > > > > > > > +properties:\n> > > > > > > > > > > + compatible:\n> > > > > > > > > > > + description: |\n> > > > > > > > > > > + This describes some common memory reservations, with the compatible\n> > > > > > > > > > > + string indicating what it is used for:\n> > > > > > > > > > > +\n> > > > > > > > > > > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > > > > > > > > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > > > > > > > > > > + the firmware for its use and is required to be saved and restored\n> > > > > > > > > > > + across an NVS sleep\n> > > > > > > > > > > + boot-code: Contains code used for booting which is not needed by the OS\n> > > > > > > > > > > + boot-code: Contains data used for booting which is not needed by the OS\n> > > > > > > > > > > + runtime-code: Contains code used for interacting with the system when\n> > > > > > > > > > > + running the OS\n> > > > > > > > > > > + runtime-data: Contains data used for interacting with the system when\n> > > > > > > > > > > + running the OS\n> > > > > > > > > > > +\n> > > > > > > > > > > + enum:\n> > > > > > > > > > > + - acpi\n> > > > > > > > > > > + - acpi-nvs\n> > > > > > > > > > > + - boot-code\n> > > > > > > > > > > + - boot-data\n> > > > > > > > > > > + - runtime-code\n> > > > > > > > > > > + - runtime-data\n> > > > > > > > > > > +\n> > > > > > > > >\n> > > > > > > > > As I mentioned a few times already, I don't think these compatibles\n> > > > > > > > > should be introduced here.\n> > > > > > > > >\n> > > > > > > > > A reserved region has a specific purpose, and the compatible should be\n> > > > > > > > > more descriptive than the enum above. If the consumer does not\n> > > > > > > > > understand this purpose, it should simply treat the memory as reserved\n> > > > > > > > > and not touch it. Alternatively, these regions can be referenced from\n> > > > > > > > > other DT nodes using phandles if needed.\n> > > > > > > >\n> > > > > > > > We still need some description of what these regions are used for, so\n> > > > > > > > that the payload can use the correct regions. I do not have any other\n> > > > > > > > solution to this problem. We are in v7 at present. At least explain\n> > > > > > > > where you want the compatible strings to be introduced.\n> > > > > > > >\n> > > > > > >\n> > > > > > > My point is really that by themselves, these regions are not usable by\n> > > > > > > either a payload or an OS that consumes this information. Unless there\n> > > > > > > is some other information being provided (via DT I imagine) that\n> > > > > > > describes how these things are supposed to be used, they are nothing\n> > > > > > > more than memory reservations that should be honored, and providing\n> > > > > > > this arbitrary set of labels is unnecessary.\n> > > > > > >\n> > > > > > > > What sort of extra detail are you looking for? Please be specific and\n> > > > > > > > preferably add some suggestions so I can close this out ASAP.\n> > > > > > > >\n> > > > > > >\n> > > > > > > A payload or OS can do nothing with a memory reservation called\n> > > > > > > 'runtime-code' it it doesn't know what is inside.\n> > > > >\n> > > > > Agreed. The question is WHAT runtime-code? The compatible needs to answer that.\n> > > > >\n> > > > > For example, we have 'ramoops' as a compatible in reserved memory.\n> > > > > That tells us *exactly* what's there. We know how to parse it. If we\n> > > > > know ramoops is not supported, then we know we can toss it out and\n> > > > > reclaim the memory.\n> > > >\n> > > > So if we said:\n> > > >\n> > > > compatible = \"runtime-code-efi\"\n> > > >\n> > > > would that be OK? We seem to be in catch 22 here, because if I don't\n> > > > mention EFI unhappy, but if I do, Ard is unhappy.\n> > >\n> > > Better yes, because then it is for something specific. However, AIUI,\n> > > that's setup for the OS and defining that region is already defined by\n> > > the EFI memory map. That's Ard's issue. If there's a need outside of\n> > > the EFI to OS handoff,\n> >\n> > There is a need. Here is part of the commit message again. If there is\n> > something else you need to know, please ask.\n> >\n> > >>>>\n> > It is common to split firmware into 'Platform Init', which does the\n> > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > Thus an handover interface is required between these two pieces.\n> >\n> > Where UEFI boot-time services are not available, but UEFI firmware is\n> > present on either side of this interface, information about memory usage\n> > and attributes must be presented to the \"Payload\" in some form.\n> > <<<\n> >\n> > > then you need to define what that usecase looks\n> > > like. Describe the problem rather than present your solution.\n> > >\n> > > If this is all specific to EDK2 then it should say that rather than\n> > > 'efi'. I imagine Ard would be happier with something tied to EDK2 than\n> > > *all* UEFI. Though maybe the problem could be any implementation? IDK.\n> > > Maybe it's TF-A that needs to define where the EFI runtime services\n> > > region is and that needs to be passed all the way thru to the EFI\n> > > implementation? So again, define the problem.\n> >\n\nAll of this:\n\n> > It is not specific to EDK2. Imagine this boot sequence:\n> >\n> > - Platform Init (U-Boot) starts up\n> > - U-Boot uses its platform knowledge to sets some ACPI tables and put\n> > various things in memory\n> > - U-Boot sets up some runtime code and data for the OS\n> > - U-Boot jumps to the Tianocore payload **\n> > - Payload (Tianocore) wants to know where the ACPI tables are, for example\n> > - Tianocore needs to provide boot services to the OS, so needs to know\n> > the memory map, etc.\n> >\n> > ** At this point we want to use DT to pass the required information.\n> >\n> > Of course, Platform Init could be coreboot or Tianocore or some\n> > strange private binary. Payload could be U-Boot or something else.\n> > That is the point of this effort, to build interoperability.\n\n[...]\n\n> > Perhaps the problem here is that Linux has tied itself up in knots\n> > with its EFI stuff and DT fixups and what-not. But this is not that.\n> > It is a simple handoff between two pieces of firmware, Platform Init\n> > and Payload. It has nothing to do with the OS. With Tianocore they are\n> > typically combined, but with this usage they are split, and we can\n> > swap out one project for another on either side of the DT interface.\n\nIs perhaps the clearest description of the problem you want to solve.\nIt's clearly related to EFI though not the interface to the OS. IIRC,\n\"platform init\" and \"payload\" are terms in the UEFI spec, right? I\ndon't recall how well defined those are vs. just abstract concepts.\n\nIs it only for this interface or any firmware to firmware handoff. If\nthe former, then I'm looking for folks involved with EFI/Tianocore to\nhave some buy-in. If the latter, then this should be part of the\nfirmware handoff efforts and have buy-in there.\n\n> > I do have views on the 'EFI' opt-out with reserved-memory, if you are\n> > interested, but that relates to the OS. If you are wanting to place\n> > some constraints on /reserved-memory and /memory we could do that\n> > e.g. that the DT and the map returned by EFI boot services must be\n> > consistent. But as it is, the nodes are ignored by the OS when booting\n> > with EFI, aren't they?\n>\n> Can this be applied, please? If there are further comments, please let me know.\n\nI really have limited knowledge and interest in this. I don't mind\nhosting something like this in dtschema, but I'm not taking it without\nbuy-in from multiple parties which I haven't seen.\n\nRob","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=sRgsBa8q;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.b=\"sRgsBa8q\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de; spf=pass smtp.mailfrom=robh@kernel.org"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SPx5T2zdhz1yQg\n\tfor ; Wed, 8 Nov 2023 05:07:41 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 3FDC98759F;\n\tTue, 7 Nov 2023 19:07:39 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id 048A8875AF; Tue, 7 Nov 2023 19:07:38 +0100 (CET)","from dfw.source.kernel.org (dfw.source.kernel.org\n [IPv6:2604:1380:4641:c500::1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 246E086FB4\n for ; Tue, 7 Nov 2023 19:07:35 +0100 (CET)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by dfw.source.kernel.org (Postfix) with ESMTP id 0DBF9612FB\n for ; Tue, 7 Nov 2023 18:07:33 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id A8A26C433C7\n for ; Tue, 7 Nov 2023 18:07:32 +0000 (UTC)","by mail-lf1-f54.google.com with SMTP id\n 2adb3069b0e04-507b9408c61so7907683e87.0\n for ; Tue, 07 Nov 2023 10:07:32 -0800 (PST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no\n version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1699380452;\n bh=N4rlLB7z0cOpmpZ/BL47aepJIVFWZKyXA+rtWoCv60w=;\n h=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n b=sRgsBa8qACxFk3y3ZOaSg8tHjo+4wTRAOUpyF8JP/B5UMc4xslcblbWkaVukJdT7S\n 2pCk37qx5rwSN/Sgc3EmxeTtCrx5KBD+Hh9a9wvZcUmWTHpyn+xlVrwAcEiaSHO82O\n qxfYul6ha0KWjDPFEwgrRfemMDKyRIvf85xKoQG0/FWOxaVmPA6UMWBM3iEyXNzTwY\n I2JPs/RyJiRoueQ3Nd4/YwlL7ld7fuZd1vUNT8xaoJbwXjzgZyUagyoiN4UfmIDGl7\n jjws5LmLelcPEGXFR/AcKV6Gfv31cE8IrqVTCFNff04y+Q0i2U4mK5dmi1cnHU6R/O\n OthnVK9kqt1oA==","X-Gm-Message-State":"AOJu0YzawSMXGr+sOpRhV4J+IrOaneqUm9QsDjAjoMenDBdhtI+7J3Pq\n SRJ77zZpAXVZPfbhAPDhCUi0UJx/vZBhCl7IAQ==","X-Google-Smtp-Source":"\n AGHT+IEkUVYvX0YzvXzJFUleQKdN0GE9vRVxqaXq3qMhrMlB77Pbme7h7KcKJjsSIgU5e9Jsi4+ATC2DZumGeHvPbdQ=","X-Received":"by 2002:a05:6512:557:b0:503:24c7:df34 with SMTP id\n h23-20020a056512055700b0050324c7df34mr24961177lfl.11.1699380450811; Tue, 07\n Nov 2023 10:07:30 -0800 (PST)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Rob Herring ","Date":"Tue, 7 Nov 2023 12:07:17 -0600","X-Gmail-Original-Message-ID":"\n ","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Simon Glass ","Cc":"Ard Biesheuvel , devicetree@vger.kernel.org,\n Mark Rutland ,\n Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3213470,"web_url":"http://patchwork.ozlabs.org/comment/3213470/","msgid":"","list_archive_url":null,"date":"2023-11-08T11:38:33","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":77831,"url":"http://patchwork.ozlabs.org/api/people/77831/","name":"Ard Biesheuvel","email":"ardb@kernel.org"},"content":"On Tue, 7 Nov 2023 at 19:07, Rob Herring wrote:\n>\n>\n> All of this:\n>\n\n> > On Mon, 16 Oct 2023 at 15:54, Simon Glass wrote:\n> > >\n> > > It is not specific to EDK2. Imagine this boot sequence:\n> > >\n> > > - Platform Init (U-Boot) starts up\n> > > - U-Boot uses its platform knowledge to sets some ACPI tables and put\n> > > various things in memory\n> > > - U-Boot sets up some runtime code and data for the OS\n> > > - U-Boot jumps to the Tianocore payload **\n> > > - Payload (Tianocore) wants to know where the ACPI tables are, for example\n> > > - Tianocore needs to provide boot services to the OS, so needs to know\n> > > the memory map, etc.\n> > >\n> > > ** At this point we want to use DT to pass the required information.\n> > >\n> > > Of course, Platform Init could be coreboot or Tianocore or some\n> > > strange private binary. Payload could be U-Boot or something else.\n> > > That is the point of this effort, to build interoperability.\n>\n> [...]\n>\n> > > Perhaps the problem here is that Linux has tied itself up in knots\n> > > with its EFI stuff and DT fixups and what-not. But this is not that.\n> > > It is a simple handoff between two pieces of firmware, Platform Init\n> > > and Payload. It has nothing to do with the OS. With Tianocore they are\n> > > typically combined, but with this usage they are split, and we can\n> > > swap out one project for another on either side of the DT interface.\n>\n> Is perhaps the clearest description of the problem you want to solve.\n> It's clearly related to EFI though not the interface to the OS. IIRC,\n> \"platform init\" and \"payload\" are terms in the UEFI spec, right?\n\nNo they are not. This is from the universal payload specification that\nis being drafted here\n\nhttps://universalpayload.github.io/spec/index.html\n\nbut the UEFI specification does not use this terminology.\n\n> I don't recall how well defined those are vs. just abstract concepts.\n>\n> Is it only for this interface or any firmware to firmware handoff. If\n> the former, then I'm looking for folks involved with EFI/Tianocore to\n> have some buy-in. If the latter, then this should be part of the\n> firmware handoff efforts and have buy-in there.\n>\n\nI still haven't seen any example of how platform init would make\nmeaningful use of 'boot-code' and 'runtime-code' regions to inform a\npayload about executable regions in memory. Especially 'runtime code'\nis interesting here, as it presumably means that the OS must map such\nregions as executable in some way. This is why I mentioned phandles in\na previous reply: there /must/ be some additional context provided\nelsewhere, or the distinction between boot code/data and runtime\ncode/data is meaningless.\n\nSo again, can we *please* have an example of how these regions will be\nused in practice?\n\n> > > I do have views on the 'EFI' opt-out with reserved-memory, if you are\n> > > interested, but that relates to the OS. If you are wanting to place\n> > > some constraints on /reserved-memory and /memory we could do that\n> > > e.g. that the DT and the map returned by EFI boot services must be\n> > > consistent. But as it is, the nodes are ignored by the OS when booting\n> > > with EFI, aren't they?\n> >\n> > Can this be applied, please? If there are further comments, please let me know.\n>\n> I really have limited knowledge and interest in this. I don't mind\n> hosting something like this in dtschema, but I'm not taking it without\n> buy-in from multiple parties which I haven't seen.\n>\n\nI will state again that I do not object to these bindings as long as\nthey are restricted to use in the context of firmware. However, there\nis no scoping in DT schema as far as I am aware, which means that the\nOS may be forced/expected to interpret these regions beyond simply\ndisregarding them and treating them as reserved memory, and *that* is\nsomething I strongly object to.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=UT3W5d5e;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.b=\"UT3W5d5e\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de; spf=pass smtp.mailfrom=ardb@kernel.org"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SQNQY3cgzz1yQl\n\tfor ; Wed, 8 Nov 2023 22:38:59 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id E2A16874DC;\n\tWed, 8 Nov 2023 12:38:51 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id 55721875EA; Wed, 8 Nov 2023 12:38:50 +0100 (CET)","from ams.source.kernel.org (ams.source.kernel.org\n [IPv6:2604:1380:4601:e00::1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id EF7D88749D\n for ; Wed, 8 Nov 2023 12:38:47 +0100 (CET)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by ams.source.kernel.org (Postfix) with ESMTP id 7A11FB81AF7\n for ; Wed, 8 Nov 2023 11:38:47 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 88775C43397\n for ; Wed, 8 Nov 2023 11:38:46 +0000 (UTC)","by mail-lj1-f175.google.com with SMTP id\n 38308e7fff4ca-2c50906f941so96932831fa.2\n for ; Wed, 08 Nov 2023 03:38:46 -0800 (PST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no\n version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1699443526;\n bh=vGXPlqnsevPIGZEWSM3CikPCEVA3knUIxql8hMIFa+8=;\n h=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n b=UT3W5d5euKmiYSHd8WWdlrXj+43eOfV4an0TzJho8R4LZp7CY1/nNRTrmHCmg2gky\n mMKRJFvTDxdo5U9r3+rydjzYYW572TAs1XERGXtUmO+Ay0rETC3Q1ShYtGZvUKQcJ/\n pjOwWr+JXzcM/0ps6QshVA+MMMb6OdA7fjOSI+og7nsFMIimiLxO/UFqLICbdAgh2s\n 0RoXPc06wblhuGeblQJtdFRKKJGksjGxakbkWCqiAA2DEC4kFMF62e/pbD0rhzBoe4\n pmlP4DqiBg/1XWnDVPYvOTX/NC6sXHVsVD5uRgckM/O1mx0CMqkRl7lWITUg5xWkFk\n HnMKT8aAiVHtg==","X-Gm-Message-State":"AOJu0YwsW7vS+QAxFYkEI2CcGCqC8BdVzyxft5GroERU8uWPZiGH1Agv\n 5i4L2GOITfh5KP5MalIa3TveB66e+z/Le0tUi6w=","X-Google-Smtp-Source":"\n AGHT+IEQ9bty1WIItGB/rSDnD5+xGDKEJz18MvCqVthKxr2g3hVt1rDXhjwsogoBOkJGa9uGw8Cqpa0oILGNn3aOwmY=","X-Received":"by 2002:a2e:ba9e:0:b0:2c5:1e70:7d30 with SMTP id\n a30-20020a2eba9e000000b002c51e707d30mr1324249ljf.30.1699443524688; Wed, 08\n Nov 2023 03:38:44 -0800 (PST)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Ard Biesheuvel ","Date":"Wed, 8 Nov 2023 12:38:33 +0100","X-Gmail-Original-Message-ID":"\n ","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Rob Herring ","Cc":"Simon Glass , devicetree@vger.kernel.org,\n Mark Rutland ,\n Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3213540,"web_url":"http://patchwork.ozlabs.org/comment/3213540/","msgid":"","list_archive_url":null,"date":"2023-11-08T13:57:15","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":62529,"url":"http://patchwork.ozlabs.org/api/people/62529/","name":"Rob Herring","email":"robh@kernel.org"},"content":"On Wed, Nov 8, 2023 at 5:38โ€ฏAM Ard Biesheuvel wrote:\n>\n> On Tue, 7 Nov 2023 at 19:07, Rob Herring wrote:\n> >\n> >\n> > All of this:\n> >\n>\n> > > On Mon, 16 Oct 2023 at 15:54, Simon Glass wrote:\n> > > >\n> > > > It is not specific to EDK2. Imagine this boot sequence:\n> > > >\n> > > > - Platform Init (U-Boot) starts up\n> > > > - U-Boot uses its platform knowledge to sets some ACPI tables and put\n> > > > various things in memory\n> > > > - U-Boot sets up some runtime code and data for the OS\n> > > > - U-Boot jumps to the Tianocore payload **\n> > > > - Payload (Tianocore) wants to know where the ACPI tables are, for example\n> > > > - Tianocore needs to provide boot services to the OS, so needs to know\n> > > > the memory map, etc.\n> > > >\n> > > > ** At this point we want to use DT to pass the required information.\n> > > >\n> > > > Of course, Platform Init could be coreboot or Tianocore or some\n> > > > strange private binary. Payload could be U-Boot or something else.\n> > > > That is the point of this effort, to build interoperability.\n> >\n> > [...]\n> >\n> > > > Perhaps the problem here is that Linux has tied itself up in knots\n> > > > with its EFI stuff and DT fixups and what-not. But this is not that.\n> > > > It is a simple handoff between two pieces of firmware, Platform Init\n> > > > and Payload. It has nothing to do with the OS. With Tianocore they are\n> > > > typically combined, but with this usage they are split, and we can\n> > > > swap out one project for another on either side of the DT interface.\n> >\n> > Is perhaps the clearest description of the problem you want to solve.\n> > It's clearly related to EFI though not the interface to the OS. IIRC,\n> > \"platform init\" and \"payload\" are terms in the UEFI spec, right?\n>\n> No they are not. This is from the universal payload specification that\n> is being drafted here\n>\n> https://universalpayload.github.io/spec/index.html\n>\n> but the UEFI specification does not use this terminology.\n\nThen I'm confused as to what this is:\n\nhttps://uefi.org/specs/PI/1.8/index.html\n\nRob","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=TLLvN3zb;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.b=\"TLLvN3zb\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de; spf=pass smtp.mailfrom=robh@kernel.org"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SQRVW6ZfFz1yQK\n\tfor ; Thu, 9 Nov 2023 00:57:39 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 1C2A687209;\n\tWed, 8 Nov 2023 14:57:37 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id 2AE8687227; Wed, 8 Nov 2023 14:57:35 +0100 (CET)","from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id ADDFA86DFF\n for ; Wed, 8 Nov 2023 14:57:31 +0100 (CET)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by dfw.source.kernel.org (Postfix) with ESMTP id B6E6F61602\n for ; Wed, 8 Nov 2023 13:57:29 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 87A36C43397\n for ; Wed, 8 Nov 2023 13:57:29 +0000 (UTC)","by mail-lf1-f50.google.com with SMTP id\n 2adb3069b0e04-507975d34e8so9967058e87.1\n for ; Wed, 08 Nov 2023 05:57:29 -0800 (PST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no\n version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1699451849;\n bh=oAMyGLNvlEk2Z3kcyrMLZHtZ2K7CmXV47NgxDhyFDAI=;\n h=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n b=TLLvN3zbeCodFityx/4ypnt/Ii/fLaigJHu+596F82grUSxrOKhUp5VnJ10ovHhGv\n TQVt+OifIzv1INb3RTscv+PKfnTR/VZ8VqSq7/ZL66e4nDpmbbBAPs7YOBrYmZnGlO\n qF/ZUayfqAma1ZWC5m63Ga58DPZ99AmzuijezXivJABvO1R0GUBdOomF7mVGJ5DcPD\n SatYDtXoRSRvA2oZRCgQjl+dEgpfDW1nV+g1uZLgS2hEEu8CerEmr+rFNBtjpTaqsv\n XzS65rJj1xOOVKWSPvaaJUKjsWRz/XhhvcYjMSAefJnHMH/E/5ioxrSdzr1Td/5o/U\n AmTn32Jy6Wjfg==","X-Gm-Message-State":"AOJu0YzKMj0LiuJF5B2RN2tQnRnd7V9LjDYYY9VD22qvEoon5+fs4yJy\n ZB8p6s5NC1wVGJNh5RtaJ2MgbSKXSKcqOR8mYA==","X-Google-Smtp-Source":"\n AGHT+IGuwHUp+aEG6CZkAVv9OagCbfM3Ciyh9iJ50ppoxMFJJ3ItGNnVmTiHOsiB5o//EA7YPSpGzVzEkTMc7343V6w=","X-Received":"by 2002:ac2:5397:0:b0:507:b9db:61dc with SMTP id\n g23-20020ac25397000000b00507b9db61dcmr1259652lfh.48.1699451847501; Wed, 08\n Nov 2023 05:57:27 -0800 (PST)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n \n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Rob Herring ","Date":"Wed, 8 Nov 2023 07:57:15 -0600","X-Gmail-Original-Message-ID":"\n ","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Ard Biesheuvel ","Cc":"Simon Glass , devicetree@vger.kernel.org,\n Mark Rutland ,\n Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3213545,"web_url":"http://patchwork.ozlabs.org/comment/3213545/","msgid":"","list_archive_url":null,"date":"2023-11-08T14:20:38","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":77831,"url":"http://patchwork.ozlabs.org/api/people/77831/","name":"Ard Biesheuvel","email":"ardb@kernel.org"},"content":"On Wed, 8 Nov 2023 at 14:57, Rob Herring wrote:\n>\n> On Wed, Nov 8, 2023 at 5:38โ€ฏAM Ard Biesheuvel wrote:\n> >\n> > On Tue, 7 Nov 2023 at 19:07, Rob Herring wrote:\n> > >\n> > >\n> > > All of this:\n> > >\n> >\n> > > > On Mon, 16 Oct 2023 at 15:54, Simon Glass wrote:\n> > > > >\n> > > > > It is not specific to EDK2. Imagine this boot sequence:\n> > > > >\n> > > > > - Platform Init (U-Boot) starts up\n> > > > > - U-Boot uses its platform knowledge to sets some ACPI tables and put\n> > > > > various things in memory\n> > > > > - U-Boot sets up some runtime code and data for the OS\n> > > > > - U-Boot jumps to the Tianocore payload **\n> > > > > - Payload (Tianocore) wants to know where the ACPI tables are, for example\n> > > > > - Tianocore needs to provide boot services to the OS, so needs to know\n> > > > > the memory map, etc.\n> > > > >\n> > > > > ** At this point we want to use DT to pass the required information.\n> > > > >\n> > > > > Of course, Platform Init could be coreboot or Tianocore or some\n> > > > > strange private binary. Payload could be U-Boot or something else.\n> > > > > That is the point of this effort, to build interoperability.\n> > >\n> > > [...]\n> > >\n> > > > > Perhaps the problem here is that Linux has tied itself up in knots\n> > > > > with its EFI stuff and DT fixups and what-not. But this is not that.\n> > > > > It is a simple handoff between two pieces of firmware, Platform Init\n> > > > > and Payload. It has nothing to do with the OS. With Tianocore they are\n> > > > > typically combined, but with this usage they are split, and we can\n> > > > > swap out one project for another on either side of the DT interface.\n> > >\n> > > Is perhaps the clearest description of the problem you want to solve.\n> > > It's clearly related to EFI though not the interface to the OS. IIRC,\n> > > \"platform init\" and \"payload\" are terms in the UEFI spec, right?\n> >\n> > No they are not. This is from the universal payload specification that\n> > is being drafted here\n> >\n> > https://universalpayload.github.io/spec/index.html\n> >\n> > but the UEFI specification does not use this terminology.\n>\n> Then I'm confused as to what this is:\n>\n> https://uefi.org/specs/PI/1.8/index.html\n>\n\nThe PI and UEFI specifications are both maintained by the UEFI forum.\n\nThe UEFI specification covers external APIs for firmware\nimplementations, i.e., the OS visible interface and the public API for\nUEFI device drivers that are not tightly integrated with system\nfirmware (for example, the GPU boot time driver in the ROM of an\nadd-in card)\n\nThe UEFI forum's PI spec describes system firmware internals, and\ndefines the SEC, PEI DXE and BDS boot phases, among other things.\n\nIt is possible to implement UEFI without PI (which is what uboot does,\nfor instance), but Tianocore/EDK2 is the reference implementation for\nboth PI and UEFI, and sadly, there is no discernible distinction\nbetween the two (e.g., both PI and UEFI use identifiers with EFI_ type\nand enum identifier prefixes)\n\n'platform init' in the context of this discussion is something\ncompletely separate, and has zero bearing on the PI<->UEFI handover in\nTianocore (which is not really a handover to begin with).\n\nThere is code in Tianocore which allows it to run as a 'payload',\nwhich means [presumably] that only the DXE and subsequent phases are\nlaunched from a 'platform init' component that describes the platform\nusing some of the DT bindings that are under discussion here. In this\ncase, I can see how some of the ACPI descriptions provided by the\n'platform init' might be inherited by the 'payload'. However, I don't\nsee how such a Tianocore payload would make meaningful use of\nboot/runtime code/data described in general terms using this proposed\nbinding, which is why I keep asking for an example scenario.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=rWV9Xw8N;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.b=\"rWV9Xw8N\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de; spf=pass smtp.mailfrom=ardb@kernel.org"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SQS1k3v4Yz1yQl\n\tfor ; Thu, 9 Nov 2023 01:21:14 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 4D4BD87272;\n\tWed, 8 Nov 2023 15:20:57 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id A668086FB2; Wed, 8 Nov 2023 15:20:55 +0100 (CET)","from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 5D2C98721C\n for ; Wed, 8 Nov 2023 15:20:53 +0100 (CET)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by ams.source.kernel.org (Postfix) with ESMTP id DFD21B81C01\n for ; Wed, 8 Nov 2023 14:20:52 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 00D1EC4339A\n for ; Wed, 8 Nov 2023 14:20:52 +0000 (UTC)","by mail-lj1-f169.google.com with SMTP id\n 38308e7fff4ca-2c6b30acacdso91899321fa.2\n for ; Wed, 08 Nov 2023 06:20:51 -0800 (PST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no\n version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1699453252;\n bh=E82DmwfH2dcxbs9xwMmLiAaOTn5D4Ow/0Cpeotwv8Tc=;\n h=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n b=rWV9Xw8NQwgrRa5bh7nxobt3EqPIBdZysZTWWrerABqOhIeuc1Jnby1BN2RDe6jSo\n wMC3krMIgAV9h8cHBuiFMh3OnoC3PvFNYfXcFr8asqoC8PUIh9NLWF0HfK/5X9PJna\n FtNp1qyXtzlxe51KM8v9HXKo949wd8TvzBYHFjWrIpr/fJT718UUvyZZYNHdr9Gz87\n lpBiEXfyw04EV1dbr6WISFxIDQcdQfSpYgg7s8OXdUzU7Wl5EHf9NVIujRA8jtvOAS\n 4hYRkewHrL2b9sIIiuVIjloxGRyoSp0Rqw3Z1EVhordXWA9/lMH6d3wK30okromWFX\n DblWljL7w3jaw==","X-Gm-Message-State":"AOJu0YyI1r99zqoENzn+GxU4R1CS5HFj/M5zdF7aUy4SN0LtthsmuSS4\n n63OrLE8SB2TPVP/RK5tT+eAgfbv78rUVXHx3Wc=","X-Google-Smtp-Source":"\n AGHT+IF3AlqJpBLUhu1DTarhTz6FDwvlN0RLFjtbhZO/9hXihKmHvPiQC4/ncAP2kR3ROp5UFGC31vCUAe8Gj7r8AZQ=","X-Received":"by 2002:a2e:8e3c:0:b0:2c6:eaf8:49ff with SMTP id\n r28-20020a2e8e3c000000b002c6eaf849ffmr1584451ljk.37.1699453250122; Wed, 08\n Nov 2023 06:20:50 -0800 (PST)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n \n \n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Ard Biesheuvel ","Date":"Wed, 8 Nov 2023 15:20:38 +0100","X-Gmail-Original-Message-ID":"\n ","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Rob Herring ","Cc":"Simon Glass , devicetree@vger.kernel.org,\n Mark Rutland ,\n Lean Sheng Tan ,\n lkml , Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui ,\n Guo Dong , Tom Rini ,\n ron minnich , Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3213689,"web_url":"http://patchwork.ozlabs.org/comment/3213689/","msgid":"","list_archive_url":null,"date":"2023-11-08T17:53:59","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":87134,"url":"http://patchwork.ozlabs.org/api/people/87134/","name":"Lean Sheng Tan","email":"sheng.tan@9elements.com"},"content":"Hi Rob,\nSure, I will ask if the edk2 developers who work together for UPL spec\ncould help to respond here.\n\nHi Ard,\nRegarding this part:\n*However, there is no scoping in DT schema as far as I am aware, which\nmeans that the OS may be forced/expected to interpret these regions beyond\nsimply disregarding them and treating them as reserved memory, and *that*\nis something I strongly object to.*\n\nI think that is one of good perspective to look into this, however please\nalso consider this situation: that everyone is just starting to develop\ntheir own DT schemas (e.g. RISC-V), and there is no way to stop OS to also\npick up those DT nodes. in that case, if we do not maintain a more unified\nDT schema, then OS might end up with more conflicting and\npossibly contracting DT nodes/ properties (e.g. RISC-V with own DT schemas\nusing U-Boot (another DT schema) + edk2 payload (another DT schema, like\nUPL) to boot to OS. So personally I still prefer a unified DT schema, even\nif the OS never uses them, but that would be very beneficial and in control\nin the long term if more people are using DT.\n\nFor now, the DT does serve as the purpose of communication vehicle in\nbetween platform init and payload, which is still within Firmware stack.\nHowever from edk2 stand point, there is more people want to roll out DT for\nmore internal usage within edk2 itself, for example:\nhttps://uefi.org/sites/default/files/resources/Embracing%20Modularity%20and%20Boot-Time%20Configuration%20Faster%20TTM%20with%20Tiano-based%20Solutions_Warkentin.pdf\n\nFor sure, it is much easier for us (and time saving as well) to just\nmaintain DT schema/ format within our own UPL spec, but as mentioned, for\nbetter long term maintenance and community collaborations, we decided to\nupstream our implementation back to the main DT schema :)\n\nThanks!\n\nBest Regards,\n*Lean Sheng Tan*\n\n\n\n9elements GmbH, KortumstraรŸe 19-21, 44787 Bochum, Germany\nEmail: sheng.tan@9elements.com\nPhone: *+49 234 68 94 188 <+492346894188>*\nMobile: *+49 176 76 113842 <+4917676113842>*\n\nRegistered office: Bochum\nCommercial register: Amtsgericht Bochum, HRB 17519\nManagement: Sebastian German, Eray Bazaar\n\nData protection information according to Art. 13 GDPR\n\n\n\nOn Wed, 8 Nov 2023 at 15:20, Ard Biesheuvel wrote:\n\n> On Wed, 8 Nov 2023 at 14:57, Rob Herring wrote:\n> >\n> > On Wed, Nov 8, 2023 at 5:38โ€ฏAM Ard Biesheuvel wrote:\n> > >\n> > > On Tue, 7 Nov 2023 at 19:07, Rob Herring wrote:\n> > > >\n> > > >\n> > > > All of this:\n> > > >\n> > >\n> > > > > On Mon, 16 Oct 2023 at 15:54, Simon Glass \n> wrote:\n> > > > > >\n> > > > > > It is not specific to EDK2. Imagine this boot sequence:\n> > > > > >\n> > > > > > - Platform Init (U-Boot) starts up\n> > > > > > - U-Boot uses its platform knowledge to sets some ACPI tables\n> and put\n> > > > > > various things in memory\n> > > > > > - U-Boot sets up some runtime code and data for the OS\n> > > > > > - U-Boot jumps to the Tianocore payload **\n> > > > > > - Payload (Tianocore) wants to know where the ACPI tables are,\n> for example\n> > > > > > - Tianocore needs to provide boot services to the OS, so needs\n> to know\n> > > > > > the memory map, etc.\n> > > > > >\n> > > > > > ** At this point we want to use DT to pass the required\n> information.\n> > > > > >\n> > > > > > Of course, Platform Init could be coreboot or Tianocore or some\n> > > > > > strange private binary. Payload could be U-Boot or something\n> else.\n> > > > > > That is the point of this effort, to build interoperability.\n> > > >\n> > > > [...]\n> > > >\n> > > > > > Perhaps the problem here is that Linux has tied itself up in\n> knots\n> > > > > > with its EFI stuff and DT fixups and what-not. But this is not\n> that.\n> > > > > > It is a simple handoff between two pieces of firmware, Platform\n> Init\n> > > > > > and Payload. It has nothing to do with the OS. With Tianocore\n> they are\n> > > > > > typically combined, but with this usage they are split, and we\n> can\n> > > > > > swap out one project for another on either side of the DT\n> interface.\n> > > >\n> > > > Is perhaps the clearest description of the problem you want to solve.\n> > > > It's clearly related to EFI though not the interface to the OS. IIRC,\n> > > > \"platform init\" and \"payload\" are terms in the UEFI spec, right?\n> > >\n> > > No they are not. This is from the universal payload specification that\n> > > is being drafted here\n> > >\n> > > https://universalpayload.github.io/spec/index.html\n> > >\n> > > but the UEFI specification does not use this terminology.\n> >\n> > Then I'm confused as to what this is:\n> >\n> > https://uefi.org/specs/PI/1.8/index.html\n> >\n>\n> The PI and UEFI specifications are both maintained by the UEFI forum.\n>\n> The UEFI specification covers external APIs for firmware\n> implementations, i.e., the OS visible interface and the public API for\n> UEFI device drivers that are not tightly integrated with system\n> firmware (for example, the GPU boot time driver in the ROM of an\n> add-in card)\n>\n> The UEFI forum's PI spec describes system firmware internals, and\n> defines the SEC, PEI DXE and BDS boot phases, among other things.\n>\n> It is possible to implement UEFI without PI (which is what uboot does,\n> for instance), but Tianocore/EDK2 is the reference implementation for\n> both PI and UEFI, and sadly, there is no discernible distinction\n> between the two (e.g., both PI and UEFI use identifiers with EFI_ type\n> and enum identifier prefixes)\n>\n> 'platform init' in the context of this discussion is something\n> completely separate, and has zero bearing on the PI<->UEFI handover in\n> Tianocore (which is not really a handover to begin with).\n>\n> There is code in Tianocore which allows it to run as a 'payload',\n> which means [presumably] that only the DXE and subsequent phases are\n> launched from a 'platform init' component that describes the platform\n> using some of the DT bindings that are under discussion here. In this\n> case, I can see how some of the ACPI descriptions provided by the\n> 'platform init' might be inherited by the 'payload'. However, I don't\n> see how such a Tianocore payload would make meaningful use of\n> boot/runtime code/data described in general terms using this proposed\n> binding, which is why I keep asking for an example scenario.\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n secure) header.d=9elements.com header.i=@9elements.com header.a=rsa-sha256\n header.s=google header.b=L6pb2Juq;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=85.214.62.61; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=fail (p=none dis=none) header.from=9elements.com","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n secure) header.d=9elements.com header.i=@9elements.com header.b=\"L6pb2Juq\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=9elements.com","phobos.denx.de;\n spf=pass smtp.mailfrom=sheng.tan@9elements.com"],"Received":["from phobos.denx.de (phobos.denx.de [85.214.62.61])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SQXm33M9Pz1yQK\n\tfor ; Thu, 9 Nov 2023 04:54:43 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id C392987063;\n\tWed, 8 Nov 2023 18:54:40 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id 626B1871A2; Wed, 8 Nov 2023 18:54:39 +0100 (CET)","from mail-ej1-x634.google.com (mail-ej1-x634.google.com\n [IPv6:2a00:1450:4864:20::634])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id D958C87033\n for ; Wed, 8 Nov 2023 18:54:35 +0100 (CET)","by mail-ej1-x634.google.com with SMTP id\n a640c23a62f3a-9bf86b77a2aso2104466b.0\n for ; Wed, 08 Nov 2023 09:54:35 -0800 (PST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,\n DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,SPF_HELO_NONE,\n SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no\n version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=9elements.com; s=google; t=1699466075; x=1700070875; darn=lists.denx.de;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=Nqqqa5adV4234V9BZcAKeuou46i1inO9zoz8S9OE0AY=;\n b=L6pb2JuqUoCWx40AUe59DUooFXmQXsDAb6O4qrtMCYxUb44O60aq1mqMnxA0B5mtcu\n t96xnk6Jv8FJUkpadzrpotR1MhoP/rlN7AgZvVL1FbIpOTyEo+XSqBP7c1CwOuUM6Mdt\n q6H76wCafzfMEnUzIKUIxXXHlVKuZqeekJD7R0X3bBBovDAV5dpuACy4t7uhaBSJ9vJk\n cn7Of0TTeSon3cr1XseFCWOdJfXmyEjXZxvRI46pbpuDKPzF8U7o4zvVWdWDn6Q072OJ\n lbPk08xtMyii9SZrjQ9uW6il5PB2/D0w/YBiWJPrrbAJxt0kUYhGPMcnnYEwGnmAFlQg\n b4Mw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1699466075; x=1700070875;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=Nqqqa5adV4234V9BZcAKeuou46i1inO9zoz8S9OE0AY=;\n b=NV89WrJ5Z6dFJDJZ7qdPU6rBaX6s4lys5byFRSi4LndnophoqB2DZnm2hIwS5V4YJ1\n r/DefD7EQAhlPcMf8m5ATAxRC/SgkPgq6Ug6DUIPAbZQuY/bGDqCz9I+qBd52RPP7UZ/\n nOAmJnj5M+wWLk/6Z2OEI4xpKz8wDYSCwV9Nu4GjHMDpKhZqUuO1SBUbOhKT504qQ/R8\n PLz3oN+EV23xGWEAb3kYxrN4kl8zZ0eKQphBicD4tuoUByXq1/YP+vB3ZYJVdxtqhQmI\n IUjAlY99+wPzbvDPZGf23vdAzApb1hIUYPWX1DPi476dPS4DMONzDNku2pgt1OVAdHdv\n mneA==","X-Gm-Message-State":"AOJu0YxfwoKYWTRR98gSD7TWxBXdWkXcJ0von+omxxhqfm5zTdkBOEVB\n sg2IMHfH8PfbAmK682YsVN/1Pb+lVGzC2/b4CE/tRQ==","X-Google-Smtp-Source":"\n AGHT+IGGUaXVEC8ODzR0pAowhKTdsBLJibQJYb8KC968W8vinDdA24VdJbhNzzXdZT00mpflFzotQaBxjMrBqxZ8f7g=","X-Received":"by 2002:a17:907:b60a:b0:9e4:4f8:c42c with SMTP id\n vl10-20020a170907b60a00b009e404f8c42cmr1617327ejc.21.1699466075034; Wed, 08\n Nov 2023 09:54:35 -0800 (PST)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n \n \n \n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Lean Sheng Tan ","Date":"Wed, 8 Nov 2023 18:53:59 +0100","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Ard Biesheuvel ","Cc":"Rob Herring , Simon Glass ,\n devicetree@vger.kernel.org,\n Mark Rutland , lkml ,\n Dhaval Sharma ,\n Maximilian Brune ,\n Yunhui Cui , Guo Dong ,\n Tom Rini , ron minnich ,\n Gua Guo ,\n Chiu Chasel , linux-acpi@vger.kernel.org,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-Content-Filtered-By":"Mailman/MimeDel 2.1.39","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3215038,"web_url":"http://patchwork.ozlabs.org/comment/3215038/","msgid":"","list_archive_url":null,"date":"2023-11-10T18:20:34","subject":"RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":87524,"url":"http://patchwork.ozlabs.org/api/people/87524/","name":"Chiu, Chasel","email":"chasel.chiu@intel.com"},"content":"Just sharing some usage examples from UEFI/EDK2 scenario.\nTo support ACPI S4/Hibernation, memory map must be consistent before entering and after resuming from S4, in this case payload may need to know previous memory map from bootloader (currently generic payload cannot access platform/bootloader specific non-volatile data, thus could not save/restore memory map information)\nAnother usage is to support binary model which generic payload is a prebuilt binary compatible for all platforms/configurations, however the payload default memory map might not always work for all the configurations and we want to allow bootloader to override payload default memory map without recompiling.\n\nUnder below assumption:\n\tFDT OS impact has been evaluated and taken care by relevant experts/stakeholders.\nReviewed-by: Chasel Chiu \n\nThanks,\nChasel\n\n\n> -----Original Message-----\n> From: Simon Glass \n> Sent: Tuesday, September 26, 2023 12:43 PM\n> To: devicetree@vger.kernel.org\n> Cc: Mark Rutland ; Rob Herring ;\n> Tan, Lean Sheng ; lkml kernel@vger.kernel.org>; Dhaval Sharma ; Brune,\n> Maximilian ; Yunhui Cui\n> ; Dong, Guo ; Tom Rini\n> ; ron minnich ; Guo, Gua\n> ; Chiu, Chasel ; linux-\n> acpi@vger.kernel.org; U-Boot Mailing List ; Ard\n> Biesheuvel ; Simon Glass \n> Subject: [PATCH v7 2/2] schemas: Add some common reserved-memory usages\n> \n> It is common to split firmware into 'Platform Init', which does the initial hardware\n> setup and a \"Payload\" which selects the OS to be booted.\n> Thus an handover interface is required between these two pieces.\n> \n> Where UEFI boot-time services are not available, but UEFI firmware is present on\n> either side of this interface, information about memory usage and attributes must\n> be presented to the \"Payload\" in some form.\n> \n> This aims to provide an small schema addition for the memory mapping needed\n> to keep these two pieces working together well.\n> \n> Signed-off-by: Simon Glass \n> ---\n> \n> Changes in v7:\n> - Rename acpi-reclaim to acpi\n> - Drop individual mention of when memory can be reclaimed\n> - Rewrite the item descriptions\n> - Add back the UEFI text (with trepidation)\n> \n> Changes in v6:\n> - Drop mention of UEFI\n> - Use compatible strings instead of node names\n> \n> Changes in v5:\n> - Drop the memory-map node (should have done that in v4)\n> - Tidy up schema a bit\n> \n> Changes in v4:\n> - Make use of the reserved-memory node instead of creating a new one\n> \n> Changes in v3:\n> - Reword commit message again\n> - cc a lot more people, from the FFI patch\n> - Split out the attributes into the /memory nodes\n> \n> Changes in v2:\n> - Reword commit message\n> \n> .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> 1 file changed, 71 insertions(+)\n> create mode 100644 dtschema/schemas/reserved-memory/common-\n> reserved.yaml\n> \n> diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml\n> b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> new file mode 100644\n> index 0000000..f7fbdfd\n> --- /dev/null\n> +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> @@ -0,0 +1,71 @@\n> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2\n> +---\n> +$id:\n> +http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> +\n> +title: Common memory reservations\n> +\n> +description: |\n> + Specifies that the reserved memory region can be used for the purpose\n> + indicated by its compatible string.\n> +\n> + Clients may reuse this reserved memory if they understand what it is\n> + for, subject to the notes below.\n> +\n> +maintainers:\n> + - Simon Glass \n> +\n> +allOf:\n> + - $ref: reserved-memory.yaml\n> +\n> +properties:\n> + compatible:\n> + description: |\n> + This describes some common memory reservations, with the compatible\n> + string indicating what it is used for:\n> +\n> + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> + the firmware for its use and is required to be saved and restored\n> + across an NVS sleep\n> + boot-code: Contains code used for booting which is not needed by the OS\n> + boot-code: Contains data used for booting which is not needed by the OS\n> + runtime-code: Contains code used for interacting with the system when\n> + running the OS\n> + runtime-data: Contains data used for interacting with the system when\n> + running the OS\n> +\n> + enum:\n> + - acpi\n> + - acpi-nvs\n> + - boot-code\n> + - boot-data\n> + - runtime-code\n> + - runtime-data\n> +\n> + reg:\n> + description: region of memory that is reserved for the purpose indicated\n> + by the compatible string.\n> +\n> +required:\n> + - reg\n> +\n> +unevaluatedProperties: false\n> +\n> +examples:\n> + - |\n> + reserved-memory {\n> + #address-cells = <1>;\n> + #size-cells = <1>;\n> +\n> + reserved@12340000 {\n> + compatible = \"boot-code\";\n> + reg = <0x12340000 0x00800000>;\n> + };\n> +\n> + reserved@43210000 {\n> + compatible = \"boot-data\";\n> + reg = <0x43210000 0x00800000>;\n> + };\n> + };\n> --\n> 2.42.0.515.g380fc7ccd1-goog","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=DVQyZIQu;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.b=\"DVQyZIQu\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=chasel.chiu@intel.com","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=intel.com;"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SRnPN1Xx0z1yQl\n\tfor ; Sat, 11 Nov 2023 05:27:52 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id B22EF877D8;\n\tFri, 10 Nov 2023 19:27:47 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id 2C8C48782E; Fri, 10 Nov 2023 19:20:45 +0100 (CET)","from mgamail.intel.com (mgamail.intel.com [198.175.65.9])\n (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id A65C7874B7\n for ; Fri, 10 Nov 2023 19:20:41 +0100 (CET)","from fmsmga005.fm.intel.com ([10.253.24.32])\n by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 10 Nov 2023 10:20:41 -0800","from fmsmsx601.amr.corp.intel.com ([10.18.126.81])\n by fmsmga005.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384;\n 10 Nov 2023 10:20:39 -0800","from fmsmsx610.amr.corp.intel.com (10.18.126.90) by\n fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.2507.34; Fri, 10 Nov 2023 10:20:38 -0800","from fmsedg601.ED.cps.intel.com (10.1.192.135) by\n fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.2507.34 via Frontend Transport; Fri, 10 Nov 2023 10:20:38 -0800","from NAM02-BN1-obe.outbound.protection.outlook.com (104.47.51.41) by\n edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.1.2507.34; Fri, 10 Nov 2023 10:20:38 -0800","from BN9PR11MB5483.namprd11.prod.outlook.com (2603:10b6:408:104::10)\n by MN0PR11MB6135.namprd11.prod.outlook.com (2603:10b6:208:3c9::9)\n with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.25; Fri, 10 Nov\n 2023 18:20:35 +0000","from BN9PR11MB5483.namprd11.prod.outlook.com\n ([fe80::6da1:a4b7:4771:14e1]) by BN9PR11MB5483.namprd11.prod.outlook.com\n ([fe80::6da1:a4b7:4771:14e1%4]) with mapi id 15.20.6977.019; Fri, 10 Nov 2023\n 18:20:35 +0000"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no\n version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1699640443; x=1731176443;\n h=from:to:cc:subject:date:message-id:references:\n in-reply-to:content-transfer-encoding:mime-version;\n bh=qbQcOvG6du6rbdGEsMBcqhw/2eRXDmjj8fePltbf4gA=;\n b=DVQyZIQuvcCfub2rWy+XxmmqVUTnaPXCjR5c5pQiTjGAxo9pccM++gaV\n fbgFRykumkEyW8SALaw6nUAJnp143pi3u7MHNbUl3hijnRq6htNpMLHcj\n ZgY0yGCl2sxIpyfzAOT0KMN20pyRCcqwzKjZuS2UAzi/UgeVkGvfORUUl\n lyre2sFzvivLkaPeTsyoXbIVSQnWT+6YjIMOMSqj8Qra6XFscWD3T1h2N\n jSqIml7OeD5WsS/zNzyjFSRkbzwnbuuUyrblp9/D5kAXHJithQyAz+khH\n tj60wHfT7P4nGVfHWr+QoJd9naZeEBsYcHHS8SkyiEdoxc0suvUxCjfd2 w==;","X-IronPort-AV":["E=McAfee;i=\"6600,9927,10890\"; a=\"8868030\"","E=Sophos;i=\"6.03,291,1694761200\";\n d=\"scan'208\";a=\"8868030\"","E=McAfee;i=\"6600,9927,10890\"; a=\"1095242974\"","E=Sophos;i=\"6.03,291,1694761200\"; d=\"scan'208\";a=\"1095242974\""],"X-ExtLoop1":"1","ARC-Seal":"i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=ZbfsivO1pIoXBMP4837SXdryIWdWbnlHagd1K5UFgDrNbWqt6yoeYNdksf+StJS0/ZF/tMABhdTyxV0P5Rw6VXQgZHNtWOgfmJMlDAynKkszTD0FGhH4s5/uUn4x4MvbLFCifkzrPWM5L6AFcjxlH2Rvmo9TM636Aok22Dpkqdw7PIyg2Y1H+aKj3usbSCEFP2vreF6WZcEuwLFy4O/BFxRNaqtc787JYs1qpfJSv+/Y9X6FC0dWTsT8U6igfiOmlBQJQPKulscG4wqXywJXJQa7Vxbi8UYg2miHMxGpZ+3GOEPeocT/8H45JdeDmkPfhHyYB3I8ZsTCGGRsCMUw+w==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;\n bh=MBf4+jhg5MiwE5dfgQbxja+JLMyW1PBMvsr2S97FG2o=;\n b=bY100qVjrW7Wa+qlWPopfP3XtQDu0SqHAy37V6pj8nFv/yl273fqfAUU3pK393UjECaIYes9qfiTaFQt/r5nXoNzhY7Q6Z23/9dzLhC/wRW1iFj1MxuY3s9F4HDU8p+5ReV7FhzoQgTEixOjYadxnpe4d2rd3jcUiaS3SRcYclIkC/6RRuAow+B7eA/xhx0k/DV3q4Od0/HDt0EL+2577/yDeSnrQan8sGEz1wH5NflCrH3kteGcK1GXn7vmWRlUyUnV9JP+OWGKJt1XZIWVt3Z3Rupme2Es6HHi78EM9eW2l4AA6cf079wiQES7tZ9WqjA4RRxEIjOmJaYvnwVngg==","ARC-Authentication-Results":"i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none","From":"\"Chiu, Chasel\" ","To":"Simon Glass , \"devicetree@vger.kernel.org\"\n ","CC":"Mark Rutland , Rob Herring , \"Tan,\n Lean Sheng\" , lkml ,\n Dhaval Sharma , \"Brune, Maximilian\"\n , Yunhui Cui ,\n \"Dong, Guo\" , Tom Rini , ron minnich\n , \"Guo, Gua\" ,\n \"linux-acpi@vger.kernel.org\" , \"U-Boot Mailing\n List\" , Ard Biesheuvel , \"Chiu,\n Chasel\" ","Subject":"RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","Thread-Topic":"[PATCH v7 2/2] schemas: Add some common reserved-memory usages","Thread-Index":"AQHZ8LGvpttG6mvEz0WlU57NBrVnTbB0GT1w","Date":"Fri, 10 Nov 2023 18:20:34 +0000","Message-ID":"\n ","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>","In-Reply-To":"<20230926194242.2732127-2-sjg@chromium.org>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","authentication-results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=DVQyZIQu;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.b=\"DVQyZIQu\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=chasel.chiu@intel.com","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=intel.com;"],"x-ms-publictraffictype":"Email","x-ms-traffictypediagnostic":"BN9PR11MB5483:EE_|MN0PR11MB6135:EE_","x-ms-office365-filtering-correlation-id":"aa3f4fee-8ef4-4ab8-7db0-08dbe219bb1c","x-ld-processed":"46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr","x-ms-exchange-senderadcheck":"1","x-ms-exchange-antispam-relay":"0","x-microsoft-antispam":"BCL:0;","x-microsoft-antispam-message-info":"\n 99WWrKQlkV+LGcBF+clpRsSpTf79OtvxNVlzC+Uxjt9wktGaLZT3154BgDrcjnTYjo7imoQbv6z6RqZXcqaCgqMWRn/wQVtBjqTLTi5oN5xDUv5Om7HsM5q8fNG2KmvL0THV4z2+3LehYVknZHA9i7++l8oWi5hnnA8+d4C2DC7agW6DNzlgixrea3nmdqd58WeuUkygF7qB08LDWLeQW1tOOKQ3lsHY/uQzREU6t1kUjgUCsWkqUwo1f5anYvDl4sYOjWx1AT4oni8cjZAT1V5xwELGF9r/y1GhB8OglHCoO7AZ+CjdVweqrIsIPsKwtbHQO0CRn4UwPVjbYs6dlDH9jKVGqHkWTTXdiP9tvAytS+hvbchkfTueHkjfMfaRscK/sJkZDv/tkSiDv2yx6Xc4KY/IdIZi4mfokyST50sWaQZK7/cHcF2jSsUxsxBKoVeyP6qHHJktX/goA5658JDhL7N4HXF9NL6/izJ3nwSAp8RUDhLaVJMK/45g09miOoRTFlP186zgMNFsa1NpyHaotWmK83Ndf4FCangiqptGRpWJdMBLFMTtc66SQfkS+kQ+PuWkhq2ygw1iobABm+tsigiEirjgTqchhnzbDC0=","x-forefront-antispam-report":"CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:BN9PR11MB5483.namprd11.prod.outlook.com; PTR:; CAT:NONE;\n SFS:(13230031)(39860400002)(346002)(376002)(366004)(396003)(136003)(230922051799003)(451199024)(1800799009)(64100799003)(186009)(8676002)(2906002)(7416002)(4326008)(5660300002)(55016003)(966005)(9686003)(122000001)(76116006)(86362001)(66446008)(316002)(71200400001)(54906003)(66476007)(66556008)(26005)(64756008)(33656002)(66946007)(110136005)(82960400001)(478600001)(6506007)(38100700002)(107886003)(7696005)(53546011)(52536014)(41300700001)(38070700009)(83380400001)(8936002);\n DIR:OUT; SFP:1102;","x-ms-exchange-antispam-messagedata-chunkcount":"1","x-ms-exchange-antispam-messagedata-0":"\n b8Q641gmCJlMn7VweMmTWI0lTSjNOvb8MyY+PrGQ0ZUVVt6Mo+gGNFseubhAYp0d0C7f6SlyXWxA5rTQfpiytjKFIiEppUY6HwILJRJ3l3a/0OxQRXqLCguTPP/cLrf1mQV7WAKKG92hZ6LKmoF44K9EIR56N1ZRjrgR9dCWfNBJnR9gCBGIafzY1EttrD/jZCYRT/yatSzWYkxc6nesKCxPyHCcIFJBazkGztdhkEi8xJRN+lUkAa2kh9TAU6eYwcmz5CPtJvGd/ZPZ4TvIm0eYcprWenIkUealPL9MOjxLrdliaU7diuTq4sqSu+7dzYIYnMESYHxpkqyOILJgfTu+Urblc+F1/ym8LV3yzHwJLN28undaONPLXEsrBwWFpEShSkygq410a4WQweJZeYsyevpm+q0iKDAmks06KYhMqLZQXqlq4dWoCGrw8XmbV+s9+a5os2/UshEWKwOXhr6+hbP4H+YDZx/+qochTVghl6B6qkZ9NZn4nfFiaQITDVx0NtgMz/6RXTAVOsF25xzK5tYcLJVAcEjWPvdYhWmkraqOHQWMEb/i6I/DS/BRtHerTxCJJYUKQnkvq2bEwFlZ9pzMrV5YCJOdz4jxMi2CPefzULueltBRsUMpxFsEzX1wyOuz0MjJDcKeF7i5h2+WUIWq5AULaVN5yWCJX7dxDrvEtHf6qghaSPzenHBeGZ81g9MweNTXO0L1WtyhSFgz0XIt10cV5LCnVbuvEnKuQsFAP/wRkiKUlYLdZMHD0DnFmpKrKicTTlArc1o4nUzTfvOKDolFieVfZQdd3CWrsBA/TFFuPkxOj8ABaavzHIjHtx0En8HJjDZxjDlP4M3h2nvthIfM8yqwclqtv38TsyCWe6yinUYp3PPSm7dIQAaCeqX7rZ51PMFYpDVFi4biLnEFlrFe8rmKcmKLGxmx83wCwxrxg/qsTTVvGumOXr88x/1XXihS2v18zArjCobnF/vxxS154ViUlN+PJdMFzkTLz7Ir83W03jMcjOTpoX1YSCJqBg9IesBo4rmnUB/qPUfTaBfBaVWdjfQXtcAzS+tBx0c3fgfXKdAZdLnxk5Je0kMjrJKzYv+t6E8JCav5gAeP3AL1iJpeOq69yww7bnfL7BOgMD+bTdRCKxbg6gHZ9aReXVakhXRzWLxBB1weZiD81O0SiL1UrNjIj+bvZXVBl0cMnwC/b1EIffJHsSunB5iPoUgZFmSshqp9L8Mp/K/muEfztj5+0NO9Ukibm/ZKUN19KY2qf8oRI0GuRRRY4XV3M3D6RtAkGkRDPeje9WdrtU6NfVsvaJOo11h21ZqZg42TTY1HRIU1Wbecv3dnJ0fc0ROHdO3j+dTiUyHsjVTTXAwBh3oWYeoPNpaa7z7cyuPc420YwwOV0d8j0oQngd4yjkD408royOR1vFcei3O2jJ7lew0K0LcTiJDWvosOL4YxQ/+jjkQ+dgk+TVLQ4qNngoZxzHKrMKlMr6Kt8KYGlorwBkB6wsCQnIuzbb56jtm5lyKtQl/myd+roqg4az25bgtUE/me8pTCA6ZkFUna2Pextr8s8c4HIA6+I/aQLMv+1yWV29UlStCV","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"quoted-printable","MIME-Version":"1.0","X-MS-Exchange-CrossTenant-AuthAs":"Internal","X-MS-Exchange-CrossTenant-AuthSource":"BN9PR11MB5483.namprd11.prod.outlook.com","X-MS-Exchange-CrossTenant-Network-Message-Id":"\n aa3f4fee-8ef4-4ab8-7db0-08dbe219bb1c","X-MS-Exchange-CrossTenant-originalarrivaltime":"10 Nov 2023 18:20:34.4034 (UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"46c98d88-e344-4ed4-8496-4ed7712e255d","X-MS-Exchange-CrossTenant-mailboxtype":"HOSTED","X-MS-Exchange-CrossTenant-userprincipalname":"\n dBKSPdh+ZadnY7Q341XcCYMg7xm9bNgUospFem9C1i85KfcVHfK0ffhKHlCRCY1mplBzp0MAG+ecc98LzLUiEA==","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"MN0PR11MB6135","X-OriginatorOrg":"intel.com","X-Mailman-Approved-At":"Fri, 10 Nov 2023 19:27:46 +0100","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3215299,"web_url":"http://patchwork.ozlabs.org/comment/3215299/","msgid":"","list_archive_url":null,"date":"2023-11-11T11:03:46","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":77831,"url":"http://patchwork.ozlabs.org/api/people/77831/","name":"Ard Biesheuvel","email":"ardb@kernel.org"},"content":"On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel wrote:\n>\n>\n> Just sharing some usage examples from UEFI/EDK2 scenario.\n> To support ACPI S4/Hibernation, memory map must be consistent before entering and after resuming from S4, in this case payload may need to know previous memory map from bootloader (currently generic payload cannot access platform/bootloader specific non-volatile data, thus could not save/restore memory map information)\n\nSo how would EDK2 reconstruct the entire EFI memory map from just\nthese unannotated /reserved-memory nodes? The EFI memory map contains\nmuch more information than that, and all of it has to match the\npre-hibernate situation, right? Can you given an example?\n\n> Another usage is to support binary model which generic payload is a prebuilt binary compatible for all platforms/configurations, however the payload default memory map might not always work for all the configurations and we want to allow bootloader to override payload default memory map without recompiling.\n>\n\nAgreed. But can you explain how a EDK2 payload might make meaningful\nuse of 'runtime-code' regions provided via DT by the non-EDK2\nplatform init? Can you give an example?\n\n> Under below assumption:\n> FDT OS impact has been evaluated and taken care by relevant experts/stakeholders.\n> Reviewed-by: Chasel Chiu \n>\n\nI am sorry but I don't know what 'FDT OS impact' means. We are talking\nabout a firmware-to-firmware abstraction that has the potential to\nleak into the OS visible interface.\n\nI am a maintainer in the Tianocore project myself, so it would help if\nyou could explain who these relevant experts and stakeholders are. Was\nthis discussed on the edk2-devel mailing list? If so, apologies for\nmissing it but I may not have been cc'ed perhaps?\n\n\n>\n> > -----Original Message-----\n> > From: Simon Glass \n> > Sent: Tuesday, September 26, 2023 12:43 PM\n> > To: devicetree@vger.kernel.org\n> > Cc: Mark Rutland ; Rob Herring ;\n> > Tan, Lean Sheng ; lkml > kernel@vger.kernel.org>; Dhaval Sharma ; Brune,\n> > Maximilian ; Yunhui Cui\n> > ; Dong, Guo ; Tom Rini\n> > ; ron minnich ; Guo, Gua\n> > ; Chiu, Chasel ; linux-\n> > acpi@vger.kernel.org; U-Boot Mailing List ; Ard\n> > Biesheuvel ; Simon Glass \n> > Subject: [PATCH v7 2/2] schemas: Add some common reserved-memory usages\n> >\n> > It is common to split firmware into 'Platform Init', which does the initial hardware\n> > setup and a \"Payload\" which selects the OS to be booted.\n> > Thus an handover interface is required between these two pieces.\n> >\n> > Where UEFI boot-time services are not available, but UEFI firmware is present on\n> > either side of this interface, information about memory usage and attributes must\n> > be presented to the \"Payload\" in some form.\n> >\n> > This aims to provide an small schema addition for the memory mapping needed\n> > to keep these two pieces working together well.\n> >\n> > Signed-off-by: Simon Glass \n> > ---\n> >\n> > Changes in v7:\n> > - Rename acpi-reclaim to acpi\n> > - Drop individual mention of when memory can be reclaimed\n> > - Rewrite the item descriptions\n> > - Add back the UEFI text (with trepidation)\n> >\n> > Changes in v6:\n> > - Drop mention of UEFI\n> > - Use compatible strings instead of node names\n> >\n> > Changes in v5:\n> > - Drop the memory-map node (should have done that in v4)\n> > - Tidy up schema a bit\n> >\n> > Changes in v4:\n> > - Make use of the reserved-memory node instead of creating a new one\n> >\n> > Changes in v3:\n> > - Reword commit message again\n> > - cc a lot more people, from the FFI patch\n> > - Split out the attributes into the /memory nodes\n> >\n> > Changes in v2:\n> > - Reword commit message\n> >\n> > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > 1 file changed, 71 insertions(+)\n> > create mode 100644 dtschema/schemas/reserved-memory/common-\n> > reserved.yaml\n> >\n> > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > new file mode 100644\n> > index 0000000..f7fbdfd\n> > --- /dev/null\n> > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > @@ -0,0 +1,71 @@\n> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2\n> > +---\n> > +$id:\n> > +http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > +\n> > +title: Common memory reservations\n> > +\n> > +description: |\n> > + Specifies that the reserved memory region can be used for the purpose\n> > + indicated by its compatible string.\n> > +\n> > + Clients may reuse this reserved memory if they understand what it is\n> > + for, subject to the notes below.\n> > +\n> > +maintainers:\n> > + - Simon Glass \n> > +\n> > +allOf:\n> > + - $ref: reserved-memory.yaml\n> > +\n> > +properties:\n> > + compatible:\n> > + description: |\n> > + This describes some common memory reservations, with the compatible\n> > + string indicating what it is used for:\n> > +\n> > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > + the firmware for its use and is required to be saved and restored\n> > + across an NVS sleep\n> > + boot-code: Contains code used for booting which is not needed by the OS\n> > + boot-code: Contains data used for booting which is not needed by the OS\n> > + runtime-code: Contains code used for interacting with the system when\n> > + running the OS\n> > + runtime-data: Contains data used for interacting with the system when\n> > + running the OS\n> > +\n> > + enum:\n> > + - acpi\n> > + - acpi-nvs\n> > + - boot-code\n> > + - boot-data\n> > + - runtime-code\n> > + - runtime-data\n> > +\n> > + reg:\n> > + description: region of memory that is reserved for the purpose indicated\n> > + by the compatible string.\n> > +\n> > +required:\n> > + - reg\n> > +\n> > +unevaluatedProperties: false\n> > +\n> > +examples:\n> > + - |\n> > + reserved-memory {\n> > + #address-cells = <1>;\n> > + #size-cells = <1>;\n> > +\n> > + reserved@12340000 {\n> > + compatible = \"boot-code\";\n> > + reg = <0x12340000 0x00800000>;\n> > + };\n> > +\n> > + reserved@43210000 {\n> > + compatible = \"boot-data\";\n> > + reg = <0x43210000 0x00800000>;\n> > + };\n> > + };\n> > --\n> > 2.42.0.515.g380fc7ccd1-goog\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=Sf58H/Ma;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.b=\"Sf58H/Ma\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de; spf=pass smtp.mailfrom=ardb@kernel.org"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SSCW11vW6z1yRV\n\tfor ; Sat, 11 Nov 2023 22:04:13 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 1238B86F5E;\n\tSat, 11 Nov 2023 12:04:08 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id 0A7F486F7C; Sat, 11 Nov 2023 12:04:07 +0100 (CET)","from sin.source.kernel.org (sin.source.kernel.org\n [IPv6:2604:1380:40e1:4800::1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 6837586F6C\n for ; Sat, 11 Nov 2023 12:04:03 +0100 (CET)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by sin.source.kernel.org (Postfix) with ESMTP id 7B140CE1736\n for ; Sat, 11 Nov 2023 11:04:00 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id B3ADDC433C7\n for ; Sat, 11 Nov 2023 11:03:59 +0000 (UTC)","by mail-lj1-f170.google.com with SMTP id\n 38308e7fff4ca-2c54c8934abso38962381fa.0\n for ; Sat, 11 Nov 2023 03:03:59 -0800 (PST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no\n version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1699700639;\n bh=/mCsRpoHNfIXUNMQCkSkO7WIeDaCJXswf/0MS4Qqxww=;\n h=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n b=Sf58H/MaoBZZ/xOFYMzMRrDPETrlRGADgg4vjWHg/ITAxvutAcyCvu+JGVVVkGyaS\n ti58qyVGv+BAsyknYmxe/7jI039fP1ZpI/suSu3zL6wVmkNVwes2jeUAEGrHWFx1ib\n rgjLH/72RIDg9yUuqjZI93NbJhYZi6c6iTCHHDirFY19X1+5tTYARa8LYttRNTrsk7\n 8dOhRd4KqOluueV3UKwtSMFAeQBKai+bfZXRwCZqlQY3QKUChI9QrK9DcweFKDbpOs\n cfSO7BOs3SZIHFrgYDZ3icrpZEkJiMS/lqyiFwCVaepza6GKFG1jmsYUfa20kSCEbC\n 0ieyYH2g6iKYA==","X-Gm-Message-State":"AOJu0YwZX5sLkqfUaVV/WdEYw50CF2hlvin249gomqTLuUyVcaGsmVIM\n FVlFz2D6eJKk5uNBR138vzEP0anDIwNkBpoasyo=","X-Google-Smtp-Source":"\n AGHT+IHwnbe1LHcOvdw6D1LpdnWzFdtyWX7I2RFO0IU/Kq2EYq5LOp7rs1R+FvsDd3/9FmKKqRkcUXf0D53RTQwLbzE=","X-Received":"by 2002:a2e:9898:0:b0:2c5:19f2:4fde with SMTP id\n b24-20020a2e9898000000b002c519f24fdemr1156839ljj.23.1699700637978; Sat, 11\n Nov 2023 03:03:57 -0800 (PST)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n ","In-Reply-To":"\n ","From":"Ard Biesheuvel ","Date":"Sat, 11 Nov 2023 21:03:46 +1000","X-Gmail-Original-Message-ID":"\n ","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"\"Chiu, Chasel\" ","Cc":"Simon Glass ,\n \"devicetree@vger.kernel.org\" ,\n Mark Rutland ,\n Rob Herring , \"Tan, Lean Sheng\" ,\n lkml , Dhaval Sharma ,\n \"Brune, Maximilian\" ,\n Yunhui Cui ,\n \"Dong, Guo\" , Tom Rini ,\n ron minnich , \"Guo, Gua\" ,\n \"linux-acpi@vger.kernel.org\" ,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3216114,"web_url":"http://patchwork.ozlabs.org/comment/3216114/","msgid":"","list_archive_url":null,"date":"2023-11-13T18:09:05","subject":"RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":87524,"url":"http://patchwork.ozlabs.org/api/people/87524/","name":"Chiu, Chasel","email":"chasel.chiu@intel.com"},"content":"Hi Ard,\n\nPlease see my reply below inline.\n\nThanks,\nChasel\n\n\n> -----Original Message-----\n> From: Ard Biesheuvel \n> Sent: Saturday, November 11, 2023 3:04 AM\n> To: Chiu, Chasel \n> Cc: Simon Glass ; devicetree@vger.kernel.org; Mark Rutland\n> ; Rob Herring ; Tan, Lean Sheng\n> ; lkml ; Dhaval\n> Sharma ; Brune, Maximilian\n> ; Yunhui Cui ;\n> Dong, Guo ; Tom Rini ; ron minnich\n> ; Guo, Gua ; linux-\n> acpi@vger.kernel.org; U-Boot Mailing List \n> Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> usages\n> \n> On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel wrote:\n> >\n> >\n> > Just sharing some usage examples from UEFI/EDK2 scenario.\n> > To support ACPI S4/Hibernation, memory map must be consistent before\n> > entering and after resuming from S4, in this case payload may need to\n> > know previous memory map from bootloader (currently generic payload\n> > cannot access platform/bootloader specific non-volatile data, thus\n> > could not save/restore memory map information)\n> \n> So how would EDK2 reconstruct the entire EFI memory map from just these\n> unannotated /reserved-memory nodes? The EFI memory map contains much\n> more information than that, and all of it has to match the pre-hibernate situation,\n> right? Can you given an example?\n\n\nHere we listed only typically memory types that may change cross different platforms.\nReserved memory type already can be handled by reserved-memory node, and rest of the types usually no need to change cross platforms thus currently we could rely on default in generic payload.\nIn the future if we see a need to add new memory types we will discuss and add it to FDT schema.\n\n\n\n> \n> > Another usage is to support binary model which generic payload is a prebuilt\n> binary compatible for all platforms/configurations, however the payload default\n> memory map might not always work for all the configurations and we want to\n> allow bootloader to override payload default memory map without recompiling.\n> >\n> \n> Agreed. But can you explain how a EDK2 payload might make meaningful use of\n> 'runtime-code' regions provided via DT by the non-EDK2 platform init? Can you\n> give an example?\n\n\nRuntime-code/data is used by UEFI payload for booting UEFI OS which required UEFI runtime services.\nPlatform Init will select some regions from the usable memory and assign it to runtime-code/data for UPL to consume. Or assign same runtime-code/data from previous boot.\nIf UEFI OS is not supported, PlatformInit may not need to provide runtime-code/data regions to payload. (always providing runtime-code/data should be supported too)\n\n\n> \n> > Under below assumption:\n> > FDT OS impact has been evaluated and taken care by relevant\n> experts/stakeholders.\n> > Reviewed-by: Chasel Chiu \n> >\n> \n> I am sorry but I don't know what 'FDT OS impact' means. We are talking about a\n> firmware-to-firmware abstraction that has the potential to leak into the OS\n> visible interface.\n> \n> I am a maintainer in the Tianocore project myself, so it would help if you could\n> explain who these relevant experts and stakeholders are. Was this discussed on\n> the edk2-devel mailing list? If so, apologies for missing it but I may not have been\n> cc'ed perhaps?\n\n\n\n\nI'm not familiar with FDT OS, also I do not know if who from edk2-devel were supporting FDT OS, I think Simon might be able to connect FDT OS experts/stakeholders.\nWe are mostly focusing on payload firmware phase implementation in edk2 (and other payloads too), however, since we have aligned the payload FDT and OS FDT months ago, I'm assuming FDT OS impact must be there and we need (or already done?) FDT OS experts to support it. (again, maybe Simon could share more information about FDT OS) \n\nIn edk2 such FDT schema is UefiPayloadPkg internal usage only and payload entry will convert FDT into HOB thus we expected the most of the edk2 generic code are no-touch/no impact, that's why we only had small group (UefiPayloadPkg) discussion.\nArd, if you are aware of any edk2 code that's for supporting FDT OS, please let us know and we can discuss if those code were impacted or not.\n\n\n\n\n> \n> \n> >\n> > > -----Original Message-----\n> > > From: Simon Glass \n> > > Sent: Tuesday, September 26, 2023 12:43 PM\n> > > To: devicetree@vger.kernel.org\n> > > Cc: Mark Rutland ; Rob Herring\n> > > ; Tan, Lean Sheng ; lkml\n> > > ; Dhaval Sharma\n> > > ; Brune, Maximilian\n> > > ; Yunhui Cui\n> > > ; Dong, Guo ; Tom Rini\n> > > ; ron minnich ; Guo, Gua\n> > > ; Chiu, Chasel ; linux-\n> > > acpi@vger.kernel.org; U-Boot Mailing List ;\n> > > Ard Biesheuvel ; Simon Glass \n> > > Subject: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> > > usages\n> > >\n> > > It is common to split firmware into 'Platform Init', which does the\n> > > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > > Thus an handover interface is required between these two pieces.\n> > >\n> > > Where UEFI boot-time services are not available, but UEFI firmware\n> > > is present on either side of this interface, information about\n> > > memory usage and attributes must be presented to the \"Payload\" in some\n> form.\n> > >\n> > > This aims to provide an small schema addition for the memory mapping\n> > > needed to keep these two pieces working together well.\n> > >\n> > > Signed-off-by: Simon Glass \n> > > ---\n> > >\n> > > Changes in v7:\n> > > - Rename acpi-reclaim to acpi\n> > > - Drop individual mention of when memory can be reclaimed\n> > > - Rewrite the item descriptions\n> > > - Add back the UEFI text (with trepidation)\n> > >\n> > > Changes in v6:\n> > > - Drop mention of UEFI\n> > > - Use compatible strings instead of node names\n> > >\n> > > Changes in v5:\n> > > - Drop the memory-map node (should have done that in v4)\n> > > - Tidy up schema a bit\n> > >\n> > > Changes in v4:\n> > > - Make use of the reserved-memory node instead of creating a new one\n> > >\n> > > Changes in v3:\n> > > - Reword commit message again\n> > > - cc a lot more people, from the FFI patch\n> > > - Split out the attributes into the /memory nodes\n> > >\n> > > Changes in v2:\n> > > - Reword commit message\n> > >\n> > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > > 1 file changed, 71 insertions(+)\n> > > create mode 100644 dtschema/schemas/reserved-memory/common-\n> > > reserved.yaml\n> > >\n> > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > new file mode 100644\n> > > index 0000000..f7fbdfd\n> > > --- /dev/null\n> > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > @@ -0,0 +1,71 @@\n> > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2\n> > > +---\n> > > +$id:\n> > > +http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > > +\n> > > +title: Common memory reservations\n> > > +\n> > > +description: |\n> > > + Specifies that the reserved memory region can be used for the\n> > > +purpose\n> > > + indicated by its compatible string.\n> > > +\n> > > + Clients may reuse this reserved memory if they understand what it\n> > > + is for, subject to the notes below.\n> > > +\n> > > +maintainers:\n> > > + - Simon Glass \n> > > +\n> > > +allOf:\n> > > + - $ref: reserved-memory.yaml\n> > > +\n> > > +properties:\n> > > + compatible:\n> > > + description: |\n> > > + This describes some common memory reservations, with the compatible\n> > > + string indicating what it is used for:\n> > > +\n> > > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > > + the firmware for its use and is required to be saved and restored\n> > > + across an NVS sleep\n> > > + boot-code: Contains code used for booting which is not needed by the\n> OS\n> > > + boot-code: Contains data used for booting which is not needed by the\n> OS\n> > > + runtime-code: Contains code used for interacting with the system when\n> > > + running the OS\n> > > + runtime-data: Contains data used for interacting with the system when\n> > > + running the OS\n> > > +\n> > > + enum:\n> > > + - acpi\n> > > + - acpi-nvs\n> > > + - boot-code\n> > > + - boot-data\n> > > + - runtime-code\n> > > + - runtime-data\n> > > +\n> > > + reg:\n> > > + description: region of memory that is reserved for the purpose indicated\n> > > + by the compatible string.\n> > > +\n> > > +required:\n> > > + - reg\n> > > +\n> > > +unevaluatedProperties: false\n> > > +\n> > > +examples:\n> > > + - |\n> > > + reserved-memory {\n> > > + #address-cells = <1>;\n> > > + #size-cells = <1>;\n> > > +\n> > > + reserved@12340000 {\n> > > + compatible = \"boot-code\";\n> > > + reg = <0x12340000 0x00800000>;\n> > > + };\n> > > +\n> > > + reserved@43210000 {\n> > > + compatible = \"boot-data\";\n> > > + reg = <0x43210000 0x00800000>;\n> > > + };\n> > > + };\n> > > --\n> > > 2.42.0.515.g380fc7ccd1-goog\n> >","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=ZuozXitP;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.b=\"ZuozXitP\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=chasel.chiu@intel.com","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=intel.com;"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4STdG26N94z1yRX\n\tfor ; Tue, 14 Nov 2023 05:27:54 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id ECDF786D3F;\n\tMon, 13 Nov 2023 19:27:51 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id 014A986611; Mon, 13 Nov 2023 19:09:41 +0100 (CET)","from mgamail.intel.com (mgamail.intel.com [134.134.136.126])\n (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 0C6DC8714E\n for ; Mon, 13 Nov 2023 19:09:36 +0100 (CET)","from fmviesa001.fm.intel.com ([10.60.135.141])\n by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 13 Nov 2023 10:09:33 -0800","from orsmsx603.amr.corp.intel.com ([10.22.229.16])\n by fmviesa001.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384;\n 13 Nov 2023 10:09:20 -0800","from orsmsx611.amr.corp.intel.com (10.22.229.24) by\n ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.2507.34; Mon, 13 Nov 2023 10:09:18 -0800","from orsmsx610.amr.corp.intel.com (10.22.229.23) by\n ORSMSX611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.2507.34; Mon, 13 Nov 2023 10:09:16 -0800","from orsedg603.ED.cps.intel.com (10.7.248.4) by\n orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.2507.34 via Frontend Transport; Mon, 13 Nov 2023 10:09:16 -0800","from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.168)\n by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.1.2507.34; Mon, 13 Nov 2023 10:09:15 -0800","from BN9PR11MB5483.namprd11.prod.outlook.com (2603:10b6:408:104::10)\n by PH7PR11MB7593.namprd11.prod.outlook.com (2603:10b6:510:27f::9)\n with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6977.26; Mon, 13 Nov\n 2023 18:09:06 +0000","from BN9PR11MB5483.namprd11.prod.outlook.com\n ([fe80::6da1:a4b7:4771:14e1]) by BN9PR11MB5483.namprd11.prod.outlook.com\n ([fe80::6da1:a4b7:4771:14e1%4]) with mapi id 15.20.6977.029; Mon, 13 Nov 2023\n 18:09:05 +0000"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no\n version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1699898977; x=1731434977;\n h=from:to:cc:subject:date:message-id:references:\n in-reply-to:content-transfer-encoding:mime-version;\n bh=oCPqqTuyXU7hHqvttl9FSkvlJFyayzeXXdrZNPAkKjY=;\n b=ZuozXitPBKvFOtIbsYy/qDePJsvpm3YYqA2QisFBSnkbtZ5yrKh6P/ps\n rli51guF0HZtY0VBLli1H1EjekV3ZqXlAl0sTmQUq6FBSqX1gvAXUYalQ\n lR8TIAxHHl1+Sf4aYIIT4zDqME5W448KKc8oQoav+Vp7liN7eQZbILfDo\n iDPKR6Z86+g4W2G/7hVlkBkApYQS/O7+Eq1zYgITpOcYdXvrKHBOtgUwk\n ITmpZWihN0j6L1h1IHqKkQGTV8A9sSUhhId+iWnYzz5O2Pe8fcLkIrsQI\n 3+11RjZAYNlJRgiJElIZT/UjA5rglLyFG6JESCSt/imU0qLu+h87JuFvO g==;","X-IronPort-AV":["E=McAfee;i=\"6600,9927,10893\"; a=\"375515654\"","E=Sophos;i=\"6.03,299,1694761200\"; d=\"scan'208\";a=\"375515654\"","E=Sophos;i=\"6.03,299,1694761200\"; d=\"scan'208\";a=\"12527788\""],"X-ExtLoop1":"1","ARC-Seal":"i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=l6P8fUUzllBgH8s+4v17OE0DCOrZG1ok6ONylpOXP5he0d3G5CeR/Zjvt1JlxVcF1mMveVSA4/SCk3oCT3XjBycLUasIfNaMelN5PrGcaQW1bKsLI3b8uEYrgRZk95pd7/HGotPdEwpDbP3yP2HJiisY+3G3M6lUzURW1ESaH8J35MHtshsePr/6AgCypESQVPc62B0KwfpNirchPH2Xow0IwC7XQMp40OquLJkJ89vWQSUb1nybOrNVy9uLZdMy/f2lYNdOCvFST7sb2rLPwmDm4gi4Nyh4cQf8d39hmtmO4fvQyRCBV6Epom30xPk8eGrQQzVKSuDKyWE/VjqDFQ==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;\n bh=oCPqqTuyXU7hHqvttl9FSkvlJFyayzeXXdrZNPAkKjY=;\n b=Gqt/LI85qV7V7U48Sw1BJwObXZW9rpXvH0Xbz+Yj0I1IJEKkVeUdBONbk2opbmh3oycyYfJxkyi+6X9t7BJYw1wqEV233Yj5p4K3WqNNvk5HpzS0aoMUyMY7RUhT9L0aHHiOxOnUnKGaYzJN10iuK31pdH+qM1PuvwAo/3vDG1/NWF4t5m741876YSIA/y7YBho+bVepBXoMI1dZgUKLzk/wTWWFWRMz13x0brTseXPPPFEk4pHRmkRJFWCeZUuduAKKzslFJzd1OK7Kg1lGApwDxHuFfDI3PCew0yD0qIlmGwYOtUiQHXg94fJ7cC1LyARfipfoMZ91GKir+uVOYQ==","ARC-Authentication-Results":"i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none","From":"\"Chiu, Chasel\" ","To":"Ard Biesheuvel ","CC":"Simon Glass , \"devicetree@vger.kernel.org\"\n , Mark Rutland , \"Rob\n Herring\" , \"Tan, Lean Sheng\" , lkml\n , Dhaval Sharma , \"Brune,\n Maximilian\" , Yunhui Cui\n , \"Dong, Guo\" , Tom Rini\n , ron minnich , \"Guo, Gua\"\n , \"linux-acpi@vger.kernel.org\"\n , U-Boot Mailing List ","Subject":"RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","Thread-Topic":"[PATCH v7 2/2] schemas: Add some common reserved-memory usages","Thread-Index":"AQHZ8LGvpttG6mvEz0WlU57NBrVnTbB0GT1wgAEi2gCAA4/1oA==","Date":"Mon, 13 Nov 2023 18:09:05 +0000","Message-ID":"\n ","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n ","In-Reply-To":"\n ","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","authentication-results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=ZuozXitP;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.b=\"ZuozXitP\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=chasel.chiu@intel.com","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=intel.com;"],"x-ms-publictraffictype":"Email","x-ms-traffictypediagnostic":"BN9PR11MB5483:EE_|PH7PR11MB7593:EE_","x-ms-office365-filtering-correlation-id":"781c6217-171e-4b37-58f6-08dbe4739fe8","x-ld-processed":"46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr","x-ms-exchange-senderadcheck":"1","x-ms-exchange-antispam-relay":"0","x-microsoft-antispam":"BCL:0;","x-microsoft-antispam-message-info":"\n H5IqpNAKgoASdbvP6g5zZ9kAxFkkZF/f89LfFzkMo+uL+Cl1YSmuEsG+oq0LL9x44L6iI8qtCS2ksBzsxDc9PY2ym2kKms25IoFkZr6teBudAEIS9uMp6h470XgXjLOJxvGw7rP2bEp2+arFpfaWtBEe2q1AJ48606OpfOhIA1/anOINp9FEiytw2hNM6kh+M86g8A+L52OIYINgmghSadv95/LCFxvldikb9bPLt7ar5mQpOnX/+tjepbLnB3P1Ylce01H5G31OFit9pzTlBXCLtEWvWHdS0sKY+5/sY3J4FE4Cu9Pif8YAMymNgmu86sYGlsZIDXiKYRz5xdFM/qDrVva7eKSQ806rkfRac6V1+H0LTwXbUuDweUqfFEQydu7cl5AWQGot7MV37aJZwFWCSKoEdmNjL1awVGFHx+2cEHXBwvW18llWrrY8h6v0xfF5fDbn2DfXBiLtRfYlyzWBNlX9I7XA2kHYaHM4fCUb1QeIbl8SLRVDKAB06HT1lrUDkBgFMRoDnC3MkiXvu6HKVApN+g9ThtLxVkQyxGdmySb5KcTHkFvSkri/kLmItIx4r1xDU6DEhgh9FA1mFoejwwwU9kzo8ABjcgnCz+M=","x-forefront-antispam-report":"CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:BN9PR11MB5483.namprd11.prod.outlook.com; PTR:; CAT:NONE;\n SFS:(13230031)(136003)(39860400002)(346002)(396003)(376002)(366004)(230922051799003)(64100799003)(451199024)(1800799009)(186009)(316002)(55016003)(54906003)(9686003)(6916009)(66476007)(66446008)(76116006)(66946007)(66556008)(83380400001)(38100700002)(64756008)(82960400001)(8676002)(8936002)(4326008)(122000001)(478600001)(966005)(6506007)(53546011)(7696005)(52536014)(5660300002)(86362001)(71200400001)(7416002)(38070700009)(2906002)(26005)(33656002)(41300700001);\n DIR:OUT; SFP:1102;","x-ms-exchange-antispam-messagedata-chunkcount":"1","x-ms-exchange-antispam-messagedata-0":"=?utf-8?q?vUm5CDv/MZJB85PudN+fnS3pMkYa?=\n\t=?utf-8?q?HgR4wDWv33lqTqunn4uNhmwvGELAu1Vwrg+5q5NFWkqRRM1FtT1Z7VKnDXniU5GCq?=\n\t=?utf-8?q?+Zh56JFEN8T0MT1TZEeKO/u0af6ouFsI6dTbOHnpcgRHkcasrWhRJGddZs8yYizfM?=\n\t=?utf-8?q?RhcJhJdv1wUgsU1qCHLPJWIiElDJTRQ7CkGUS2qY4wwgbFgwwggjfjN3Nrc3g4P++?=\n\t=?utf-8?q?EXbbeG4LlaYqRve5Efaoqqtuhx+KXS+cnGm59XO8kcQmgZ8jwwsuthdIFo2GgZwS+?=\n\t=?utf-8?q?bRPPZ5m4pGKh9wS/q3tCHl0vcAPOSd2ynY3I6s1zEe1jGG/13PngKH8ZpC2KDquXy?=\n\t=?utf-8?q?9cM/UScK0yQ3iGDVWL5ZmbA5O5k+KBXWe31IWw/h+c+K1k4H3co8f/Pj+oDuyAYUb?=\n\t=?utf-8?q?7fTS5N3gcRYax5wx0rjY3St8WPbFkq7l0JKH97faXAp3i57i1mClSkVGXBWJmLuzF?=\n\t=?utf-8?q?q3IBOLIsAEN/quhFqdBWMfddkWgewbtN11wVNwba5pgPhdUf4UJ+lxgS1ouaokC+O?=\n\t=?utf-8?q?+Fy6J3N+8xkF4XHUPbiqi+4GGGQPEhsq9lupGh4QRuU3YGIzO8TElEs024tSY+94W?=\n\t=?utf-8?q?Dy9Qas9VOKDDB3lp8EQ4g4qpBY6uq+E3kEBVzpz319YzmCK4xQsgLXgjqYYC6fWhF?=\n\t=?utf-8?q?wgX8XtifkxAh4ASKBreNfo1tuyfzYe8P5wFlp/5wQ7/NE61ofxk9PmO5jn0OUzo8Y?=\n\t=?utf-8?q?MZeI0/kl6E9VyP8YOgxobo0PXGg8FsxnNvhSX0MXstQHXpv/Dsid8uBo+iKEEhmHP?=\n\t=?utf-8?q?RV4Zuzr7o+WSj2ZkQ33U21yhBe/vFwgrS81tJw8xJpP2ahD5doyt3Kqg/TV2bCGcl?=\n\t=?utf-8?q?klm4LC1g4etZRhnBRTY3dMsYgwzDgiV+NrJ5HwRs/UYpadHVso10510WVhnUZtxgA?=\n\t=?utf-8?q?TIXUe9W7B5CaRV5AXf4X6dJ2QQ7Z8YQ4WYSivhJu+NpTgpkKGDjXdbdxFetRNriad?=\n\t=?utf-8?q?vjIvynokKRv7Jin2/pl7UgkiwMAR0XzZzv5vQ/XvwqXJxpA/MhDGOSDVBG6LokHwd?=\n\t=?utf-8?q?hD/K9LPmFyJcSnChJMRVldck5KnhRD+iY0yTt9P4P4F6RVThtVARKxeYSpU4tEHA4?=\n\t=?utf-8?q?NrgpL+C4XIsQghF5rgZaLTt2yu/nP0/1qnm9glFm8ZP3x4rb2u24gfzaZoKhbzJp4?=\n\t=?utf-8?q?Y9djToa4FVnUuOh1jEx4BIUXseyGGntYHF7sAucvz+HcXcgFAyc0KY4AypxVPyfDe?=\n\t=?utf-8?q?s4dYH3RdTlpA0JTLzIqUbPaRsgKzOoeQ37oEEB5KeFwT65GTT/iyXF1J+JkSiuRg7?=\n\t=?utf-8?q?0WaOt0wNT1vAyZ8Liw09dPiCxCa6NUx6xaaKHtlPDRHKbh3BcQoQV3FZZYy/i3fuB?=\n\t=?utf-8?q?PRFknPXFWvp50yzKtRG4Weq/YGfXXQ94at79ladnBwMQG+V0fCGk7ACmU4jUPEA03?=\n\t=?utf-8?q?7v4bWT+ietWxPl/EKUx8yfqtxMv/raR6qt0dwrNOR8cZho6OFW2gCG9vBLLp6BJmf?=\n\t=?utf-8?q?G+ZQZRJYCoten1WacQ3nfoGJfWvsf/Aujis3XvfHEKhMRx2t52pQPOnrwbbdVfrX0?=\n\t=?utf-8?q?AHr6QDYfXVZw?=","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-MS-Exchange-CrossTenant-AuthAs":"Internal","X-MS-Exchange-CrossTenant-AuthSource":"BN9PR11MB5483.namprd11.prod.outlook.com","X-MS-Exchange-CrossTenant-Network-Message-Id":"\n 781c6217-171e-4b37-58f6-08dbe4739fe8","X-MS-Exchange-CrossTenant-originalarrivaltime":"13 Nov 2023 18:09:05.7306 (UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"46c98d88-e344-4ed4-8496-4ed7712e255d","X-MS-Exchange-CrossTenant-mailboxtype":"HOSTED","X-MS-Exchange-CrossTenant-userprincipalname":"\n ekS46u9ymapPlqEp6Z03rfiUln+CftsXdHf3hMs3i2rhzMFjvJ6WDv8hBSUhipfKiBrPuvij3LfhfvUaTN6Gpw==","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"PH7PR11MB7593","X-OriginatorOrg":"intel.com","X-Mailman-Approved-At":"Mon, 13 Nov 2023 19:27:50 +0100","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3220019,"web_url":"http://patchwork.ozlabs.org/comment/3220019/","msgid":"","list_archive_url":null,"date":"2023-11-21T02:12:15","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":6170,"url":"http://patchwork.ozlabs.org/api/people/6170/","name":"Simon Glass","email":"sjg@chromium.org"},"content":"Hi,\n\nOn Mon, 13 Nov 2023 at 11:09, Chiu, Chasel wrote:\n>\n>\n> Hi Ard,\n>\n> Please see my reply below inline.\n>\n> Thanks,\n> Chasel\n>\n>\n> > -----Original Message-----\n> > From: Ard Biesheuvel \n> > Sent: Saturday, November 11, 2023 3:04 AM\n> > To: Chiu, Chasel \n> > Cc: Simon Glass ; devicetree@vger.kernel.org; Mark Rutland\n> > ; Rob Herring ; Tan, Lean Sheng\n> > ; lkml ; Dhaval\n> > Sharma ; Brune, Maximilian\n> > ; Yunhui Cui ;\n> > Dong, Guo ; Tom Rini ; ron minnich\n> > ; Guo, Gua ; linux-\n> > acpi@vger.kernel.org; U-Boot Mailing List \n> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> > usages\n> >\n> > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel wrote:\n> > >\n> > >\n> > > Just sharing some usage examples from UEFI/EDK2 scenario.\n> > > To support ACPI S4/Hibernation, memory map must be consistent before\n> > > entering and after resuming from S4, in this case payload may need to\n> > > know previous memory map from bootloader (currently generic payload\n> > > cannot access platform/bootloader specific non-volatile data, thus\n> > > could not save/restore memory map information)\n> >\n> > So how would EDK2 reconstruct the entire EFI memory map from just these\n> > unannotated /reserved-memory nodes? The EFI memory map contains much\n> > more information than that, and all of it has to match the pre-hibernate situation,\n> > right? Can you given an example?\n>\n>\n> Here we listed only typically memory types that may change cross different platforms.\n> Reserved memory type already can be handled by reserved-memory node, and rest of the types usually no need to change cross platforms thus currently we could rely on default in generic payload.\n> In the future if we see a need to add new memory types we will discuss and add it to FDT schema.\n>\n>\n>\n> >\n> > > Another usage is to support binary model which generic payload is a prebuilt\n> > binary compatible for all platforms/configurations, however the payload default\n> > memory map might not always work for all the configurations and we want to\n> > allow bootloader to override payload default memory map without recompiling.\n> > >\n> >\n> > Agreed. But can you explain how a EDK2 payload might make meaningful use of\n> > 'runtime-code' regions provided via DT by the non-EDK2 platform init? Can you\n> > give an example?\n>\n>\n> Runtime-code/data is used by UEFI payload for booting UEFI OS which required UEFI runtime services.\n> Platform Init will select some regions from the usable memory and assign it to runtime-code/data for UPL to consume. Or assign same runtime-code/data from previous boot.\n> If UEFI OS is not supported, PlatformInit may not need to provide runtime-code/data regions to payload. (always providing runtime-code/data should be supported too)\n>\n>\n> >\n> > > Under below assumption:\n> > > FDT OS impact has been evaluated and taken care by relevant\n> > experts/stakeholders.\n> > > Reviewed-by: Chasel Chiu \n> > >\n> >\n> > I am sorry but I don't know what 'FDT OS impact' means. We are talking about a\n> > firmware-to-firmware abstraction that has the potential to leak into the OS\n> > visible interface.\n> >\n> > I am a maintainer in the Tianocore project myself, so it would help if you could\n> > explain who these relevant experts and stakeholders are. Was this discussed on\n> > the edk2-devel mailing list? If so, apologies for missing it but I may not have been\n> > cc'ed perhaps?\n>\n>\n>\n>\n> I'm not familiar with FDT OS, also I do not know if who from edk2-devel were supporting FDT OS, I think Simon might be able to connect FDT OS experts/stakeholders.\n> We are mostly focusing on payload firmware phase implementation in edk2 (and other payloads too), however, since we have aligned the payload FDT and OS FDT months ago, I'm assuming FDT OS impact must be there and we need (or already done?) FDT OS experts to support it. (again, maybe Simon could share more information about FDT OS)\n>\n> In edk2 such FDT schema is UefiPayloadPkg internal usage only and payload entry will convert FDT into HOB thus we expected the most of the edk2 generic code are no-touch/no impact, that's why we only had small group (UefiPayloadPkg) discussion.\n> Ard, if you are aware of any edk2 code that's for supporting FDT OS, please let us know and we can discuss if those code were impacted or not.\n\nWe discussed this and just to clarify, 'FDT OS' is not a special OS,\nit is just Linux.\n\nSo, with the above, are we all on the same page? Can the patch be\napplied, perhaps? If not, what other discussion is needed?\n\nRegards,\nSimon\n\n>\n>\n>\n>\n> >\n> >\n> > >\n> > > > -----Original Message-----\n> > > > From: Simon Glass \n> > > > Sent: Tuesday, September 26, 2023 12:43 PM\n> > > > To: devicetree@vger.kernel.org\n> > > > Cc: Mark Rutland ; Rob Herring\n> > > > ; Tan, Lean Sheng ; lkml\n> > > > ; Dhaval Sharma\n> > > > ; Brune, Maximilian\n> > > > ; Yunhui Cui\n> > > > ; Dong, Guo ; Tom Rini\n> > > > ; ron minnich ; Guo, Gua\n> > > > ; Chiu, Chasel ; linux-\n> > > > acpi@vger.kernel.org; U-Boot Mailing List ;\n> > > > Ard Biesheuvel ; Simon Glass \n> > > > Subject: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> > > > usages\n> > > >\n> > > > It is common to split firmware into 'Platform Init', which does the\n> > > > initial hardware setup and a \"Payload\" which selects the OS to be booted.\n> > > > Thus an handover interface is required between these two pieces.\n> > > >\n> > > > Where UEFI boot-time services are not available, but UEFI firmware\n> > > > is present on either side of this interface, information about\n> > > > memory usage and attributes must be presented to the \"Payload\" in some\n> > form.\n> > > >\n> > > > This aims to provide an small schema addition for the memory mapping\n> > > > needed to keep these two pieces working together well.\n> > > >\n> > > > Signed-off-by: Simon Glass \n> > > > ---\n> > > >\n> > > > Changes in v7:\n> > > > - Rename acpi-reclaim to acpi\n> > > > - Drop individual mention of when memory can be reclaimed\n> > > > - Rewrite the item descriptions\n> > > > - Add back the UEFI text (with trepidation)\n> > > >\n> > > > Changes in v6:\n> > > > - Drop mention of UEFI\n> > > > - Use compatible strings instead of node names\n> > > >\n> > > > Changes in v5:\n> > > > - Drop the memory-map node (should have done that in v4)\n> > > > - Tidy up schema a bit\n> > > >\n> > > > Changes in v4:\n> > > > - Make use of the reserved-memory node instead of creating a new one\n> > > >\n> > > > Changes in v3:\n> > > > - Reword commit message again\n> > > > - cc a lot more people, from the FFI patch\n> > > > - Split out the attributes into the /memory nodes\n> > > >\n> > > > Changes in v2:\n> > > > - Reword commit message\n> > > >\n> > > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++\n> > > > 1 file changed, 71 insertions(+)\n> > > > create mode 100644 dtschema/schemas/reserved-memory/common-\n> > > > reserved.yaml\n> > > >\n> > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > new file mode 100644\n> > > > index 0000000..f7fbdfd\n> > > > --- /dev/null\n> > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml\n> > > > @@ -0,0 +1,71 @@\n> > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2\n> > > > +---\n> > > > +$id:\n> > > > +http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#\n> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#\n> > > > +\n> > > > +title: Common memory reservations\n> > > > +\n> > > > +description: |\n> > > > + Specifies that the reserved memory region can be used for the\n> > > > +purpose\n> > > > + indicated by its compatible string.\n> > > > +\n> > > > + Clients may reuse this reserved memory if they understand what it\n> > > > + is for, subject to the notes below.\n> > > > +\n> > > > +maintainers:\n> > > > + - Simon Glass \n> > > > +\n> > > > +allOf:\n> > > > + - $ref: reserved-memory.yaml\n> > > > +\n> > > > +properties:\n> > > > + compatible:\n> > > > + description: |\n> > > > + This describes some common memory reservations, with the compatible\n> > > > + string indicating what it is used for:\n> > > > +\n> > > > + acpi: Advanced Configuration and Power Interface (ACPI) tables\n> > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by\n> > > > + the firmware for its use and is required to be saved and restored\n> > > > + across an NVS sleep\n> > > > + boot-code: Contains code used for booting which is not needed by the\n> > OS\n> > > > + boot-code: Contains data used for booting which is not needed by the\n> > OS\n> > > > + runtime-code: Contains code used for interacting with the system when\n> > > > + running the OS\n> > > > + runtime-data: Contains data used for interacting with the system when\n> > > > + running the OS\n> > > > +\n> > > > + enum:\n> > > > + - acpi\n> > > > + - acpi-nvs\n> > > > + - boot-code\n> > > > + - boot-data\n> > > > + - runtime-code\n> > > > + - runtime-data\n> > > > +\n> > > > + reg:\n> > > > + description: region of memory that is reserved for the purpose indicated\n> > > > + by the compatible string.\n> > > > +\n> > > > +required:\n> > > > + - reg\n> > > > +\n> > > > +unevaluatedProperties: false\n> > > > +\n> > > > +examples:\n> > > > + - |\n> > > > + reserved-memory {\n> > > > + #address-cells = <1>;\n> > > > + #size-cells = <1>;\n> > > > +\n> > > > + reserved@12340000 {\n> > > > + compatible = \"boot-code\";\n> > > > + reg = <0x12340000 0x00800000>;\n> > > > + };\n> > > > +\n> > > > + reserved@43210000 {\n> > > > + compatible = \"boot-data\";\n> > > > + reg = <0x43210000 0x00800000>;\n> > > > + };\n> > > > + };\n> > > > --\n> > > > 2.42.0.515.g380fc7ccd1-goog\n> > >","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256\n header.s=google header.b=f0uxTc2g;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=85.214.62.61; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org\n header.b=\"f0uxTc2g\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com"],"Received":["from phobos.denx.de (phobos.denx.de [85.214.62.61])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SZ7F12YPKz1ySN\n\tfor ; Tue, 21 Nov 2023 13:12:37 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id C48B3870F8;\n\tTue, 21 Nov 2023 03:12:32 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id AF9C3869F6; Tue, 21 Nov 2023 03:12:31 +0100 (CET)","from mail-ej1-x634.google.com (mail-ej1-x634.google.com\n [IPv6:2a00:1450:4864:20::634])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 21BBB875D6\n for ; Tue, 21 Nov 2023 03:12:28 +0100 (CET)","by mail-ej1-x634.google.com with SMTP id\n a640c23a62f3a-991c786369cso693078466b.1\n for ; Mon, 20 Nov 2023 18:12:28 -0800 (PST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-9.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,\n SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_SPF_WL\n autolearn=no autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=chromium.org; s=google; t=1700532747; x=1701137547; darn=lists.denx.de;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:from:to:cc:subject:date\n :message-id:reply-to;\n bh=9oErZSNPpRWj6cWya6fUNKL2baOOgkbfElqn5bDFEVg=;\n b=f0uxTc2g+bM8emomnLjI1stwZscbCpuDPArShPFv+AfmQ7PpHl/CayNfLDWQVWQ86m\n UkIvIwEhaYWtH3FQCZSxCiLOm6/9GhsPfYudHNm7qXJlgfhPsegJGu+jzt6x7dIiR1vq\n KWgECP9GHhBQltQJh6KSEsa+3DoZOZyLjAFgY=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1700532747; x=1701137547;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc\n :subject:date:message-id:reply-to;\n bh=9oErZSNPpRWj6cWya6fUNKL2baOOgkbfElqn5bDFEVg=;\n b=cIIjt9h0kxEbrSg77IdPCmYNeVx2wzPX8JtUDZUMKCjeUlEDFyPtHoK/O1lVa+QwQl\n EyLk7X18M3T3jFDKoltwIntFf/Y0G16w7E++0DrQFheFSiXGxPa4wnbOATLHZKCnoIlP\n BkrGVbPFz7GzyC4Hrx4T208zBckxzA+Hi1rPh1E7HYLYRLwxhPyq8B6s05AXphIQOPKs\n RDn0FnqDnS7WETIoz8r/mXYFE0xUVZYEniv7uFu/Skz7FQcbCEd6eqhxHZd1YEnI8GNN\n qvSmd+AvJJ8U724hIiF0LSTGImbGfSwtwgmtzc6O1I4kREINX22I1xa6nihwL3bz/pAL\n PmJQ==","X-Gm-Message-State":"AOJu0YwnTHGBBcBa4q33T2IdQciP9v8uo0P6M7Gy9LBPG1NmYTU3fOR+\n k9y1thNVOB3ZLq2AlcnBBvA9QeaD3jnOrMf1yWTRDg==","X-Google-Smtp-Source":"\n AGHT+IEzZ6s5vb8lIiHxjBh0g3WDopuC29/uf986diynE3D2QSfTI/OYBwO7jAdNcvlEjuiL/tfXN7R6J2D15fFjvM0=","X-Received":"by 2002:a17:906:224d:b0:9bf:2f84:5de7 with SMTP id\n 13-20020a170906224d00b009bf2f845de7mr6153971ejr.4.1700532747244; Mon, 20 Nov\n 2023 18:12:27 -0800 (PST)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n ","In-Reply-To":"\n ","From":"Simon Glass ","Date":"Mon, 20 Nov 2023 19:12:15 -0700","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"\"Chiu, Chasel\" ","Cc":"Ard Biesheuvel ,\n \"devicetree@vger.kernel.org\" ,\n Mark Rutland ,\n Rob Herring , \"Tan, Lean Sheng\" ,\n lkml , Dhaval Sharma ,\n \"Brune, Maximilian\" ,\n Yunhui Cui ,\n \"Dong, Guo\" , Tom Rini ,\n ron minnich , \"Guo, Gua\" ,\n \"linux-acpi@vger.kernel.org\" ,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3220640,"web_url":"http://patchwork.ozlabs.org/comment/3220640/","msgid":"","list_archive_url":null,"date":"2023-11-21T16:41:59","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":77831,"url":"http://patchwork.ozlabs.org/api/people/77831/","name":"Ard Biesheuvel","email":"ardb@kernel.org"},"content":"On Mon, 20 Nov 2023 at 21:12, Simon Glass wrote:\n>\n> Hi,\n>\n> On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel wrote:\n> >\n> >\n> > Hi Ard,\n> >\n> > Please see my reply below inline.\n> >\n> > Thanks,\n> > Chasel\n> >\n> >\n> > > -----Original Message-----\n> > > From: Ard Biesheuvel \n> > > Sent: Saturday, November 11, 2023 3:04 AM\n> > > To: Chiu, Chasel \n> > > Cc: Simon Glass ; devicetree@vger.kernel.org; Mark Rutland\n> > > ; Rob Herring ; Tan, Lean Sheng\n> > > ; lkml ; Dhaval\n> > > Sharma ; Brune, Maximilian\n> > > ; Yunhui Cui ;\n> > > Dong, Guo ; Tom Rini ; ron minnich\n> > > ; Guo, Gua ; linux-\n> > > acpi@vger.kernel.org; U-Boot Mailing List \n> > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> > > usages\n> > >\n> > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel wrote:\n> > > >\n> > > >\n> > > > Just sharing some usage examples from UEFI/EDK2 scenario.\n> > > > To support ACPI S4/Hibernation, memory map must be consistent before\n> > > > entering and after resuming from S4, in this case payload may need to\n> > > > know previous memory map from bootloader (currently generic payload\n> > > > cannot access platform/bootloader specific non-volatile data, thus\n> > > > could not save/restore memory map information)\n> > >\n> > > So how would EDK2 reconstruct the entire EFI memory map from just these\n> > > unannotated /reserved-memory nodes? The EFI memory map contains much\n> > > more information than that, and all of it has to match the pre-hibernate situation,\n> > > right? Can you given an example?\n> >\n> >\n> > Here we listed only typically memory types that may change cross different platforms.\n> > Reserved memory type already can be handled by reserved-memory node, and rest of the types usually no need to change cross platforms thus currently we could rely on default in generic payload.\n> > In the future if we see a need to add new memory types we will discuss and add it to FDT schema.\n> >\n> >\n> >\n> > >\n> > > > Another usage is to support binary model which generic payload is a prebuilt\n> > > binary compatible for all platforms/configurations, however the payload default\n> > > memory map might not always work for all the configurations and we want to\n> > > allow bootloader to override payload default memory map without recompiling.\n> > > >\n> > >\n> > > Agreed. But can you explain how a EDK2 payload might make meaningful use of\n> > > 'runtime-code' regions provided via DT by the non-EDK2 platform init? Can you\n> > > give an example?\n> >\n> >\n> > Runtime-code/data is used by UEFI payload for booting UEFI OS which required UEFI runtime services.\n> > Platform Init will select some regions from the usable memory and assign it to runtime-code/data for UPL to consume. Or assign same runtime-code/data from previous boot.\n> > If UEFI OS is not supported, PlatformInit may not need to provide runtime-code/data regions to payload. (always providing runtime-code/data should be supported too)\n> >\n> >\n> > >\n> > > > Under below assumption:\n> > > > FDT OS impact has been evaluated and taken care by relevant\n> > > experts/stakeholders.\n> > > > Reviewed-by: Chasel Chiu \n> > > >\n> > >\n> > > I am sorry but I don't know what 'FDT OS impact' means. We are talking about a\n> > > firmware-to-firmware abstraction that has the potential to leak into the OS\n> > > visible interface.\n> > >\n> > > I am a maintainer in the Tianocore project myself, so it would help if you could\n> > > explain who these relevant experts and stakeholders are. Was this discussed on\n> > > the edk2-devel mailing list? If so, apologies for missing it but I may not have been\n> > > cc'ed perhaps?\n> >\n> >\n> >\n> >\n> > I'm not familiar with FDT OS, also I do not know if who from edk2-devel were supporting FDT OS, I think Simon might be able to connect FDT OS experts/stakeholders.\n> > We are mostly focusing on payload firmware phase implementation in edk2 (and other payloads too), however, since we have aligned the payload FDT and OS FDT months ago, I'm assuming FDT OS impact must be there and we need (or already done?) FDT OS experts to support it. (again, maybe Simon could share more information about FDT OS)\n> >\n> > In edk2 such FDT schema is UefiPayloadPkg internal usage only and payload entry will convert FDT into HOB thus we expected the most of the edk2 generic code are no-touch/no impact, that's why we only had small group (UefiPayloadPkg) discussion.\n> > Ard, if you are aware of any edk2 code that's for supporting FDT OS, please let us know and we can discuss if those code were impacted or not.\n>\n> We discussed this and just to clarify, 'FDT OS' is not a special OS,\n> it is just Linux.\n>\n> So, with the above, are we all on the same page? Can the patch be\n> applied, perhaps? If not, what other discussion is needed?\n>\n\nAn example of how a platform-init/payload combination would make\nmeaningful use of such runtime-code/data regions.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=fbdiQe8X;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.b=\"fbdiQe8X\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de; spf=pass smtp.mailfrom=ardb@kernel.org"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SZVXX1jjSz1ySS\n\tfor ; Wed, 22 Nov 2023 03:42:20 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 239CB875A4;\n\tTue, 21 Nov 2023 17:42:18 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id 5EFB9875B8; Tue, 21 Nov 2023 17:42:17 +0100 (CET)","from dfw.source.kernel.org (dfw.source.kernel.org\n [IPv6:2604:1380:4641:c500::1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id CFDB187258\n for ; Tue, 21 Nov 2023 17:42:14 +0100 (CET)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by dfw.source.kernel.org (Postfix) with ESMTP id 3560461A95\n for ; Tue, 21 Nov 2023 16:42:13 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id D783CC433CD\n for ; Tue, 21 Nov 2023 16:42:12 +0000 (UTC)","by mail-lj1-f179.google.com with SMTP id\n 38308e7fff4ca-2c876f1e44dso38703931fa.0\n for ; Tue, 21 Nov 2023 08:42:12 -0800 (PST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no\n version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1700584932;\n bh=aFR/mFQKExXAv/nb9N19ON2XLkx59yXepa2exX1U6mQ=;\n h=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n b=fbdiQe8X69JnkXR9G+YL3eKWLpEa9R9p0icP5neCy/qJjCZXxLmCZD/NbohU93wcY\n 7SZNvGqDRjTIN4EdDte4XEmQqO13pIkEPKnHBaPukBCH3u5Isy7Ye+sKEUiCpoztrz\n O9+3cOmKQsoDuRGnceCn/iMAutUZb/loXqoXJ0eG/EndcQ0HQSNzYPgGGjHoFXVBip\n MLpYlEajp8IToIRD/xSOQpFuIzgQ+87Qt2+7p6IojhME43Dho6v/ZWdPoh0jtFo6Q5\n Lr35JjycOgRghk1gA7aq7nAlEs8LP3FEIrWIEOED74W6cwpJGzdQuvIWYQ83m7ENRi\n g7G1UzLENPMVQ==","X-Gm-Message-State":"AOJu0Yyg4F9UXv+f8RRNhe9akUfHLJyCtXd8y0aLFMC3XsaUSQBb627J\n JKDkiO81vhTIOf7ICfCo73agBXRxcepcwM+CQ1o=","X-Google-Smtp-Source":"\n AGHT+IE1BtBBQXH8IhaD0lfThsj9OIMHKzDOIxlPBJGUB9DukWvY41yZhOqj18nk5W7PFyAXHxOdAkbW6vA0h7iKYww=","X-Received":"by 2002:a2e:8e63:0:b0:2bb:a28b:58e1 with SMTP id\n t3-20020a2e8e63000000b002bba28b58e1mr7794383ljk.41.1700584931089; Tue, 21 Nov\n 2023 08:42:11 -0800 (PST)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n ","In-Reply-To":"\n ","From":"Ard Biesheuvel ","Date":"Tue, 21 Nov 2023 11:41:59 -0500","X-Gmail-Original-Message-ID":"\n ","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"Simon Glass ","Cc":"\"Chiu, Chasel\" ,\n \"devicetree@vger.kernel.org\" ,\n Mark Rutland ,\n Rob Herring , \"Tan, Lean Sheng\" ,\n lkml , Dhaval Sharma ,\n \"Brune, Maximilian\" ,\n Yunhui Cui ,\n \"Dong, Guo\" , Tom Rini ,\n ron minnich , \"Guo, Gua\" ,\n \"linux-acpi@vger.kernel.org\" ,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3220764,"web_url":"http://patchwork.ozlabs.org/comment/3220764/","msgid":"","list_archive_url":null,"date":"2023-11-21T18:34:20","subject":"RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":87524,"url":"http://patchwork.ozlabs.org/api/people/87524/","name":"Chiu, Chasel","email":"chasel.chiu@intel.com"},"content":"Hi Ard,\n\nHere is the POC PR for your reference: https://github.com/tianocore/edk2/pull/4969/files#diff-ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR268\nPlease note that this PR is still in early phase and expected to have significant changes.\n\nThe idea is that payload entry will create gEfiMemoryTypeInformationGuid HOB with payload default memory types and allow FDT to override if correspond node present.\nPlease let me know if you have questions or suggestions.\n\nThanks,\nChasel\n\n\n> -----Original Message-----\n> From: Ard Biesheuvel \n> Sent: Tuesday, November 21, 2023 8:42 AM\n> To: Simon Glass \n> Cc: Chiu, Chasel ; devicetree@vger.kernel.org; Mark\n> Rutland ; Rob Herring ; Tan, Lean\n> Sheng ; lkml ;\n> Dhaval Sharma ; Brune, Maximilian\n> ; Yunhui Cui ;\n> Dong, Guo ; Tom Rini ; ron minnich\n> ; Guo, Gua ; linux-\n> acpi@vger.kernel.org; U-Boot Mailing List \n> Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> usages\n> \n> On Mon, 20 Nov 2023 at 21:12, Simon Glass wrote:\n> >\n> > Hi,\n> >\n> > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel wrote:\n> > >\n> > >\n> > > Hi Ard,\n> > >\n> > > Please see my reply below inline.\n> > >\n> > > Thanks,\n> > > Chasel\n> > >\n> > >\n> > > > -----Original Message-----\n> > > > From: Ard Biesheuvel \n> > > > Sent: Saturday, November 11, 2023 3:04 AM\n> > > > To: Chiu, Chasel \n> > > > Cc: Simon Glass ; devicetree@vger.kernel.org;\n> > > > Mark Rutland ; Rob Herring\n> > > > ; Tan, Lean Sheng ; lkml\n> > > > ; Dhaval Sharma\n> > > > ; Brune, Maximilian\n> > > > ; Yunhui Cui\n> > > > ; Dong, Guo ; Tom\n> > > > Rini ; ron minnich ; Guo,\n> > > > Gua ; linux- acpi@vger.kernel.org; U-Boot\n> > > > Mailing List \n> > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common\n> > > > reserved-memory usages\n> > > >\n> > > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel wrote:\n> > > > >\n> > > > >\n> > > > > Just sharing some usage examples from UEFI/EDK2 scenario.\n> > > > > To support ACPI S4/Hibernation, memory map must be consistent\n> > > > > before entering and after resuming from S4, in this case payload\n> > > > > may need to know previous memory map from bootloader (currently\n> > > > > generic payload cannot access platform/bootloader specific\n> > > > > non-volatile data, thus could not save/restore memory map\n> > > > > information)\n> > > >\n> > > > So how would EDK2 reconstruct the entire EFI memory map from just\n> > > > these unannotated /reserved-memory nodes? The EFI memory map\n> > > > contains much more information than that, and all of it has to\n> > > > match the pre-hibernate situation, right? Can you given an example?\n> > >\n> > >\n> > > Here we listed only typically memory types that may change cross different\n> platforms.\n> > > Reserved memory type already can be handled by reserved-memory node,\n> and rest of the types usually no need to change cross platforms thus currently we\n> could rely on default in generic payload.\n> > > In the future if we see a need to add new memory types we will discuss and\n> add it to FDT schema.\n> > >\n> > >\n> > >\n> > > >\n> > > > > Another usage is to support binary model which generic payload\n> > > > > is a prebuilt\n> > > > binary compatible for all platforms/configurations, however the\n> > > > payload default memory map might not always work for all the\n> > > > configurations and we want to allow bootloader to override payload default\n> memory map without recompiling.\n> > > > >\n> > > >\n> > > > Agreed. But can you explain how a EDK2 payload might make\n> > > > meaningful use of 'runtime-code' regions provided via DT by the\n> > > > non-EDK2 platform init? Can you give an example?\n> > >\n> > >\n> > > Runtime-code/data is used by UEFI payload for booting UEFI OS which\n> required UEFI runtime services.\n> > > Platform Init will select some regions from the usable memory and assign it to\n> runtime-code/data for UPL to consume. Or assign same runtime-code/data from\n> previous boot.\n> > > If UEFI OS is not supported, PlatformInit may not need to provide\n> > > runtime-code/data regions to payload. (always providing\n> > > runtime-code/data should be supported too)\n> > >\n> > >\n> > > >\n> > > > > Under below assumption:\n> > > > > FDT OS impact has been evaluated and taken care by\n> > > > > relevant\n> > > > experts/stakeholders.\n> > > > > Reviewed-by: Chasel Chiu \n> > > > >\n> > > >\n> > > > I am sorry but I don't know what 'FDT OS impact' means. We are\n> > > > talking about a firmware-to-firmware abstraction that has the\n> > > > potential to leak into the OS visible interface.\n> > > >\n> > > > I am a maintainer in the Tianocore project myself, so it would\n> > > > help if you could explain who these relevant experts and\n> > > > stakeholders are. Was this discussed on the edk2-devel mailing\n> > > > list? If so, apologies for missing it but I may not have been cc'ed perhaps?\n> > >\n> > >\n> > >\n> > >\n> > > I'm not familiar with FDT OS, also I do not know if who from edk2-devel were\n> supporting FDT OS, I think Simon might be able to connect FDT OS\n> experts/stakeholders.\n> > > We are mostly focusing on payload firmware phase implementation in\n> > > edk2 (and other payloads too), however, since we have aligned the\n> > > payload FDT and OS FDT months ago, I'm assuming FDT OS impact must\n> > > be there and we need (or already done?) FDT OS experts to support\n> > > it. (again, maybe Simon could share more information about FDT OS)\n> > >\n> > > In edk2 such FDT schema is UefiPayloadPkg internal usage only and payload\n> entry will convert FDT into HOB thus we expected the most of the edk2 generic\n> code are no-touch/no impact, that's why we only had small group\n> (UefiPayloadPkg) discussion.\n> > > Ard, if you are aware of any edk2 code that's for supporting FDT OS, please let\n> us know and we can discuss if those code were impacted or not.\n> >\n> > We discussed this and just to clarify, 'FDT OS' is not a special OS,\n> > it is just Linux.\n> >\n> > So, with the above, are we all on the same page? Can the patch be\n> > applied, perhaps? If not, what other discussion is needed?\n> >\n> \n> An example of how a platform-init/payload combination would make meaningful\n> use of such runtime-code/data regions.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=F6kDBQWR;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.b=\"F6kDBQWR\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=chasel.chiu@intel.com","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=intel.com;"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SZZd10fZ6z1yRV\n\tfor ; Wed, 22 Nov 2023 06:46:29 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 877BE87628;\n\tTue, 21 Nov 2023 20:46:04 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id D253987595; Tue, 21 Nov 2023 19:34:34 +0100 (CET)","from mgamail.intel.com (mgamail.intel.com [198.175.65.9])\n (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 741B687448\n for ; Tue, 21 Nov 2023 19:34:30 +0100 (CET)","from orsmga004.jf.intel.com ([10.7.209.38])\n by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 21 Nov 2023 10:34:27 -0800","from fmsmsx602.amr.corp.intel.com ([10.18.126.82])\n by orsmga004.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384;\n 21 Nov 2023 10:34:26 -0800","from fmsmsx612.amr.corp.intel.com (10.18.126.92) by\n fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.2507.34; Tue, 21 Nov 2023 10:34:26 -0800","from fmsmsx610.amr.corp.intel.com (10.18.126.90) by\n fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.2507.34; Tue, 21 Nov 2023 10:34:25 -0800","from fmsedg602.ED.cps.intel.com (10.1.192.136) by\n fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.2507.34 via Frontend Transport; Tue, 21 Nov 2023 10:34:25 -0800","from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.169)\n by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.1.2507.34; Tue, 21 Nov 2023 10:34:25 -0800","from BN9PR11MB5483.namprd11.prod.outlook.com (2603:10b6:408:104::10)\n by MW3PR11MB4683.namprd11.prod.outlook.com (2603:10b6:303:5c::24)\n with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.28; Tue, 21 Nov\n 2023 18:34:21 +0000","from BN9PR11MB5483.namprd11.prod.outlook.com\n ([fe80::6da1:a4b7:4771:14e1]) by BN9PR11MB5483.namprd11.prod.outlook.com\n ([fe80::6da1:a4b7:4771:14e1%4]) with mapi id 15.20.7002.028; Tue, 21 Nov 2023\n 18:34:20 +0000"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no\n version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1700591671; x=1732127671;\n h=from:to:cc:subject:date:message-id:references:\n in-reply-to:content-transfer-encoding:mime-version;\n bh=RDmVzRqsZY3VloV2zlXwC04Jf/AAPUUL9CrU1qerfDo=;\n b=F6kDBQWRcjD9VUOc2cMt331HA7w8SJzl7N4jr2WEuwXphYDvfFQiwlK/\n H5byb+SDkdFcFOGwC9C+uuGf/QHI3CUyV5EJiq0q4QXZvhsAE3ZlxxzQc\n rc8aR22e3J0vjgaZYTf2GLTSbOxxLUT3T+EH4jXtgkhEzJnKF89MMVHx2\n ATsmtul18EvZaasaGY5foswm9RnRBdG9qoX4LaPNYVBZcFrE0uQSSPgLl\n lwX/XrLfgp5lL0PDr/IpBKZgSjtaDgLnX4Xn+/3JouXHnB/Nw2Fn37dLO\n oFb+fF9NLmAHTEuyj4o5X+zEdrsQupBR9Ri+J91nGYb7nin2tTH+uwOjx w==;","X-IronPort-AV":["E=McAfee;i=\"6600,9927,10901\"; a=\"10570023\"","E=Sophos;i=\"6.04,216,1695711600\"; d=\"scan'208\";a=\"10570023\"","E=McAfee;i=\"6600,9927,10901\"; a=\"890333577\"","E=Sophos;i=\"6.04,216,1695711600\"; d=\"scan'208\";a=\"890333577\""],"X-ExtLoop1":"1","ARC-Seal":"i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=RGdNJzJuWKpEmpxv1/DqVNEyYxAEkQRmm3JMbJHGEeWa5LgBw6OH//acDCbVBdFuLZQZ2pyeSgIrGf40W0PYNpFiTzDk0K008WKcWBok2k31dmmiy/uJe/mfZL+u1nVtI5IbT8/dB7yqAKicFAF5SaBBIO3QkHoTcUMFPVqe8ieFK7lVpjqNasN/ZN0VL/p6hSO6CaHzRfHOjxAEt3CR4TgboAmJkuM4ZgQK/kdEt1UlGmE17+vXg1tbxxStB5DhiT21mXyUi3JszoMLMea34E+tiHOf1rT2/A47teY4bbyCYjNlNyMoNJeqO6YzG8zZcHRPRML6+gUMWEUzHmwlDA==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;\n bh=RDmVzRqsZY3VloV2zlXwC04Jf/AAPUUL9CrU1qerfDo=;\n b=ZFzSukpMxRbneDKnYC2Xd+iTo0RSOVcWNytSbxPl7qIV9WMX5a+OUaba47aFOAGbdVk4gXKEyFmwaAzCmV3W/6nH2Ffmvren4H9IKvcAZfsQ5mMReqnBg2zNxG1NqjKUtkWhYLyU7P6TPBudzAHzwAUbo+nyRiWx3DsxcTuBHyfW0smkJbe20OWoi0d2oRBTnJ2ao/d7cTcCsDc11d6mnO0cZWoc2YUP4Qce5L4+QBCVR7/HGWiykMkq4ns1JsHjUixfpaFv7ngR7MtIjxalObWILW6eLSvqYGaKDomgm4OsNgNvQ7X/IueNxrkB0/9DAHjcwiG4IzWs6zvh7kUNsg==","ARC-Authentication-Results":"i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none","From":"\"Chiu, Chasel\" ","To":"Ard Biesheuvel , Simon Glass ","CC":"\"devicetree@vger.kernel.org\" , Mark Rutland\n , Rob Herring , \"Tan, Lean Sheng\"\n , lkml , Dhaval Sharma\n , \"Brune, Maximilian\" ,\n Yunhui Cui , \"Dong, Guo\" , \"Tom\n Rini\" , ron minnich , \"Guo, Gua\"\n , \"linux-acpi@vger.kernel.org\"\n , U-Boot Mailing List ,\n \"Chiu, Chasel\" ","Subject":"RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","Thread-Topic":"[PATCH v7 2/2] schemas: Add some common reserved-memory usages","Thread-Index":"\n AQHZ8LGvpttG6mvEz0WlU57NBrVnTbB0GT1wgAEi2gCAA4/1oIALktuAgADzAICAABvkkA==","Date":"Tue, 21 Nov 2023 18:34:20 +0000","Message-ID":"\n ","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n ","In-Reply-To":"\n ","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","authentication-results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=F6kDBQWR;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.b=\"F6kDBQWR\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=chasel.chiu@intel.com","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=intel.com;"],"x-ms-publictraffictype":"Email","x-ms-traffictypediagnostic":"BN9PR11MB5483:EE_|MW3PR11MB4683:EE_","x-ms-office365-filtering-correlation-id":"11da1951-4fd1-4899-c3c6-08dbeac079fa","x-ld-processed":"46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr","x-ms-exchange-senderadcheck":"1","x-ms-exchange-antispam-relay":"0","x-microsoft-antispam":"BCL:0;","x-microsoft-antispam-message-info":"\n lDq+FFx22x9fxl1ESN6SwrxJ9+FLybnMI7DGopsZnXmEDf3dw7fTfq9bnYYEZ2wS3ITJV02903G4dATdaoE6v4T202cqggFt3B+eFnnBcXgUOjhvBnGeL2JE71iiCsIsTK+xdTFF8A/1JB/sYdskFKZIwqzsNNPV+Dgr/jgq3p2PY0BtS+Ua4wwPxO5aRz1TrZY6trJwpP6lBS1MQyhIuVCiKMtduHMwfc/8rsaeHCsrnaYSRsnW+H7tvquxR6m+hnHnOKxn+5d0wXB6S5GljoIk+6PfBUBA3rEWIDR9xVMwVOsZckHHb2RzPbIRn3lxTG/b6WbmNNFZ0IZnYciuOLTs/b321S8JFAEKoUUJ3MrzkD8uCoNFnu9bILXiSkABB89ARgwiiZVInHaA514/LzPDO4jlF4y64yO22OO5pxq+lNnv7UyEONRih392/R9zQWq5vxfptmHnV/0WIPe1L6Wnow+92A1c0K/HQr9KJTA5yjX9anof79WHIYKaNApUaN+YZaep1o9tPwCST7h0VI8e+6WXcw1Y+EWexaivMGDmsGvSsPdprhPSzDdgBUyqzgtCFF4LsJBhEcl+joZShlMX62WMIPoJv1Ce1qdP5Ss=","x-forefront-antispam-report":"CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:BN9PR11MB5483.namprd11.prod.outlook.com; PTR:; CAT:NONE;\n SFS:(13230031)(396003)(376002)(136003)(346002)(366004)(39860400002)(230922051799003)(186009)(451199024)(64100799003)(1800799012)(66556008)(66476007)(66946007)(110136005)(76116006)(316002)(66446008)(54906003)(64756008)(53546011)(7696005)(9686003)(6506007)(26005)(107886003)(966005)(478600001)(71200400001)(38100700002)(82960400001)(122000001)(83380400001)(33656002)(86362001)(38070700009)(55016003)(5660300002)(7416002)(2906002)(8676002)(4326008)(41300700001)(8936002)(52536014);\n DIR:OUT; SFP:1102;","x-ms-exchange-antispam-messagedata-chunkcount":"1","x-ms-exchange-antispam-messagedata-0":"=?utf-8?q?Ry1tV1TT7m2gj2TmMAeUGU0EqL0J?=\n\t=?utf-8?q?ZLBSsKSgyjkwBRJuWT0xxTg2x7DWQ1S1JGIPkcnFO4Z3bXUw4ZGP3hWnFQrq5EzUi?=\n\t=?utf-8?q?KS55ex0Sv0HgOR/+sSdimP+MkvuQ+m+VYvCHH4b4b0VYhifjIP57FkIbjeLOzCXjC?=\n\t=?utf-8?q?gTxeEkZg3CRtftXpMgUjeM7SnCNQrG1DwFtthQunlI57heBRiLU2YG1iEJlepflOq?=\n\t=?utf-8?q?UaK9AC627HqtpNdM6vm/OsUrAMWqBwL5azTkGyXR3c9Ca43o9JksCz/DTrLxKSKyb?=\n\t=?utf-8?q?hw5bF2Ym2MYJE+yz0OqfAi5AnIqzUCs/BpTAPIQqqsIgqrcSD+C2UFIPhQ3hL+8vv?=\n\t=?utf-8?q?wq4PTNa7gHeKVl8219XWr8PhwVS+o3xzaYBhUD4xBaHvblE0qoZ35AM+PtbykTj4l?=\n\t=?utf-8?q?v9728WyjpB5Db93TsuWMPHQUOb7nVHwBQ0kXOGgpko+QFmRo5b6KHc6zDjYcvuakP?=\n\t=?utf-8?q?rqYYFuCtMhe1V9HWkiGjnYfRo4dsaCVzBX+uc/2BHc7tPkOr5soX+tE+sYzMQkifm?=\n\t=?utf-8?q?zmQkclkGJ/ORvdxQPA85kaD7MD2ZR5cV6bucSOWBjglUUdeOp5uU3QI2EtlSLpq7g?=\n\t=?utf-8?q?MCF5dJMv63iv3xRxl8YUdNaGWK4TN/BXhMqZHaJvlsCtmIBKpgWHZMCaLyoYdH4uv?=\n\t=?utf-8?q?UCDxz4S/4rLfMRRxUxdDdo9nydpGt5S8C/SVvE1dALPnVS1yT/j0mebQqYRZ+jCHZ?=\n\t=?utf-8?q?kUYhyFZptzYMsIsT/TG+f1IGqn0HllJG4C4OPCt3IP5Vz/c4T9QP6GE2BkD7n6oY7?=\n\t=?utf-8?q?eJAaCV5Zg9uXZHGi5Ngk+Sd0uxsKpJUAt8feSC5jsjobKYXWR0lJptFlMhFL8i9V7?=\n\t=?utf-8?q?iQ93nHzeOyeA6M7pq57TZ9SdU6Kqrc6lwmL5VEOIe+GBdsEKIuZ9i8rmFvWSJOV3x?=\n\t=?utf-8?q?LKWgiXSUBFbMvJZ901cKloDe8BtdV9KJJNr2Ffx+NziDlsKEvrd0U9CMVOQLIcOcG?=\n\t=?utf-8?q?EqlBAp76nUFBlPpH/kL68MsgQ4mvoAOLKhcEiGowUHykNCz0QdEZBgPSIyHov55dw?=\n\t=?utf-8?q?d6c1sgU/mjsIzOtqVj8IF4LP+UgC+BhwbJ6nMRLPpVn+AW31ImGZT9EGuumXqoZhd?=\n\t=?utf-8?q?NYRUNUhGuL0g0M+7tBWFJeXiY6mFuBv8FXXvTdhSfkKHZj7I4SJaWqKAkeZuIRWvO?=\n\t=?utf-8?q?YDVrFbQXmBmjjdJul50Frk+AGIAqAWWJR0nzEAgjLGmqjedp7eOdPZZmlq/8cQYV7?=\n\t=?utf-8?q?2/TjcIlWTWRAKhlM5fJAUJ+vinB8UzxWyt/t4VlZ6Y+P+RgsS4pjT3RJb1PIP3Wct?=\n\t=?utf-8?q?YiO4SRazVCi5M9rgX7Vk2trS4l0KrUnj3eOCjUkUB3QMFNP+JYpWiM86Z8+9QiQ5J?=\n\t=?utf-8?q?w9efA8bRvO4TRw5iGddkFaj94aue5KRTJ+j0jLOHw3uE6nSVkV0hMuEn1Qcj5j4JM?=\n\t=?utf-8?q?1bRmPF8+A5I1p1VWEB6ENzfZKci1tdoiH0H30NWxLMLqhV6xP1Cv804+zSt0xJpcu?=\n\t=?utf-8?q?+mpIn57cSkTVvrvS0CWwvrYWlthwF+Yk1HCau799+N3QjjqHIu6Xk5mriU/1prdQD?=\n\t=?utf-8?q?rTG4WxoiU1Yx?=","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-MS-Exchange-CrossTenant-AuthAs":"Internal","X-MS-Exchange-CrossTenant-AuthSource":"BN9PR11MB5483.namprd11.prod.outlook.com","X-MS-Exchange-CrossTenant-Network-Message-Id":"\n 11da1951-4fd1-4899-c3c6-08dbeac079fa","X-MS-Exchange-CrossTenant-originalarrivaltime":"21 Nov 2023 18:34:20.4141 (UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"46c98d88-e344-4ed4-8496-4ed7712e255d","X-MS-Exchange-CrossTenant-mailboxtype":"HOSTED","X-MS-Exchange-CrossTenant-userprincipalname":"\n 6w0NSceTsy0E0xig6C87+kuriuBkCmfGz2XrFuEyIgbRk+ihNxZIvtGHTLL5SfOBDTPwDe+JkeL9pb8fbreUag==","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"MW3PR11MB4683","X-OriginatorOrg":"intel.com","X-Mailman-Approved-At":"Tue, 21 Nov 2023 20:46:01 +0100","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3220765,"web_url":"http://patchwork.ozlabs.org/comment/3220765/","msgid":"","list_archive_url":null,"date":"2023-11-21T18:37:41","subject":"RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":87524,"url":"http://patchwork.ozlabs.org/api/people/87524/","name":"Chiu, Chasel","email":"chasel.chiu@intel.com"},"content":"In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for related example code.\n\nThanks,\nChasel\n\n\n> -----Original Message-----\n> From: Chiu, Chasel\n> Sent: Tuesday, November 21, 2023 10:34 AM\n> To: Ard Biesheuvel ; Simon Glass \n> Cc: devicetree@vger.kernel.org; Mark Rutland ; Rob\n> Herring ; Tan, Lean Sheng ; lkml\n> ; Dhaval Sharma ; Brune,\n> Maximilian ; Yunhui Cui\n> ; Dong, Guo ; Tom Rini\n> ; ron minnich ; Guo, Gua\n> ; linux-acpi@vger.kernel.org; U-Boot Mailing List boot@lists.denx.de>; Chiu, Chasel \n> Subject: RE: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> usages\n> \n> \n> Hi Ard,\n> \n> Here is the POC PR for your reference:\n> https://github.com/tianocore/edk2/pull/4969/files#diff-\n> ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR26\n> 8\n> Please note that this PR is still in early phase and expected to have significant\n> changes.\n> \n> The idea is that payload entry will create gEfiMemoryTypeInformationGuid HOB\n> with payload default memory types and allow FDT to override if correspond node\n> present.\n> Please let me know if you have questions or suggestions.\n> \n> Thanks,\n> Chasel\n> \n> \n> > -----Original Message-----\n> > From: Ard Biesheuvel \n> > Sent: Tuesday, November 21, 2023 8:42 AM\n> > To: Simon Glass \n> > Cc: Chiu, Chasel ; devicetree@vger.kernel.org;\n> > Mark Rutland ; Rob Herring ;\n> > Tan, Lean Sheng ; lkml\n> > ; Dhaval Sharma ;\n> > Brune, Maximilian ; Yunhui Cui\n> > ; Dong, Guo ; Tom Rini\n> > ; ron minnich ; Guo, Gua\n> > ; linux- acpi@vger.kernel.org; U-Boot Mailing List\n> > \n> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> > usages\n> >\n> > On Mon, 20 Nov 2023 at 21:12, Simon Glass wrote:\n> > >\n> > > Hi,\n> > >\n> > > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel wrote:\n> > > >\n> > > >\n> > > > Hi Ard,\n> > > >\n> > > > Please see my reply below inline.\n> > > >\n> > > > Thanks,\n> > > > Chasel\n> > > >\n> > > >\n> > > > > -----Original Message-----\n> > > > > From: Ard Biesheuvel \n> > > > > Sent: Saturday, November 11, 2023 3:04 AM\n> > > > > To: Chiu, Chasel \n> > > > > Cc: Simon Glass ; devicetree@vger.kernel.org;\n> > > > > Mark Rutland ; Rob Herring\n> > > > > ; Tan, Lean Sheng ;\n> > > > > lkml ; Dhaval Sharma\n> > > > > ; Brune, Maximilian\n> > > > > ; Yunhui Cui\n> > > > > ; Dong, Guo ; Tom\n> > > > > Rini ; ron minnich ;\n> > > > > Guo, Gua ; linux- acpi@vger.kernel.org;\n> > > > > U-Boot Mailing List \n> > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common\n> > > > > reserved-memory usages\n> > > > >\n> > > > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel \n> wrote:\n> > > > > >\n> > > > > >\n> > > > > > Just sharing some usage examples from UEFI/EDK2 scenario.\n> > > > > > To support ACPI S4/Hibernation, memory map must be consistent\n> > > > > > before entering and after resuming from S4, in this case\n> > > > > > payload may need to know previous memory map from bootloader\n> > > > > > (currently generic payload cannot access platform/bootloader\n> > > > > > specific non-volatile data, thus could not save/restore memory\n> > > > > > map\n> > > > > > information)\n> > > > >\n> > > > > So how would EDK2 reconstruct the entire EFI memory map from\n> > > > > just these unannotated /reserved-memory nodes? The EFI memory\n> > > > > map contains much more information than that, and all of it has\n> > > > > to match the pre-hibernate situation, right? Can you given an example?\n> > > >\n> > > >\n> > > > Here we listed only typically memory types that may change cross\n> > > > different\n> > platforms.\n> > > > Reserved memory type already can be handled by reserved-memory\n> > > > node,\n> > and rest of the types usually no need to change cross platforms thus\n> > currently we could rely on default in generic payload.\n> > > > In the future if we see a need to add new memory types we will\n> > > > discuss and\n> > add it to FDT schema.\n> > > >\n> > > >\n> > > >\n> > > > >\n> > > > > > Another usage is to support binary model which generic payload\n> > > > > > is a prebuilt\n> > > > > binary compatible for all platforms/configurations, however the\n> > > > > payload default memory map might not always work for all the\n> > > > > configurations and we want to allow bootloader to override\n> > > > > payload default\n> > memory map without recompiling.\n> > > > > >\n> > > > >\n> > > > > Agreed. But can you explain how a EDK2 payload might make\n> > > > > meaningful use of 'runtime-code' regions provided via DT by the\n> > > > > non-EDK2 platform init? Can you give an example?\n> > > >\n> > > >\n> > > > Runtime-code/data is used by UEFI payload for booting UEFI OS\n> > > > which\n> > required UEFI runtime services.\n> > > > Platform Init will select some regions from the usable memory and\n> > > > assign it to\n> > runtime-code/data for UPL to consume. Or assign same runtime-code/data\n> > from previous boot.\n> > > > If UEFI OS is not supported, PlatformInit may not need to provide\n> > > > runtime-code/data regions to payload. (always providing\n> > > > runtime-code/data should be supported too)\n> > > >\n> > > >\n> > > > >\n> > > > > > Under below assumption:\n> > > > > > FDT OS impact has been evaluated and taken care by\n> > > > > > relevant\n> > > > > experts/stakeholders.\n> > > > > > Reviewed-by: Chasel Chiu \n> > > > > >\n> > > > >\n> > > > > I am sorry but I don't know what 'FDT OS impact' means. We are\n> > > > > talking about a firmware-to-firmware abstraction that has the\n> > > > > potential to leak into the OS visible interface.\n> > > > >\n> > > > > I am a maintainer in the Tianocore project myself, so it would\n> > > > > help if you could explain who these relevant experts and\n> > > > > stakeholders are. Was this discussed on the edk2-devel mailing\n> > > > > list? If so, apologies for missing it but I may not have been cc'ed perhaps?\n> > > >\n> > > >\n> > > >\n> > > >\n> > > > I'm not familiar with FDT OS, also I do not know if who from\n> > > > edk2-devel were\n> > supporting FDT OS, I think Simon might be able to connect FDT OS\n> > experts/stakeholders.\n> > > > We are mostly focusing on payload firmware phase implementation in\n> > > > edk2 (and other payloads too), however, since we have aligned the\n> > > > payload FDT and OS FDT months ago, I'm assuming FDT OS impact must\n> > > > be there and we need (or already done?) FDT OS experts to support\n> > > > it. (again, maybe Simon could share more information about FDT OS)\n> > > >\n> > > > In edk2 such FDT schema is UefiPayloadPkg internal usage only and\n> > > > payload\n> > entry will convert FDT into HOB thus we expected the most of the edk2\n> > generic code are no-touch/no impact, that's why we only had small\n> > group\n> > (UefiPayloadPkg) discussion.\n> > > > Ard, if you are aware of any edk2 code that's for supporting FDT\n> > > > OS, please let\n> > us know and we can discuss if those code were impacted or not.\n> > >\n> > > We discussed this and just to clarify, 'FDT OS' is not a special OS,\n> > > it is just Linux.\n> > >\n> > > So, with the above, are we all on the same page? Can the patch be\n> > > applied, perhaps? If not, what other discussion is needed?\n> > >\n> >\n> > An example of how a platform-init/payload combination would make\n> > meaningful use of such runtime-code/data regions.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=Cw5EiFze;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=85.214.62.61; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.b=\"Cw5EiFze\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=chasel.chiu@intel.com","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=intel.com;"],"Received":["from phobos.denx.de (phobos.denx.de [85.214.62.61])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SZZdF6Bzvz1yRV\n\tfor ; Wed, 22 Nov 2023 06:46:41 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 14C7187631;\n\tTue, 21 Nov 2023 20:46:05 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id 6DCF58269F; Tue, 21 Nov 2023 19:37:51 +0100 (CET)","from mgamail.intel.com (mgamail.intel.com [192.55.52.43])\n (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 9DAF7875C7\n for ; Tue, 21 Nov 2023 19:37:47 +0100 (CET)","from orsmga006.jf.intel.com ([10.7.209.51])\n by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 21 Nov 2023 10:37:45 -0800","from orsmsx601.amr.corp.intel.com ([10.22.229.14])\n by orsmga006.jf.intel.com with ESMTP/TLS/AES256-GCM-SHA384;\n 21 Nov 2023 10:37:45 -0800","from orsmsx602.amr.corp.intel.com (10.22.229.15) by\n ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.2507.34; Tue, 21 Nov 2023 10:37:44 -0800","from ORSEDG601.ED.cps.intel.com (10.7.248.6) by\n orsmsx602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.2507.34 via Frontend Transport; Tue, 21 Nov 2023 10:37:44 -0800","from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.101)\n by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.1.2507.34; Tue, 21 Nov 2023 10:37:44 -0800","from BN9PR11MB5483.namprd11.prod.outlook.com (2603:10b6:408:104::10)\n by SA0PR11MB4624.namprd11.prod.outlook.com (2603:10b6:806:98::19)\n with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.28; Tue, 21 Nov\n 2023 18:37:41 +0000","from BN9PR11MB5483.namprd11.prod.outlook.com\n ([fe80::6da1:a4b7:4771:14e1]) by BN9PR11MB5483.namprd11.prod.outlook.com\n ([fe80::6da1:a4b7:4771:14e1%4]) with mapi id 15.20.7002.028; Tue, 21 Nov 2023\n 18:37:41 +0000"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no\n version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1700591867; x=1732127867;\n h=from:to:cc:subject:date:message-id:references:\n in-reply-to:content-transfer-encoding:mime-version;\n bh=YxhJ3USLrW2jb0HSNDtG0XdPEyiGLqChKTawrPuPgtM=;\n b=Cw5EiFze3njupdldsqvF+G1tJZggHgo/VX7kmuMfFPTRGijuQ6qB+WcK\n toTOq+n+DuFKrS15NseYX3crK/IkgY2DCCZvrB8123sUqU+Wl3sEimwf5\n i69vt5dknXAWDycBauazpY8Lrys4lx/beNN3qafegTKZM2r3Xwdz1cPsL\n mtC3K72sWf/HZZZW6N9au8VQ5SKEUIQPDHvB/fQazWGZK994EKHRB3d91\n rXhWm22tjm4FhlMXWmzzBLJmHRDBaF1d2F4oZA2sOA5mEO+Q5FWve2ji9\n TCREYVkW2ob46jaY50MkntCQtFPqxFrfh3/EHxL3Y4IyKSK1tbGfOEneB w==;","X-IronPort-AV":["E=McAfee;i=\"6600,9927,10901\"; a=\"478109650\"","E=Sophos;i=\"6.04,216,1695711600\"; d=\"scan'208\";a=\"478109650\"","E=McAfee;i=\"6600,9927,10901\"; a=\"743136571\"","E=Sophos;i=\"6.04,216,1695711600\"; d=\"scan'208\";a=\"743136571\""],"X-ExtLoop1":"1","ARC-Seal":"i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=RfVTz1mew4G4nax3zcAmyrxVM3w8luRR1pjhY+U/88ecfC+HxSPVbQ3HDJrri1P65eD5XWrALfcDPgWy5Gi/4IFbGaQRG//fjHuJp43gU29QJiokaeyawrZUTOi3toVdpBlLmmZObNgRu4P4gFFt4T+qlx0I6PdR+MrIylYUGZVBFKzST7J1yP6A574mIpAX4YuIkxeIeAmoW6du7k25lpDOmuFRFbunSciMJDw+jI24frui1a29jIz0O4UYNH9CVKCJ9xJ+/09vX/HscNesq1Wv0H3ZSl9qHkvJVeHQTi8dFbvz8M9svxNRW7IMqoKP4Rq/xARZYCcY3IQp6pZZGQ==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;\n bh=YxhJ3USLrW2jb0HSNDtG0XdPEyiGLqChKTawrPuPgtM=;\n b=HuXqMB3i3s5O9+mBu0zkaHToPYpucP9D/dBipsWsDta9qsU1RkxA+kU/Ngp4nA19D9EchRiGZQv+4IMr66JzVriEKTawGjmAO2m5CI665zVOWhoW54rTqxg1x8A0yUJx1LROA2LOgY6ggYOeRjE2FtlTbNwpee82+O2Nq7+++yvSdQ4rLBahUxHNPJ9UM1c8Exe6FzYdcOVG8sjnuCl9AENVMErVRlCkhpN1sy08BgufK19m9ASM/stYsqn4Lw5635xedv3qRi8XHG9Wwp2Ji1q10dkFDX14Ifh7NVC+btFt1UBT3Xep9B048ukvJhHJIGr0WwKPCfT/E5l3B/3LVA==","ARC-Authentication-Results":"i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none","From":"\"Chiu, Chasel\" ","To":"Ard Biesheuvel , Simon Glass ","CC":"\"devicetree@vger.kernel.org\" , Mark Rutland\n , Rob Herring , \"Tan, Lean Sheng\"\n , lkml , Dhaval Sharma\n , \"Brune, Maximilian\" ,\n Yunhui Cui , \"Dong, Guo\" , \"Tom\n Rini\" , ron minnich , \"Guo, Gua\"\n , \"linux-acpi@vger.kernel.org\"\n , U-Boot Mailing List ,\n \"Chiu, Chasel\" ","Subject":"RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","Thread-Topic":"[PATCH v7 2/2] schemas: Add some common reserved-memory usages","Thread-Index":"\n AQHZ8LGvpttG6mvEz0WlU57NBrVnTbB0GT1wgAEi2gCAA4/1oIALktuAgADzAICAABvkkIAABCKw","Date":"Tue, 21 Nov 2023 18:37:41 +0000","Message-ID":"\n ","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n ","In-Reply-To":"\n ","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","authentication-results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=Cw5EiFze;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=85.214.62.61; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.b=\"Cw5EiFze\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=chasel.chiu@intel.com","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=intel.com;"],"x-ms-publictraffictype":"Email","x-ms-traffictypediagnostic":"BN9PR11MB5483:EE_|SA0PR11MB4624:EE_","x-ms-office365-filtering-correlation-id":"43be3aa0-df01-49d4-f83d-08dbeac0f208","x-ld-processed":"46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr","x-ms-exchange-senderadcheck":"1","x-ms-exchange-antispam-relay":"0","x-microsoft-antispam":"BCL:0;","x-microsoft-antispam-message-info":"\n o0lqYw9JA6cHvrV8dSF+SATDmz1FPrjZ7gARutUIWCswNK2R8O/C+9DqGhtEibPNN3EPKlb6yOSworN+XGCPR46rJ/KfkSNqeS2coLEDfjT+GMJptlTRHRPPIj1xogrNxBCTgcWH9sf6+EVcnX9InLP+b75pORpY1EhwwqkXaESpJyew5kTM956H6VqqTRsE5DfHImB/8hEfsglpkOHFln+0ihcKGPRzN44p1leMs37ckYsbQRIipcLN9WmQOSWvZ869RsXP/qNzC/5fS3EkhZH9l+tmW8ieO97vNYSJjBBnwjj13vvOg8vCpgeiOhCiqdYPyQYtsJjzURNEUsR6tjrCGNB6Z6Bv94BiQr0fSyn07tvcCJ8fd1+JaqF96k7A6m0ceox3P0mR2ziByhp2opnABWT86iIPhr0MvsjpEYL04Z94bfGZ/7nH4Qn+E6ix9vWdmEW4yU3Y8nfGBiBAlJ69GGqM4jCrbA6HHKiHLpifyduwMFlJF4d8MIkvs61/yDUw0qPlgUOyLNJrSWoM2hDx1rl1ZcgoDUQyBtfPDVVzl/2lkKXzpu7yVYX3LH+bdZWRdbGMIhMDSMN9B9HC4tM1YzRPFE41IYVPkq8v+5w=","x-forefront-antispam-report":"CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:BN9PR11MB5483.namprd11.prod.outlook.com; PTR:; CAT:NONE;\n SFS:(13230031)(346002)(366004)(376002)(136003)(396003)(39860400002)(230922051799003)(64100799003)(451199024)(186009)(1800799012)(2906002)(33656002)(52536014)(8676002)(8936002)(4326008)(5660300002)(38100700002)(86362001)(7416002)(38070700009)(41300700001)(2940100002)(107886003)(9686003)(55016003)(71200400001)(26005)(6506007)(53546011)(7696005)(83380400001)(82960400001)(478600001)(122000001)(66946007)(110136005)(66556008)(66446008)(64756008)(66476007)(54906003)(76116006)(316002)(966005);\n DIR:OUT; SFP:1102;","x-ms-exchange-antispam-messagedata-chunkcount":"1","x-ms-exchange-antispam-messagedata-0":"=?utf-8?q?SG0b6wD8IGWgKnrlcw7JtQ0zV6P2?=\n\t=?utf-8?q?7T1Sk6hDStjkusOtzcsPAwV+iVjQbOAv/R+OhwRFJ6iN4V4YZkzaiYj4g478uJbLx?=\n\t=?utf-8?q?Kg2z1ivZmvGBFNHdxBUL/BcC9a+rd73Z2ROnb1pxJEvTFOuB5jvQwPxhyJSmw3Fr5?=\n\t=?utf-8?q?U07HCQph5FHzBqUfLPI0jlQjbaH8VR4lBSePeeEmADvSjYqzk1n4IG9XwXTZpuVNQ?=\n\t=?utf-8?q?tBpKUEn5EgWLUBw/a48CEE4fQVAvnF0n01FDJJ6g1vVbs2TL4GgjwXCpohbsEcZcg?=\n\t=?utf-8?q?PtiMvgde2bosxzShUbQpdU+iCl5tWLfKLk5ZKUZekUlCaEM19UzKENdrdJ2XkjZ5O?=\n\t=?utf-8?q?jj5flDBP02bppaOfpbUP0L0hZhelTfcYaBiSNL51Z+T/ZpQJK0FmKOBMWKYjZhbSl?=\n\t=?utf-8?q?jRo0NCUTQDZNvgRm2JXzPgGIgad8B6Y3cdauTrG3f4gkNuLVTjmA27A4RoFepgwOO?=\n\t=?utf-8?q?aNAMkSNpxNz41KoPAC14FquGApszZPB7HU+ErBDgGUehTKI0LTWbNVbm4ckEcsWn9?=\n\t=?utf-8?q?MGfewHDXgSsk+2mxn9PCX2FBpePSAKzjO2ayncW++KArJwpNIEPBEu3mCtUGSlEg3?=\n\t=?utf-8?q?fTG9c7QR/9M1yBURvSoAVSF/Q7PD8srZAgyKKDEfiH592m3sY+yirOMNEyeD/7d6f?=\n\t=?utf-8?q?2rlswKy97IDDOk+b1qEJsJP1ZTsjcTbm0sW5ql3G4H+gzkSkvP0HaWD8JOFpcz5nR?=\n\t=?utf-8?q?jZGf66M5dFhog/KxpbXET6PzOqagujKpqPLDjcwoJDDJ/xI+OJ4zzAk+P1Jz0UQts?=\n\t=?utf-8?q?11CxQXbfE+421FsW7MEshRBHaP89UBXnDAVlFiqAfe8WDWwcYEvG4c9DAYo1dLrza?=\n\t=?utf-8?q?lLkIStE3Q0UL5SSsI5FswjxqvpE9m6uVog0xWf4h5gGWmsgAtA+H8fq/3JTQ3XNqM?=\n\t=?utf-8?q?JiDaixNUPYnobSeb7EcomWvfIk01xtXZTJx3pEbFkTFOPYFLFaaX653Afu/A6Ku1r?=\n\t=?utf-8?q?9Z+hNm81a0zcXdgyQZyT3H62S3xqHrMwunoBrgpNAdUh2lB+r++UAox/azsa01fUg?=\n\t=?utf-8?q?M9qRwWi3usGekgaaUJhFDE5PmT+Hv8V2bcphtz9WCaw0NTQucg5lX3KVvB/kbA8Cr?=\n\t=?utf-8?q?b+MaARhtrHPN9XStN4WW2+rB5/JimtuOz9H7RbwfKdf0gRQ0IyR+i8dTA2XxoIMVO?=\n\t=?utf-8?q?OlgrSongL1XZ9d/TBAiIKIpcoDcezn3jINJK5lvH6gdNa4uyq4mw6C9jpLRGjW+hH?=\n\t=?utf-8?q?fUF1wgsbSRDOpWXoZEkDUHX/p6KUYjq8hiTSHScuvMLmV9vawIirQbahGmM+Hp/nC?=\n\t=?utf-8?q?NfhI108jhEV6dE7OOZ0sPDGgg6XaPfTdk0KFcItf7/mw/clZXJeJh1HBki/5Q8vzw?=\n\t=?utf-8?q?NZuOF8w4BmZ+fzpl9imN6lGfUQBdTzFuu41P5pMXkXkVy1slZAp3VACtqRCSk9KKO?=\n\t=?utf-8?q?ScrIhTG92fcIQKmvGbaCuOqZWmEBzzK2y4yHfUHVbLUyWI6FohPoFo4jZeywRLyuV?=\n\t=?utf-8?q?5IJ6mPnyeamHjYjF+9EhnC4aMTLJd+gHuslGIF49KdEHOhxHJxuvOuQJk+1QMpW0N?=\n\t=?utf-8?q?SBL5tA4KWJ2R?=","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-MS-Exchange-CrossTenant-AuthAs":"Internal","X-MS-Exchange-CrossTenant-AuthSource":"BN9PR11MB5483.namprd11.prod.outlook.com","X-MS-Exchange-CrossTenant-Network-Message-Id":"\n 43be3aa0-df01-49d4-f83d-08dbeac0f208","X-MS-Exchange-CrossTenant-originalarrivaltime":"21 Nov 2023 18:37:41.8020 (UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"46c98d88-e344-4ed4-8496-4ed7712e255d","X-MS-Exchange-CrossTenant-mailboxtype":"HOSTED","X-MS-Exchange-CrossTenant-userprincipalname":"\n P1OTONkZkDUHPITf/LAdZ48mGQAu+CZPmDkAHfDgzO+Mk3758mTfXRSGa2T1hcd7sO/nPGhc6RHE77DdaZSO5w==","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"SA0PR11MB4624","X-OriginatorOrg":"intel.com","X-Mailman-Approved-At":"Tue, 21 Nov 2023 20:46:01 +0100","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3224574,"web_url":"http://patchwork.ozlabs.org/comment/3224574/","msgid":"","list_archive_url":null,"date":"2023-11-28T18:07:50","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":77831,"url":"http://patchwork.ozlabs.org/api/people/77831/","name":"Ard Biesheuvel","email":"ardb@kernel.org"},"content":"You are referring to a 2000 line patch so it is not 100% clear where\nto look tbh.\n\n\nOn Tue, 21 Nov 2023 at 19:37, Chiu, Chasel wrote:\n>\n>\n> In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for related example code.\n>\n\nThat refers to a 'memory-allocation' node, right? How does that relate\nto the 'reserved-memory' node?\n\nAnd crucially, how does this clarify in which way \"runtime-code\" and\n\"runtime-data\" reservations are being used?\n\nSince the very beginning of this discussion, I have been asking\nrepeatedly for examples that describe the wider context in which these\nreservations are used. The \"runtime\" into runtime-code and\nruntime-data means that these regions have a special significance to\nthe operating system, not just to the next bootloader stage. So I want\nto understand exactly why it is necessary to describe these regions in\na way where the operating system might be expected to interpret this\ninformation and act upon it.\n\n\n>\n> > -----Original Message-----\n> > From: Chiu, Chasel\n> > Sent: Tuesday, November 21, 2023 10:34 AM\n> > To: Ard Biesheuvel ; Simon Glass \n> > Cc: devicetree@vger.kernel.org; Mark Rutland ; Rob\n> > Herring ; Tan, Lean Sheng ; lkml\n> > ; Dhaval Sharma ; Brune,\n> > Maximilian ; Yunhui Cui\n> > ; Dong, Guo ; Tom Rini\n> > ; ron minnich ; Guo, Gua\n> > ; linux-acpi@vger.kernel.org; U-Boot Mailing List > boot@lists.denx.de>; Chiu, Chasel \n> > Subject: RE: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> > usages\n> >\n> >\n> > Hi Ard,\n> >\n> > Here is the POC PR for your reference:\n> > https://github.com/tianocore/edk2/pull/4969/files#diff-\n> > ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR26\n> > 8\n> > Please note that this PR is still in early phase and expected to have significant\n> > changes.\n> >\n> > The idea is that payload entry will create gEfiMemoryTypeInformationGuid HOB\n> > with payload default memory types and allow FDT to override if correspond node\n> > present.\n> > Please let me know if you have questions or suggestions.\n> >\n> > Thanks,\n> > Chasel\n> >\n> >\n> > > -----Original Message-----\n> > > From: Ard Biesheuvel \n> > > Sent: Tuesday, November 21, 2023 8:42 AM\n> > > To: Simon Glass \n> > > Cc: Chiu, Chasel ; devicetree@vger.kernel.org;\n> > > Mark Rutland ; Rob Herring ;\n> > > Tan, Lean Sheng ; lkml\n> > > ; Dhaval Sharma ;\n> > > Brune, Maximilian ; Yunhui Cui\n> > > ; Dong, Guo ; Tom Rini\n> > > ; ron minnich ; Guo, Gua\n> > > ; linux- acpi@vger.kernel.org; U-Boot Mailing List\n> > > \n> > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> > > usages\n> > >\n> > > On Mon, 20 Nov 2023 at 21:12, Simon Glass wrote:\n> > > >\n> > > > Hi,\n> > > >\n> > > > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel wrote:\n> > > > >\n> > > > >\n> > > > > Hi Ard,\n> > > > >\n> > > > > Please see my reply below inline.\n> > > > >\n> > > > > Thanks,\n> > > > > Chasel\n> > > > >\n> > > > >\n> > > > > > -----Original Message-----\n> > > > > > From: Ard Biesheuvel \n> > > > > > Sent: Saturday, November 11, 2023 3:04 AM\n> > > > > > To: Chiu, Chasel \n> > > > > > Cc: Simon Glass ; devicetree@vger.kernel.org;\n> > > > > > Mark Rutland ; Rob Herring\n> > > > > > ; Tan, Lean Sheng ;\n> > > > > > lkml ; Dhaval Sharma\n> > > > > > ; Brune, Maximilian\n> > > > > > ; Yunhui Cui\n> > > > > > ; Dong, Guo ; Tom\n> > > > > > Rini ; ron minnich ;\n> > > > > > Guo, Gua ; linux- acpi@vger.kernel.org;\n> > > > > > U-Boot Mailing List \n> > > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common\n> > > > > > reserved-memory usages\n> > > > > >\n> > > > > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel \n> > wrote:\n> > > > > > >\n> > > > > > >\n> > > > > > > Just sharing some usage examples from UEFI/EDK2 scenario.\n> > > > > > > To support ACPI S4/Hibernation, memory map must be consistent\n> > > > > > > before entering and after resuming from S4, in this case\n> > > > > > > payload may need to know previous memory map from bootloader\n> > > > > > > (currently generic payload cannot access platform/bootloader\n> > > > > > > specific non-volatile data, thus could not save/restore memory\n> > > > > > > map\n> > > > > > > information)\n> > > > > >\n> > > > > > So how would EDK2 reconstruct the entire EFI memory map from\n> > > > > > just these unannotated /reserved-memory nodes? The EFI memory\n> > > > > > map contains much more information than that, and all of it has\n> > > > > > to match the pre-hibernate situation, right? Can you given an example?\n> > > > >\n> > > > >\n> > > > > Here we listed only typically memory types that may change cross\n> > > > > different\n> > > platforms.\n> > > > > Reserved memory type already can be handled by reserved-memory\n> > > > > node,\n> > > and rest of the types usually no need to change cross platforms thus\n> > > currently we could rely on default in generic payload.\n> > > > > In the future if we see a need to add new memory types we will\n> > > > > discuss and\n> > > add it to FDT schema.\n> > > > >\n> > > > >\n> > > > >\n> > > > > >\n> > > > > > > Another usage is to support binary model which generic payload\n> > > > > > > is a prebuilt\n> > > > > > binary compatible for all platforms/configurations, however the\n> > > > > > payload default memory map might not always work for all the\n> > > > > > configurations and we want to allow bootloader to override\n> > > > > > payload default\n> > > memory map without recompiling.\n> > > > > > >\n> > > > > >\n> > > > > > Agreed. But can you explain how a EDK2 payload might make\n> > > > > > meaningful use of 'runtime-code' regions provided via DT by the\n> > > > > > non-EDK2 platform init? Can you give an example?\n> > > > >\n> > > > >\n> > > > > Runtime-code/data is used by UEFI payload for booting UEFI OS\n> > > > > which\n> > > required UEFI runtime services.\n> > > > > Platform Init will select some regions from the usable memory and\n> > > > > assign it to\n> > > runtime-code/data for UPL to consume. Or assign same runtime-code/data\n> > > from previous boot.\n> > > > > If UEFI OS is not supported, PlatformInit may not need to provide\n> > > > > runtime-code/data regions to payload. (always providing\n> > > > > runtime-code/data should be supported too)\n> > > > >\n> > > > >\n> > > > > >\n> > > > > > > Under below assumption:\n> > > > > > > FDT OS impact has been evaluated and taken care by\n> > > > > > > relevant\n> > > > > > experts/stakeholders.\n> > > > > > > Reviewed-by: Chasel Chiu \n> > > > > > >\n> > > > > >\n> > > > > > I am sorry but I don't know what 'FDT OS impact' means. We are\n> > > > > > talking about a firmware-to-firmware abstraction that has the\n> > > > > > potential to leak into the OS visible interface.\n> > > > > >\n> > > > > > I am a maintainer in the Tianocore project myself, so it would\n> > > > > > help if you could explain who these relevant experts and\n> > > > > > stakeholders are. Was this discussed on the edk2-devel mailing\n> > > > > > list? If so, apologies for missing it but I may not have been cc'ed perhaps?\n> > > > >\n> > > > >\n> > > > >\n> > > > >\n> > > > > I'm not familiar with FDT OS, also I do not know if who from\n> > > > > edk2-devel were\n> > > supporting FDT OS, I think Simon might be able to connect FDT OS\n> > > experts/stakeholders.\n> > > > > We are mostly focusing on payload firmware phase implementation in\n> > > > > edk2 (and other payloads too), however, since we have aligned the\n> > > > > payload FDT and OS FDT months ago, I'm assuming FDT OS impact must\n> > > > > be there and we need (or already done?) FDT OS experts to support\n> > > > > it. (again, maybe Simon could share more information about FDT OS)\n> > > > >\n> > > > > In edk2 such FDT schema is UefiPayloadPkg internal usage only and\n> > > > > payload\n> > > entry will convert FDT into HOB thus we expected the most of the edk2\n> > > generic code are no-touch/no impact, that's why we only had small\n> > > group\n> > > (UefiPayloadPkg) discussion.\n> > > > > Ard, if you are aware of any edk2 code that's for supporting FDT\n> > > > > OS, please let\n> > > us know and we can discuss if those code were impacted or not.\n> > > >\n> > > > We discussed this and just to clarify, 'FDT OS' is not a special OS,\n> > > > it is just Linux.\n> > > >\n> > > > So, with the above, are we all on the same page? Can the patch be\n> > > > applied, perhaps? If not, what other discussion is needed?\n> > > >\n> > >\n> > > An example of how a platform-init/payload combination would make\n> > > meaningful use of such runtime-code/data regions.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=XWiG9o0D;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.b=\"XWiG9o0D\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de; spf=pass smtp.mailfrom=ardb@kernel.org"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4Sfr6Q4H0rz1yST\n\tfor ; Wed, 29 Nov 2023 05:08:14 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id BDBC687753;\n\tTue, 28 Nov 2023 19:08:10 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id 7EEE18776F; Tue, 28 Nov 2023 19:08:10 +0100 (CET)","from dfw.source.kernel.org (dfw.source.kernel.org\n [IPv6:2604:1380:4641:c500::1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 49A2D86F67\n for ; Tue, 28 Nov 2023 19:08:06 +0100 (CET)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by dfw.source.kernel.org (Postfix) with ESMTP id 8449261874\n for ; Tue, 28 Nov 2023 18:08:04 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id D76BEC43397\n for ; Tue, 28 Nov 2023 18:08:03 +0000 (UTC)","by mail-lj1-f169.google.com with SMTP id\n 38308e7fff4ca-2c87adce180so71569511fa.0\n for ; Tue, 28 Nov 2023 10:08:03 -0800 (PST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no\n version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1701194883;\n bh=4DwB38wbaKFqe7hUkjoK0KTOX2HU0BmeTqXJcyORlu4=;\n h=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n b=XWiG9o0Dtq787TusZ2eK1KJKrxDR6ZWsvWOUs1UhQwi/EqTGjSVzPy1M+BcivIXz8\n nKM4NnDzVmlPy4d56Q2UCesllUtMPZGL/0QkX7IMNeaphkjFm2UDe7x33QM08aSyNg\n HT+7MRyZ5Ty1ggpvUZ0/+5D4vejZIgr5QVPyS7fPyIAE7W8mxdCvLJL9bT57/U9ZSM\n 5KfMaTnpcjctst3YM+476nbFzErxYqznvVsXBJ+2Ovg6wsBotr7yBLXpwoWP9LvQci\n glX1WDuLypxtZc6NAtIkU+q16SZ7p4PwqSyOVYlSslQcaGx7xyqM26ZGNPB+3i2to5\n XGQqVb9QkNvWQ==","X-Gm-Message-State":"AOJu0YytOIIizyiyjRYBOz8lxkdotiMJ8XGkd3qr2MptcBVR0d3wOyzE\n h32NF47ubZZBBiQXjP1+rCu1+S0xoDB1TXAozpc=","X-Google-Smtp-Source":"\n AGHT+IEMmvfyq0v5/2oBeBE/oqLc1Eu+CJpsjOxQOhU1mp+t/ys+FzWHNt4xUEoc92KVGBiOkt8B0IacbD0oqbAchGI=","X-Received":"by 2002:a2e:b0e1:0:b0:2c9:b9db:73 with SMTP id\n h1-20020a2eb0e1000000b002c9b9db0073mr988987ljl.20.1701194881929;\n Tue, 28 Nov 2023 10:08:01 -0800 (PST)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Ard Biesheuvel ","Date":"Tue, 28 Nov 2023 19:07:50 +0100","X-Gmail-Original-Message-ID":"\n ","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"\"Chiu, Chasel\" ","Cc":"Simon Glass ,\n \"devicetree@vger.kernel.org\" ,\n Mark Rutland ,\n Rob Herring , \"Tan, Lean Sheng\" ,\n lkml , Dhaval Sharma ,\n \"Brune, Maximilian\" ,\n Yunhui Cui ,\n \"Dong, Guo\" , Tom Rini ,\n ron minnich , \"Guo, Gua\" ,\n \"linux-acpi@vger.kernel.org\" ,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3224636,"web_url":"http://patchwork.ozlabs.org/comment/3224636/","msgid":"","list_archive_url":null,"date":"2023-11-28T20:30:49","subject":"RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":87524,"url":"http://patchwork.ozlabs.org/api/people/87524/","name":"Chiu, Chasel","email":"chasel.chiu@intel.com"},"content":"> -----Original Message-----\n> From: Ard Biesheuvel \n> Sent: Tuesday, November 28, 2023 10:08 AM\n> To: Chiu, Chasel \n> Cc: Simon Glass ; devicetree@vger.kernel.org; Mark Rutland\n> ; Rob Herring ; Tan, Lean Sheng\n> ; lkml ; Dhaval\n> Sharma ; Brune, Maximilian\n> ; Yunhui Cui ;\n> Dong, Guo ; Tom Rini ; ron minnich\n> ; Guo, Gua ; linux-\n> acpi@vger.kernel.org; U-Boot Mailing List \n> Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> usages\n> \n> You are referring to a 2000 line patch so it is not 100% clear where to look tbh.\n> \n> \n> On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel wrote:\n> >\n> >\n> > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for\n> related example code.\n> >\n> \n> That refers to a 'memory-allocation' node, right? How does that relate to the\n> 'reserved-memory' node?\n> \n> And crucially, how does this clarify in which way \"runtime-code\" and \"runtime-\n> data\" reservations are being used?\n> \n> Since the very beginning of this discussion, I have been asking repeatedly for\n> examples that describe the wider context in which these reservations are used.\n> The \"runtime\" into runtime-code and runtime-data means that these regions have\n> a special significance to the operating system, not just to the next bootloader\n> stage. So I want to understand exactly why it is necessary to describe these\n> regions in a way where the operating system might be expected to interpret this\n> information and act upon it.\n> \n\n\nI think runtime code and data today are mainly for supporting UEFI runtime services - some BIOS functions for OS to utilize, OS may follow below ACPI spec to treat them as reserved range:\nhttps://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#uefi-memory-types-and-mapping-to-acpi-address-range-types\n\nLike I mentioned earlier, that PR is still in early phase and has not reflected all the required changes yet, but the idea is to build gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes.\nUEFI generic Payload has DxeMain integrated, however Memory Types are platform-specific, for example, some platforms may need bigger runtime memory for their implementation, that's why we want such FDT reserved-memory node to tell DxeMain.\n\nThe Payload flow will be like this:\n Payload creates built-in default MemoryTypes table ->\n FDT reserved-memory node to override if required (this also ensures the same memory map cross boots so ACPI S4 works) ->\n Build gEfiMemoryTypeInformationGuid HOB by \"platfom specific\" MemoryTypes Table ->\n DxeMain/GCD to consume this MemoryTypes table and setup memory service ->\n Install memory types table to UEFI system table.Configuration table...\n\nNote: if Payload built-in default MemoryTypes table works fine for the platform, then FDT reserved-memory node does not need to provide such 'usage' compatible strings. (optional)\nThis FDT node could allow flexibility/compatibility without rebuilding Payload binary.\n\nNot sure if I answered all your questions, please highlight which area you need more information.\n\nThanks,\nChasel\n\n\n> \n> >\n> > > -----Original Message-----\n> > > From: Chiu, Chasel\n> > > Sent: Tuesday, November 21, 2023 10:34 AM\n> > > To: Ard Biesheuvel ; Simon Glass \n> > > Cc: devicetree@vger.kernel.org; Mark Rutland ;\n> > > Rob Herring ; Tan, Lean Sheng\n> > > ; lkml ;\n> > > Dhaval Sharma ; Brune, Maximilian\n> > > ; Yunhui Cui\n> > > ; Dong, Guo ; Tom Rini\n> > > ; ron minnich ; Guo, Gua\n> > > ; linux-acpi@vger.kernel.org; U-Boot Mailing List\n> > > ; Chiu, Chasel \n> > > Subject: RE: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> > > usages\n> > >\n> > >\n> > > Hi Ard,\n> > >\n> > > Here is the POC PR for your reference:\n> > > https://github.com/tianocore/edk2/pull/4969/files#diff-\n> > >\n> ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR26\n> > > 8\n> > > Please note that this PR is still in early phase and expected to\n> > > have significant changes.\n> > >\n> > > The idea is that payload entry will create\n> > > gEfiMemoryTypeInformationGuid HOB with payload default memory types\n> > > and allow FDT to override if correspond node present.\n> > > Please let me know if you have questions or suggestions.\n> > >\n> > > Thanks,\n> > > Chasel\n> > >\n> > >\n> > > > -----Original Message-----\n> > > > From: Ard Biesheuvel \n> > > > Sent: Tuesday, November 21, 2023 8:42 AM\n> > > > To: Simon Glass \n> > > > Cc: Chiu, Chasel ;\n> > > > devicetree@vger.kernel.org; Mark Rutland ;\n> > > > Rob Herring ; Tan, Lean Sheng\n> > > > ; lkml ;\n> > > > Dhaval Sharma ; Brune, Maximilian\n> > > > ; Yunhui Cui\n> > > > ; Dong, Guo ; Tom\n> > > > Rini ; ron minnich ; Guo,\n> > > > Gua ; linux- acpi@vger.kernel.org; U-Boot\n> > > > Mailing List \n> > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common\n> > > > reserved-memory usages\n> > > >\n> > > > On Mon, 20 Nov 2023 at 21:12, Simon Glass wrote:\n> > > > >\n> > > > > Hi,\n> > > > >\n> > > > > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel \n> wrote:\n> > > > > >\n> > > > > >\n> > > > > > Hi Ard,\n> > > > > >\n> > > > > > Please see my reply below inline.\n> > > > > >\n> > > > > > Thanks,\n> > > > > > Chasel\n> > > > > >\n> > > > > >\n> > > > > > > -----Original Message-----\n> > > > > > > From: Ard Biesheuvel \n> > > > > > > Sent: Saturday, November 11, 2023 3:04 AM\n> > > > > > > To: Chiu, Chasel \n> > > > > > > Cc: Simon Glass ;\n> > > > > > > devicetree@vger.kernel.org; Mark Rutland\n> > > > > > > ; Rob Herring ; Tan,\n> > > > > > > Lean Sheng ; lkml\n> > > > > > > ; Dhaval Sharma\n> > > > > > > ; Brune, Maximilian\n> > > > > > > ; Yunhui Cui\n> > > > > > > ; Dong, Guo ;\n> > > > > > > Tom Rini ; ron minnich\n> > > > > > > ; Guo, Gua ; linux-\n> > > > > > > acpi@vger.kernel.org; U-Boot Mailing List\n> > > > > > > \n> > > > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common\n> > > > > > > reserved-memory usages\n> > > > > > >\n> > > > > > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel\n> > > > > > > \n> > > wrote:\n> > > > > > > >\n> > > > > > > >\n> > > > > > > > Just sharing some usage examples from UEFI/EDK2 scenario.\n> > > > > > > > To support ACPI S4/Hibernation, memory map must be\n> > > > > > > > consistent before entering and after resuming from S4, in\n> > > > > > > > this case payload may need to know previous memory map\n> > > > > > > > from bootloader (currently generic payload cannot access\n> > > > > > > > platform/bootloader specific non-volatile data, thus could\n> > > > > > > > not save/restore memory map\n> > > > > > > > information)\n> > > > > > >\n> > > > > > > So how would EDK2 reconstruct the entire EFI memory map from\n> > > > > > > just these unannotated /reserved-memory nodes? The EFI\n> > > > > > > memory map contains much more information than that, and all\n> > > > > > > of it has to match the pre-hibernate situation, right? Can you given an\n> example?\n> > > > > >\n> > > > > >\n> > > > > > Here we listed only typically memory types that may change\n> > > > > > cross different\n> > > > platforms.\n> > > > > > Reserved memory type already can be handled by reserved-memory\n> > > > > > node,\n> > > > and rest of the types usually no need to change cross platforms\n> > > > thus currently we could rely on default in generic payload.\n> > > > > > In the future if we see a need to add new memory types we will\n> > > > > > discuss and\n> > > > add it to FDT schema.\n> > > > > >\n> > > > > >\n> > > > > >\n> > > > > > >\n> > > > > > > > Another usage is to support binary model which generic\n> > > > > > > > payload is a prebuilt\n> > > > > > > binary compatible for all platforms/configurations, however\n> > > > > > > the payload default memory map might not always work for all\n> > > > > > > the configurations and we want to allow bootloader to\n> > > > > > > override payload default\n> > > > memory map without recompiling.\n> > > > > > > >\n> > > > > > >\n> > > > > > > Agreed. But can you explain how a EDK2 payload might make\n> > > > > > > meaningful use of 'runtime-code' regions provided via DT by\n> > > > > > > the\n> > > > > > > non-EDK2 platform init? Can you give an example?\n> > > > > >\n> > > > > >\n> > > > > > Runtime-code/data is used by UEFI payload for booting UEFI OS\n> > > > > > which\n> > > > required UEFI runtime services.\n> > > > > > Platform Init will select some regions from the usable memory\n> > > > > > and assign it to\n> > > > runtime-code/data for UPL to consume. Or assign same\n> > > > runtime-code/data from previous boot.\n> > > > > > If UEFI OS is not supported, PlatformInit may not need to\n> > > > > > provide runtime-code/data regions to payload. (always\n> > > > > > providing runtime-code/data should be supported too)\n> > > > > >\n> > > > > >\n> > > > > > >\n> > > > > > > > Under below assumption:\n> > > > > > > > FDT OS impact has been evaluated and taken care by\n> > > > > > > > relevant\n> > > > > > > experts/stakeholders.\n> > > > > > > > Reviewed-by: Chasel Chiu \n> > > > > > > >\n> > > > > > >\n> > > > > > > I am sorry but I don't know what 'FDT OS impact' means. We\n> > > > > > > are talking about a firmware-to-firmware abstraction that\n> > > > > > > has the potential to leak into the OS visible interface.\n> > > > > > >\n> > > > > > > I am a maintainer in the Tianocore project myself, so it\n> > > > > > > would help if you could explain who these relevant experts\n> > > > > > > and stakeholders are. Was this discussed on the edk2-devel\n> > > > > > > mailing list? If so, apologies for missing it but I may not have been cc'ed\n> perhaps?\n> > > > > >\n> > > > > >\n> > > > > >\n> > > > > >\n> > > > > > I'm not familiar with FDT OS, also I do not know if who from\n> > > > > > edk2-devel were\n> > > > supporting FDT OS, I think Simon might be able to connect FDT OS\n> > > > experts/stakeholders.\n> > > > > > We are mostly focusing on payload firmware phase\n> > > > > > implementation in\n> > > > > > edk2 (and other payloads too), however, since we have aligned\n> > > > > > the payload FDT and OS FDT months ago, I'm assuming FDT OS\n> > > > > > impact must be there and we need (or already done?) FDT OS\n> > > > > > experts to support it. (again, maybe Simon could share more\n> > > > > > information about FDT OS)\n> > > > > >\n> > > > > > In edk2 such FDT schema is UefiPayloadPkg internal usage only\n> > > > > > and payload\n> > > > entry will convert FDT into HOB thus we expected the most of the\n> > > > edk2 generic code are no-touch/no impact, that's why we only had\n> > > > small group\n> > > > (UefiPayloadPkg) discussion.\n> > > > > > Ard, if you are aware of any edk2 code that's for supporting\n> > > > > > FDT OS, please let\n> > > > us know and we can discuss if those code were impacted or not.\n> > > > >\n> > > > > We discussed this and just to clarify, 'FDT OS' is not a special\n> > > > > OS, it is just Linux.\n> > > > >\n> > > > > So, with the above, are we all on the same page? Can the patch\n> > > > > be applied, perhaps? If not, what other discussion is needed?\n> > > > >\n> > > >\n> > > > An example of how a platform-init/payload combination would make\n> > > > meaningful use of such runtime-code/data regions.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=fQMYVScz;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.b=\"fQMYVScz\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=chasel.chiu@intel.com","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=intel.com;"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4Sfx0h37Y7z23mS\n\tfor ; Wed, 29 Nov 2023 08:48:36 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 66E75875F0;\n\tTue, 28 Nov 2023 22:48:28 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id BB75A87741; Tue, 28 Nov 2023 21:31:07 +0100 (CET)","from mgamail.intel.com (mgamail.intel.com [192.55.52.88])\n (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id A279A86C68\n for ; Tue, 28 Nov 2023 21:31:03 +0100 (CET)","from fmviesa001.fm.intel.com ([10.60.135.141])\n by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 28 Nov 2023 12:31:00 -0800","from orsmsx602.amr.corp.intel.com ([10.22.229.15])\n by fmviesa001.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384;\n 28 Nov 2023 12:31:00 -0800","from orsmsx612.amr.corp.intel.com (10.22.229.25) by\n ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.2507.34; Tue, 28 Nov 2023 12:30:59 -0800","from orsmsx610.amr.corp.intel.com (10.22.229.23) by\n ORSMSX612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.2507.34; Tue, 28 Nov 2023 12:30:59 -0800","from orsedg603.ED.cps.intel.com (10.7.248.4) by\n orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.2507.34 via Frontend Transport; Tue, 28 Nov 2023 12:30:58 -0800","from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.101)\n by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.1.2507.34; Tue, 28 Nov 2023 12:30:57 -0800","from BN9PR11MB5483.namprd11.prod.outlook.com (2603:10b6:408:104::10)\n by DM4PR11MB5565.namprd11.prod.outlook.com (2603:10b6:5:39e::12) with\n Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7046.22; Tue, 28 Nov\n 2023 20:30:49 +0000","from BN9PR11MB5483.namprd11.prod.outlook.com\n ([fe80::6da1:a4b7:4771:14e1]) by BN9PR11MB5483.namprd11.prod.outlook.com\n ([fe80::6da1:a4b7:4771:14e1%5]) with mapi id 15.20.7025.022; Tue, 28 Nov 2023\n 20:30:49 +0000"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,\n RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE\n autolearn=ham autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1701203463; x=1732739463;\n h=from:to:cc:subject:date:message-id:references:\n in-reply-to:content-transfer-encoding:mime-version;\n bh=9B0kBOy4vIvBw7mu5AglBGDkWfduIpFCvukKGAYEgbU=;\n b=fQMYVSczo9qhWoh1Mex1cnpXZH1/yHwvUJxadcHLaWKIFDeNmKcxLJ98\n q5AkXbiC6Hz3ZDtKQjpor8JXMU4VfbKNcTuOUwIDRT9yYsA+Y3BK8hrfG\n TzBM2cVsG11R3vBNhItlGwe3C/lCWOvPmrXf5Cy7LV+AZO0L6Dakt2Q+s\n XxrjZzgmygHL681LoatPdWhy90fq3saROJuEuRcWCtwniR4jFN/ou7N32\n 3CA8roZpPVUFZLnievvxn5tjh14njUNWybDVAtsOLBip0pMZA/Q5ef9CL\n 9Um3G3+aOmJxAbcRG1p1t6TyquSoUWOmeD/RVhLiUgf8UzlwIwIZIcyOl A==;","X-IronPort-AV":["E=McAfee;i=\"6600,9927,10908\"; a=\"424168546\"","E=Sophos;i=\"6.04,234,1695711600\"; d=\"scan'208\";a=\"424168546\"","E=Sophos;i=\"6.04,234,1695711600\"; d=\"scan'208\";a=\"17038269\""],"X-ExtLoop1":"1","ARC-Seal":"i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=jSxtg8WDqTezcov6noowmgftp5ZdZvldxMKwLJco2s4ZYeCW4BbvgSdWRm1pnSTBdMWLub+Wk4jUV4iZv6TesZKklPZANXhm0v9U4X1wzWAMxmTNleH9pcHE2/LSTj/bnzvmbTZUQfPq/3/VSx69W39Sq1NTTPtAHyjI+Yu4dRHXveuXEJU4HDma59dYsWrpHYvMtNR0yQYqQ1GFngPonnKPQPHq18uNXPCMi2fKcK1D21v6PP0r+9tnNSfcJfK9p7gyxCkn45guzrpBro56TogSKrYdFOjkXzGAFM5YOMk//YwJffVAERx0vJqxhrExZpCG3LVehdug73nNl7vO0A==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;\n bh=9B0kBOy4vIvBw7mu5AglBGDkWfduIpFCvukKGAYEgbU=;\n b=b7JSoLAwJt1ikjwOECMC776DhZJ8VikQ0DmhzW9vmfu/quK6Tk5XmR5QLcS1/B+yk1gom8OrzyQDCEdYbMalS9p9J6/eQgZYtxOoR921f7g3AHQpAs7wFdfhn92ZIEBD+zAROuNQcw3G0uTd8lNCzImcP7ajtxFdKmRQt9uocyT8cJHc63AR3N64LFh16oXHhwNVWwN0GRZtxN5k+q9yqvrKbzrvLHA2j4P2lsVCRVuWE+iHnDSPE0ZdgfOkSNaxR8yBRhI2cVfKUSNYciUmc53SsqcUJ/FWf1gCggBQ8HgEby4H6oIida9v4yZMy5t+MwzY+9Et7o5nKjZ6Eyin/g==","ARC-Authentication-Results":"i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none","From":"\"Chiu, Chasel\" ","To":"Ard Biesheuvel ","CC":"Simon Glass , \"devicetree@vger.kernel.org\"\n , Mark Rutland , \"Rob\n Herring\" , \"Tan, Lean Sheng\" , lkml\n , Dhaval Sharma , \"Brune,\n Maximilian\" , Yunhui Cui\n , \"Dong, Guo\" , Tom Rini\n , ron minnich , \"Guo, Gua\"\n , \"linux-acpi@vger.kernel.org\"\n , U-Boot Mailing List ,\n \"Chiu, Chasel\" ","Subject":"RE: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","Thread-Topic":"[PATCH v7 2/2] schemas: Add some common reserved-memory usages","Thread-Index":"\n AQHZ8LGvpttG6mvEz0WlU57NBrVnTbB0GT1wgAEi2gCAA4/1oIALktuAgADzAICAABvkkIAABCKwgAr4SACAABVGMA==","Date":"Tue, 28 Nov 2023 20:30:49 +0000","Message-ID":"\n ","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n \n \n ","In-Reply-To":"\n ","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","authentication-results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=fQMYVScz;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.b=\"fQMYVScz\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=intel.com","phobos.denx.de;\n spf=pass smtp.mailfrom=chasel.chiu@intel.com","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=intel.com;"],"x-ms-publictraffictype":"Email","x-ms-traffictypediagnostic":"BN9PR11MB5483:EE_|DM4PR11MB5565:EE_","x-ms-office365-filtering-correlation-id":"c2699d79-d81f-440f-eb99-08dbf050e8a4","x-ld-processed":"46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr","x-ms-exchange-senderadcheck":"1","x-ms-exchange-antispam-relay":"0","x-microsoft-antispam":"BCL:0;","x-microsoft-antispam-message-info":"\n 4pjMlFBmlAgaEaiSX9vpmH+eJhLdMpRMHYLb6zZhf8DD8DB2kZROZhq/EN7+vY7ZpfA0+L7kfXq0MuO+wqAewPR4BSky5tSpzFPLUhAuRpe3XEvmXE1AKW3Yh+RcPQKpr/Isgg4xUbXmNmNTGsNgY8FjeqWnaAvg975ueyq5HCBF12QChVZDua7LmNlfLnzwaAfUk6HJnprSFmTJMYAQPrV50GJZO/jrK++0/Bb0xFUPSryVMT20q6i7AxMIpw2HKMoFdn/MrOgOBq+CVlN0hZPo8Gbj4hGpi86h6TTHVYboliMOlr5zlEKn1nyIcZT9q/R3vzp0OfxLkny4J9pl/ZCpTk2dDjDUSj8Pu6qkZe28mFhOiGFXt0EEgNga1rd+OFvUTh3aAN+S/OGCNWUyga+ad9JuPTnbr/BRRY1nfEujIXC6thbbKw4iP3mKs5VbbwGduOjPluByAcHm3BuuaUDk2d8xWrgquSDwMfINGmoLl/K9U9qhGELB1g1VSA+VzLtIWJZXmAEq/ewNAJhfmwOf1tscCJQTSNgCsqOBlIPt78txtAFFUXnFI2rOc2ID3In2+p04qXwDxz5y4H+UpYcR5VoJELtbZq8T+JwP5vbK66SYPj4WCc0VxMp1MyLwuoVb0ZJbyNLmcQHEl4dE7Q==","x-forefront-antispam-report":"CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:BN9PR11MB5483.namprd11.prod.outlook.com; PTR:; CAT:NONE;\n SFS:(13230031)(396003)(39860400002)(366004)(136003)(376002)(346002)(230922051799003)(451199024)(186009)(64100799003)(1800799012)(55016003)(9686003)(71200400001)(107886003)(478600001)(26005)(122000001)(82960400001)(86362001)(38100700002)(33656002)(5660300002)(38070700009)(30864003)(2906002)(41300700001)(83380400001)(6506007)(7696005)(53546011)(6916009)(4326008)(316002)(66556008)(66476007)(66446008)(64756008)(54906003)(7416002)(8676002)(52536014)(8936002)(76116006)(66946007)(966005);\n DIR:OUT; SFP:1102;","x-ms-exchange-antispam-messagedata-chunkcount":"1","x-ms-exchange-antispam-messagedata-0":"=?utf-8?q?e5xxa+wApO48B1uAUdpVKbrYrpE5?=\n\t=?utf-8?q?8yl/dtt0xlhcaFxyhI5T8NZE66cgSsk70eDqATgUitQlBTyxFjUxwwxDc4w/AnUK4?=\n\t=?utf-8?q?2wOMAgtmsUkwqb2keDTTgl3v1he80WO7Am6ijEsuADr+dLLIqqAbw20pKpiPmtF3z?=\n\t=?utf-8?q?WUyLC7/8IaTLaS0Nm2UkCq2tYjCZszNIEeB73qmTobPMPNTqZUpkSdOyD+mhDrtMi?=\n\t=?utf-8?q?D7VVtkDcycEkZRnQykc2Ys0qHH/Ml26lh6XiZmLuT+pXZluMIKS5DYFXXQGwwPQcC?=\n\t=?utf-8?q?YiEXGscGSap+ZtuRomdEbj4uKwqdzZVEvsvV2PNwONFYi7EoOw8dvY+1ha83rTA70?=\n\t=?utf-8?q?D9+0pOw2H0+99x2XOokkhPLrVYLAS54c7qRNQobSucI1Ko/PiuoiyOtr9QYH/T59h?=\n\t=?utf-8?q?hW3TEImG1LaSdKFXRpd+599FWCFNs+nCqfm+sIOMXEEr8hMei9nyTM58AK+DORIql?=\n\t=?utf-8?q?xpwdDqIYxaoATRZ/0KLMkm4JDGar8L3TfI9NMxZJJPC3bg2PZ4VjRX3ObPtmnONlV?=\n\t=?utf-8?q?Pof6YOiSqtIQUhH3TilgN25Gqk04xjguoEt3NGGkH72Tw7+j++SmNGEKqFJ8sgy2p?=\n\t=?utf-8?q?bYLUw0eem1iOfoYdBpUHipVQprw06WSh1AIteOmh9XcINTuvjqHuAGoixd9uUyvjV?=\n\t=?utf-8?q?/LD9zIv/5od/KtIy+q1QzPlocvI2fOB5Wbzxf+j/DT3ZZ2Y9lo4cJxEEHlUzLfx3M?=\n\t=?utf-8?q?ae7ytbPw2rphkdtbX+YrQlZX1+haDrC1/eI/1kkQ95Bvh/71MuNqvwQf1XXDTbV1K?=\n\t=?utf-8?q?CgFUSpytT62Lc3v5CdjH+vspPk7Dehi5Wa9hrQ5i03x1lTV9WE43OXSUmhQNdhBGR?=\n\t=?utf-8?q?Odu5c8SCNp16cG824rVbfMY/7YPSik8CWwBz247bRUZiDFim7yRkRD4EyBtEt0JBs?=\n\t=?utf-8?q?728SwYO6LywEt1kCXAFRKxzAwbqcSCb+WIc7Uh/al96qDPb0FxtYgoHOUBiELZYx1?=\n\t=?utf-8?q?isaASFlnc1w7baJt8naUreAdk9BHgqcXSFH+89AGbjbyzIOZXEKXsTZAvHxy2HQ4T?=\n\t=?utf-8?q?n13DW4kSamvrIl74BkUqnY76J9SQZ3i/tQg40zOYVtLbK7L43GDLBNIHUOl+aPvef?=\n\t=?utf-8?q?4CHLCvXXurXc8EfVMzAETQ7XhP/Pb0FGg2RaCGlgsqKaVBQ/3IYk74gGJ4vHYBsCO?=\n\t=?utf-8?q?3eFN/GKxfopB1nQPxrXLaMUyGpaHcoA3n5aL9TXV4hSSHBDFIwCk22KnnHROKCvJf?=\n\t=?utf-8?q?/u2schHyO+zB2m7pF0FeYHl/IJfbzg2miJoTOYXWzx9XcUaJqvrwj1BOB2AMhdmUa?=\n\t=?utf-8?q?+0EN2zRYj+BfBym52Fa/lSqyRv/Wdugbx85vLBslh3yGZsjccHPIP7Kgn6BI40aG7?=\n\t=?utf-8?q?Dzv7KVjg/tD/xgJ+zeV9o9czem0zgdQioJ77eFgMA2/zqFAAYEmi1+HBj71eVWNVf?=\n\t=?utf-8?q?8R/ZZC3lfX44ZjwlIQaPf5gaZ1D6HCBN0hqQ45tIKJ5XkH14SrGU9/yrJA5b4qMIl?=\n\t=?utf-8?q?5Fep364adJcWc9FtHimdg3Jrxjn/cx4MOqEwkjv3SX6YAd7OveXQ9Nb03h4s7JgH7?=\n\t=?utf-8?q?cEmJx9OlGlWC?=","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","X-MS-Exchange-CrossTenant-AuthAs":"Internal","X-MS-Exchange-CrossTenant-AuthSource":"BN9PR11MB5483.namprd11.prod.outlook.com","X-MS-Exchange-CrossTenant-Network-Message-Id":"\n c2699d79-d81f-440f-eb99-08dbf050e8a4","X-MS-Exchange-CrossTenant-originalarrivaltime":"28 Nov 2023 20:30:49.4146 (UTC)","X-MS-Exchange-CrossTenant-fromentityheader":"Hosted","X-MS-Exchange-CrossTenant-id":"46c98d88-e344-4ed4-8496-4ed7712e255d","X-MS-Exchange-CrossTenant-mailboxtype":"HOSTED","X-MS-Exchange-CrossTenant-userprincipalname":"\n RNrX4npq5mOZfaqC9IzEMrbEnIkxwaxTRlgnPsg3Mbs2Dj6tV0CDxR0UMDgXW+joxHlp6XwEhlGYZHyqEBKvIw==","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"DM4PR11MB5565","X-OriginatorOrg":"intel.com","X-Mailman-Approved-At":"Tue, 28 Nov 2023 22:48:27 +0100","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3231765,"web_url":"http://patchwork.ozlabs.org/comment/3231765/","msgid":"","list_archive_url":null,"date":"2023-12-11T17:52:20","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":6170,"url":"http://patchwork.ozlabs.org/api/people/6170/","name":"Simon Glass","email":"sjg@chromium.org"},"content":"Hi,\n\nOn Tue, 28 Nov 2023 at 13:31, Chiu, Chasel wrote:\n>\n>\n>\n>\n> > -----Original Message-----\n> > From: Ard Biesheuvel \n> > Sent: Tuesday, November 28, 2023 10:08 AM\n> > To: Chiu, Chasel \n> > Cc: Simon Glass ; devicetree@vger.kernel.org; Mark Rutland\n> > ; Rob Herring ; Tan, Lean Sheng\n> > ; lkml ; Dhaval\n> > Sharma ; Brune, Maximilian\n> > ; Yunhui Cui ;\n> > Dong, Guo ; Tom Rini ; ron minnich\n> > ; Guo, Gua ; linux-\n> > acpi@vger.kernel.org; U-Boot Mailing List \n> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> > usages\n> >\n> > You are referring to a 2000 line patch so it is not 100% clear where to look tbh.\n> >\n> >\n> > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel wrote:\n> > >\n> > >\n> > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for\n> > related example code.\n> > >\n> >\n> > That refers to a 'memory-allocation' node, right? How does that relate to the\n> > 'reserved-memory' node?\n> >\n> > And crucially, how does this clarify in which way \"runtime-code\" and \"runtime-\n> > data\" reservations are being used?\n> >\n> > Since the very beginning of this discussion, I have been asking repeatedly for\n> > examples that describe the wider context in which these reservations are used.\n> > The \"runtime\" into runtime-code and runtime-data means that these regions have\n> > a special significance to the operating system, not just to the next bootloader\n> > stage. So I want to understand exactly why it is necessary to describe these\n> > regions in a way where the operating system might be expected to interpret this\n> > information and act upon it.\n> >\n>\n>\n> I think runtime code and data today are mainly for supporting UEFI runtime services - some BIOS functions for OS to utilize, OS may follow below ACPI spec to treat them as reserved range:\n> https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#uefi-memory-types-and-mapping-to-acpi-address-range-types\n>\n> Like I mentioned earlier, that PR is still in early phase and has not reflected all the required changes yet, but the idea is to build gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes.\n> UEFI generic Payload has DxeMain integrated, however Memory Types are platform-specific, for example, some platforms may need bigger runtime memory for their implementation, that's why we want such FDT reserved-memory node to tell DxeMain.\n>\n> The Payload flow will be like this:\n> Payload creates built-in default MemoryTypes table ->\n> FDT reserved-memory node to override if required (this also ensures the same memory map cross boots so ACPI S4 works) ->\n> Build gEfiMemoryTypeInformationGuid HOB by \"platfom specific\" MemoryTypes Table ->\n> DxeMain/GCD to consume this MemoryTypes table and setup memory service ->\n> Install memory types table to UEFI system table.Configuration table...\n>\n> Note: if Payload built-in default MemoryTypes table works fine for the platform, then FDT reserved-memory node does not need to provide such 'usage' compatible strings. (optional)\n> This FDT node could allow flexibility/compatibility without rebuilding Payload binary.\n>\n> Not sure if I answered all your questions, please highlight which area you need more information.\n\nAny more thoughts on this? If not, I would like to see this patch\napplied, please.\n\nRegards,\nSimon\n\n\n>\n> Thanks,\n> Chasel\n>\n>\n> >\n> > >\n> > > > -----Original Message-----\n> > > > From: Chiu, Chasel\n> > > > Sent: Tuesday, November 21, 2023 10:34 AM\n> > > > To: Ard Biesheuvel ; Simon Glass \n> > > > Cc: devicetree@vger.kernel.org; Mark Rutland ;\n> > > > Rob Herring ; Tan, Lean Sheng\n> > > > ; lkml ;\n> > > > Dhaval Sharma ; Brune, Maximilian\n> > > > ; Yunhui Cui\n> > > > ; Dong, Guo ; Tom Rini\n> > > > ; ron minnich ; Guo, Gua\n> > > > ; linux-acpi@vger.kernel.org; U-Boot Mailing List\n> > > > ; Chiu, Chasel \n> > > > Subject: RE: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> > > > usages\n> > > >\n> > > >\n> > > > Hi Ard,\n> > > >\n> > > > Here is the POC PR for your reference:\n> > > > https://github.com/tianocore/edk2/pull/4969/files#diff-\n> > > >\n> > ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR26\n> > > > 8\n> > > > Please note that this PR is still in early phase and expected to\n> > > > have significant changes.\n> > > >\n> > > > The idea is that payload entry will create\n> > > > gEfiMemoryTypeInformationGuid HOB with payload default memory types\n> > > > and allow FDT to override if correspond node present.\n> > > > Please let me know if you have questions or suggestions.\n> > > >\n> > > > Thanks,\n> > > > Chasel\n> > > >\n> > > >\n> > > > > -----Original Message-----\n> > > > > From: Ard Biesheuvel \n> > > > > Sent: Tuesday, November 21, 2023 8:42 AM\n> > > > > To: Simon Glass \n> > > > > Cc: Chiu, Chasel ;\n> > > > > devicetree@vger.kernel.org; Mark Rutland ;\n> > > > > Rob Herring ; Tan, Lean Sheng\n> > > > > ; lkml ;\n> > > > > Dhaval Sharma ; Brune, Maximilian\n> > > > > ; Yunhui Cui\n> > > > > ; Dong, Guo ; Tom\n> > > > > Rini ; ron minnich ; Guo,\n> > > > > Gua ; linux- acpi@vger.kernel.org; U-Boot\n> > > > > Mailing List \n> > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common\n> > > > > reserved-memory usages\n> > > > >\n> > > > > On Mon, 20 Nov 2023 at 21:12, Simon Glass wrote:\n> > > > > >\n> > > > > > Hi,\n> > > > > >\n> > > > > > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel \n> > wrote:\n> > > > > > >\n> > > > > > >\n> > > > > > > Hi Ard,\n> > > > > > >\n> > > > > > > Please see my reply below inline.\n> > > > > > >\n> > > > > > > Thanks,\n> > > > > > > Chasel\n> > > > > > >\n> > > > > > >\n> > > > > > > > -----Original Message-----\n> > > > > > > > From: Ard Biesheuvel \n> > > > > > > > Sent: Saturday, November 11, 2023 3:04 AM\n> > > > > > > > To: Chiu, Chasel \n> > > > > > > > Cc: Simon Glass ;\n> > > > > > > > devicetree@vger.kernel.org; Mark Rutland\n> > > > > > > > ; Rob Herring ; Tan,\n> > > > > > > > Lean Sheng ; lkml\n> > > > > > > > ; Dhaval Sharma\n> > > > > > > > ; Brune, Maximilian\n> > > > > > > > ; Yunhui Cui\n> > > > > > > > ; Dong, Guo ;\n> > > > > > > > Tom Rini ; ron minnich\n> > > > > > > > ; Guo, Gua ; linux-\n> > > > > > > > acpi@vger.kernel.org; U-Boot Mailing List\n> > > > > > > > \n> > > > > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common\n> > > > > > > > reserved-memory usages\n> > > > > > > >\n> > > > > > > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel\n> > > > > > > > \n> > > > wrote:\n> > > > > > > > >\n> > > > > > > > >\n> > > > > > > > > Just sharing some usage examples from UEFI/EDK2 scenario.\n> > > > > > > > > To support ACPI S4/Hibernation, memory map must be\n> > > > > > > > > consistent before entering and after resuming from S4, in\n> > > > > > > > > this case payload may need to know previous memory map\n> > > > > > > > > from bootloader (currently generic payload cannot access\n> > > > > > > > > platform/bootloader specific non-volatile data, thus could\n> > > > > > > > > not save/restore memory map\n> > > > > > > > > information)\n> > > > > > > >\n> > > > > > > > So how would EDK2 reconstruct the entire EFI memory map from\n> > > > > > > > just these unannotated /reserved-memory nodes? The EFI\n> > > > > > > > memory map contains much more information than that, and all\n> > > > > > > > of it has to match the pre-hibernate situation, right? Can you given an\n> > example?\n> > > > > > >\n> > > > > > >\n> > > > > > > Here we listed only typically memory types that may change\n> > > > > > > cross different\n> > > > > platforms.\n> > > > > > > Reserved memory type already can be handled by reserved-memory\n> > > > > > > node,\n> > > > > and rest of the types usually no need to change cross platforms\n> > > > > thus currently we could rely on default in generic payload.\n> > > > > > > In the future if we see a need to add new memory types we will\n> > > > > > > discuss and\n> > > > > add it to FDT schema.\n> > > > > > >\n> > > > > > >\n> > > > > > >\n> > > > > > > >\n> > > > > > > > > Another usage is to support binary model which generic\n> > > > > > > > > payload is a prebuilt\n> > > > > > > > binary compatible for all platforms/configurations, however\n> > > > > > > > the payload default memory map might not always work for all\n> > > > > > > > the configurations and we want to allow bootloader to\n> > > > > > > > override payload default\n> > > > > memory map without recompiling.\n> > > > > > > > >\n> > > > > > > >\n> > > > > > > > Agreed. But can you explain how a EDK2 payload might make\n> > > > > > > > meaningful use of 'runtime-code' regions provided via DT by\n> > > > > > > > the\n> > > > > > > > non-EDK2 platform init? Can you give an example?\n> > > > > > >\n> > > > > > >\n> > > > > > > Runtime-code/data is used by UEFI payload for booting UEFI OS\n> > > > > > > which\n> > > > > required UEFI runtime services.\n> > > > > > > Platform Init will select some regions from the usable memory\n> > > > > > > and assign it to\n> > > > > runtime-code/data for UPL to consume. Or assign same\n> > > > > runtime-code/data from previous boot.\n> > > > > > > If UEFI OS is not supported, PlatformInit may not need to\n> > > > > > > provide runtime-code/data regions to payload. (always\n> > > > > > > providing runtime-code/data should be supported too)\n> > > > > > >\n> > > > > > >\n> > > > > > > >\n> > > > > > > > > Under below assumption:\n> > > > > > > > > FDT OS impact has been evaluated and taken care by\n> > > > > > > > > relevant\n> > > > > > > > experts/stakeholders.\n> > > > > > > > > Reviewed-by: Chasel Chiu \n> > > > > > > > >\n> > > > > > > >\n> > > > > > > > I am sorry but I don't know what 'FDT OS impact' means. We\n> > > > > > > > are talking about a firmware-to-firmware abstraction that\n> > > > > > > > has the potential to leak into the OS visible interface.\n> > > > > > > >\n> > > > > > > > I am a maintainer in the Tianocore project myself, so it\n> > > > > > > > would help if you could explain who these relevant experts\n> > > > > > > > and stakeholders are. Was this discussed on the edk2-devel\n> > > > > > > > mailing list? If so, apologies for missing it but I may not have been cc'ed\n> > perhaps?\n> > > > > > >\n> > > > > > >\n> > > > > > >\n> > > > > > >\n> > > > > > > I'm not familiar with FDT OS, also I do not know if who from\n> > > > > > > edk2-devel were\n> > > > > supporting FDT OS, I think Simon might be able to connect FDT OS\n> > > > > experts/stakeholders.\n> > > > > > > We are mostly focusing on payload firmware phase\n> > > > > > > implementation in\n> > > > > > > edk2 (and other payloads too), however, since we have aligned\n> > > > > > > the payload FDT and OS FDT months ago, I'm assuming FDT OS\n> > > > > > > impact must be there and we need (or already done?) FDT OS\n> > > > > > > experts to support it. (again, maybe Simon could share more\n> > > > > > > information about FDT OS)\n> > > > > > >\n> > > > > > > In edk2 such FDT schema is UefiPayloadPkg internal usage only\n> > > > > > > and payload\n> > > > > entry will convert FDT into HOB thus we expected the most of the\n> > > > > edk2 generic code are no-touch/no impact, that's why we only had\n> > > > > small group\n> > > > > (UefiPayloadPkg) discussion.\n> > > > > > > Ard, if you are aware of any edk2 code that's for supporting\n> > > > > > > FDT OS, please let\n> > > > > us know and we can discuss if those code were impacted or not.\n> > > > > >\n> > > > > > We discussed this and just to clarify, 'FDT OS' is not a special\n> > > > > > OS, it is just Linux.\n> > > > > >\n> > > > > > So, with the above, are we all on the same page? Can the patch\n> > > > > > be applied, perhaps? If not, what other discussion is needed?\n> > > > > >\n> > > > >\n> > > > > An example of how a platform-init/payload combination would make\n> > > > > meaningful use of such runtime-code/data regions.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256\n header.s=google header.b=GrbGAY0K;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org\n header.b=\"GrbGAY0K\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SpqBD1Fh2z20Gc\n\tfor ; Tue, 12 Dec 2023 04:54:12 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 78948877BF;\n\tMon, 11 Dec 2023 18:53:14 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id CFA17877A5; Mon, 11 Dec 2023 18:53:12 +0100 (CET)","from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com\n [IPv6:2607:f8b0:4864:20::b29])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 61E9A877AA\n for ; Mon, 11 Dec 2023 18:53:06 +0100 (CET)","by mail-yb1-xb29.google.com with SMTP id\n 3f1490d57ef6-db53f8cf4afso3788772276.3\n for ; Mon, 11 Dec 2023 09:53:06 -0800 (PST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-9.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,\n SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_SPF_WL\n autolearn=no autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=chromium.org; s=google; t=1702317185; x=1702921985; darn=lists.denx.de;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=z1kYwpn/4RRiTYfgxP4Z+0TS9Lkq3RtxeVaveQei1nk=;\n b=GrbGAY0KiqqkTk1xPuuuGILc7M+tlgeyNB3Fo8IaN4Yu3zpb6u6Ljcu+fN2VOtWweV\n utDlg9JEBE0e/i/CTkhXQuk/Yx2NpiYCWqJaajsgJcWq6/fnq3gKqUp6n4hRaGDzgPTG\n UxQMs29rEmCsZt3Tv1UXZuRfXtZ8jEhjWsdpI=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1702317185; x=1702921985;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=z1kYwpn/4RRiTYfgxP4Z+0TS9Lkq3RtxeVaveQei1nk=;\n b=DTujcLSoEuz+sQP6pVfBg+cuVLmX3B7X0jqcCpldJpX/CKHvNiZkGvbOtKp1n/sZ8C\n 8cuOzLo/O+6+/VVu+QSQIh3FL794DPDhPuToMmf5pxlujEVPlNk7S87CW7/ntj2q9WJQ\n 3rX17beEIHyF1c+2AKrUEI0DS1VYjbRceFi1S1G5DQ33Qt+3L+JTNmqekd0YRAE2bexq\n mydOTZTvu6onZCU8oD6wIzXebmzQSaJhfVBW87YD54xIKdU53rsv34qr03HzmZO/4mfk\n a7SCFeHfygtYyZ3NAbLvKuB+SXhOQzvi+1wVWzzTzjkM/810J6R4JsOnkecfCa+26242\n 6/mw==","X-Gm-Message-State":"AOJu0YwpKioWNvQl+cYLAFnJCtxWe38Q3yXu4DUANwtGOO6FPymywE3b\n T8szrXSjyHiBcspHTGbIYiZanHviqPwv3/+sLQhYSA==","X-Google-Smtp-Source":"\n AGHT+IFJkIGl3bY2Xlq63CmKGEYpGlFd0kMox2Ikbmn5tqvBTEGLeZPhoS9YDszOKT0dLkTHJU3Qe8+2l32oswYZYF0=","X-Received":"by 2002:a25:76cb:0:b0:db7:dad0:76ca with SMTP id\n r194-20020a2576cb000000b00db7dad076camr3075678ybc.102.1702317184840; Mon, 11\n Dec 2023 09:53:04 -0800 (PST)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Simon Glass ","Date":"Mon, 11 Dec 2023 10:52:20 -0700","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"\"Chiu, Chasel\" ","Cc":"Ard Biesheuvel ,\n \"devicetree@vger.kernel.org\" ,\n Mark Rutland ,\n Rob Herring , \"Tan, Lean Sheng\" ,\n lkml , Dhaval Sharma ,\n \"Brune, Maximilian\" ,\n Yunhui Cui ,\n \"Dong, Guo\" , Tom Rini ,\n ron minnich , \"Guo, Gua\" ,\n \"linux-acpi@vger.kernel.org\" ,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3236746,"web_url":"http://patchwork.ozlabs.org/comment/3236746/","msgid":"","list_archive_url":null,"date":"2023-12-20T04:46:04","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":6170,"url":"http://patchwork.ozlabs.org/api/people/6170/","name":"Simon Glass","email":"sjg@chromium.org"},"content":"Hi,\n\nOn Mon, 11 Dec 2023 at 10:52, Simon Glass wrote:\n>\n> Hi,\n>\n> On Tue, 28 Nov 2023 at 13:31, Chiu, Chasel wrote:\n> >\n> >\n> >\n> >\n> > > -----Original Message-----\n> > > From: Ard Biesheuvel \n> > > Sent: Tuesday, November 28, 2023 10:08 AM\n> > > To: Chiu, Chasel \n> > > Cc: Simon Glass ; devicetree@vger.kernel.org; Mark Rutland\n> > > ; Rob Herring ; Tan, Lean Sheng\n> > > ; lkml ; Dhaval\n> > > Sharma ; Brune, Maximilian\n> > > ; Yunhui Cui ;\n> > > Dong, Guo ; Tom Rini ; ron minnich\n> > > ; Guo, Gua ; linux-\n> > > acpi@vger.kernel.org; U-Boot Mailing List \n> > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> > > usages\n> > >\n> > > You are referring to a 2000 line patch so it is not 100% clear where to look tbh.\n> > >\n> > >\n> > > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel wrote:\n> > > >\n> > > >\n> > > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for\n> > > related example code.\n> > > >\n> > >\n> > > That refers to a 'memory-allocation' node, right? How does that relate to the\n> > > 'reserved-memory' node?\n> > >\n> > > And crucially, how does this clarify in which way \"runtime-code\" and \"runtime-\n> > > data\" reservations are being used?\n> > >\n> > > Since the very beginning of this discussion, I have been asking repeatedly for\n> > > examples that describe the wider context in which these reservations are used.\n> > > The \"runtime\" into runtime-code and runtime-data means that these regions have\n> > > a special significance to the operating system, not just to the next bootloader\n> > > stage. So I want to understand exactly why it is necessary to describe these\n> > > regions in a way where the operating system might be expected to interpret this\n> > > information and act upon it.\n> > >\n> >\n> >\n> > I think runtime code and data today are mainly for supporting UEFI runtime services - some BIOS functions for OS to utilize, OS may follow below ACPI spec to treat them as reserved range:\n> > https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#uefi-memory-types-and-mapping-to-acpi-address-range-types\n> >\n> > Like I mentioned earlier, that PR is still in early phase and has not reflected all the required changes yet, but the idea is to build gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes.\n> > UEFI generic Payload has DxeMain integrated, however Memory Types are platform-specific, for example, some platforms may need bigger runtime memory for their implementation, that's why we want such FDT reserved-memory node to tell DxeMain.\n> >\n> > The Payload flow will be like this:\n> > Payload creates built-in default MemoryTypes table ->\n> > FDT reserved-memory node to override if required (this also ensures the same memory map cross boots so ACPI S4 works) ->\n> > Build gEfiMemoryTypeInformationGuid HOB by \"platfom specific\" MemoryTypes Table ->\n> > DxeMain/GCD to consume this MemoryTypes table and setup memory service ->\n> > Install memory types table to UEFI system table.Configuration table...\n> >\n> > Note: if Payload built-in default MemoryTypes table works fine for the platform, then FDT reserved-memory node does not need to provide such 'usage' compatible strings. (optional)\n> > This FDT node could allow flexibility/compatibility without rebuilding Payload binary.\n> >\n> > Not sure if I answered all your questions, please highlight which area you need more information.\n>\n> Any more thoughts on this? If not, I would like to see this patch\n> applied, please.\n\nI am really not sure who or what is holding this up, so far.\n\nCan we perhaps get this applied in time for Christmas? It would be a\nnice end to the year.\n\nRegards,\nSimon","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256\n header.s=google header.b=WN68kkdR;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org\n header.b=\"WN68kkdR\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4Sw1H63MXtz1ydg\n\tfor ; Wed, 20 Dec 2023 15:46:26 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id B9C618753E;\n\tWed, 20 Dec 2023 05:46:19 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id 24D808753E; Wed, 20 Dec 2023 05:46:19 +0100 (CET)","from mail-ej1-x634.google.com (mail-ej1-x634.google.com\n [IPv6:2a00:1450:4864:20::634])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id AA986870B7\n for ; Wed, 20 Dec 2023 05:46:16 +0100 (CET)","by mail-ej1-x634.google.com with SMTP id\n a640c23a62f3a-a2370535060so64890166b.1\n for ; Tue, 19 Dec 2023 20:46:16 -0800 (PST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-9.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,\n SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_SPF_WL\n autolearn=ham autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=chromium.org; s=google; t=1703047576; x=1703652376; darn=lists.denx.de;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=ObOjGHxxzANzBA20+fRUpz/qy8ssxRN2M1oEwSnchMg=;\n b=WN68kkdRWGGhdv3BINAztTdBiSyv4celyGG0CykFBnqEjtW/sYa9YYzEedzO/lNpYQ\n CucZ50YbdhxaHayKSPIRz8hXioNRx4NbdgC9g6CYhek6PdP72f8GzLNW0Oe47XjVwPU8\n TLqszz+SDUI10rMsErDm8xPYFtmqC0JKvAbdM=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20230601; t=1703047576; x=1703652376;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=ObOjGHxxzANzBA20+fRUpz/qy8ssxRN2M1oEwSnchMg=;\n b=H73IBe2eFPWwMyC/UG1a6t7vvCEm2KmHqm00ngLXd+L4eCl+oWZ95+NSPn7ai26xaK\n W2fJiz6kdoT9En1m+NaJ/uT6ldeqWIoSXKoZ7QDOvG/5JI0Lj7fNuI4QMiIQ82L1VIdP\n dw+S3/DdrPgH4dkCnZsRXgN40TDYbyOaJC9yiXV5d5ZHStZelVQ9Fi03HzvYBM6YpwQQ\n ElVpr/WZtMEACnP8OX3y2sWHKySmEf3cera7BWoXufEpXY+iNWONmBi8BEXM3OqhMa8r\n M5vBOdQDul8FJ9Y7RQ+rfsj27Up+Ez5Y3o9akjqb5akvBjUL8pHw7saTiIrz96tD2AK5\n e5rA==","X-Gm-Message-State":"AOJu0YwSYAToQsVkSjhlwQQ3m9HnC5Apsz5dtn9Q/KDWpgI0+bacjaK7\n e8sJtLupSsnPlRHCAO3Zqr4DfufG5Gf600AJ3oAptCemIQvy","X-Google-Smtp-Source":"\n AGHT+IFiAtnYS6LXvMS3hEaXi1ylgrBmLLhNN+uioKFv9mVb/Ycop0Bj8klqTrKKv5ovgt1osw7sDYHdsp6TNkdiWcg=","X-Received":"by 2002:a17:906:c15:b0:a26:8f35:20e3 with SMTP id\n s21-20020a1709060c1500b00a268f3520e3mr484981ejf.4.1703047576066; Tue, 19 Dec\n 2023 20:46:16 -0800 (PST)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Simon Glass ","Date":"Tue, 19 Dec 2023 21:46:04 -0700","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"\"Chiu, Chasel\" ","Cc":"Ard Biesheuvel ,\n \"devicetree@vger.kernel.org\" ,\n Mark Rutland ,\n Rob Herring , \"Tan, Lean Sheng\" ,\n lkml , Dhaval Sharma ,\n \"Brune, Maximilian\" ,\n Yunhui Cui ,\n \"Dong, Guo\" , Tom Rini ,\n ron minnich , \"Guo, Gua\" ,\n \"linux-acpi@vger.kernel.org\" ,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3237711,"web_url":"http://patchwork.ozlabs.org/comment/3237711/","msgid":"","list_archive_url":null,"date":"2023-12-21T14:30:40","subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","submitter":{"id":77831,"url":"http://patchwork.ozlabs.org/api/people/77831/","name":"Ard Biesheuvel","email":"ardb@kernel.org"},"content":"On Tue, 28 Nov 2023 at 21:31, Chiu, Chasel wrote:\n>\n>\n>\n>\n> > -----Original Message-----\n> > From: Ard Biesheuvel \n> > Sent: Tuesday, November 28, 2023 10:08 AM\n> > To: Chiu, Chasel \n> > Cc: Simon Glass ; devicetree@vger.kernel.org; Mark Rutland\n> > ; Rob Herring ; Tan, Lean Sheng\n> > ; lkml ; Dhaval\n> > Sharma ; Brune, Maximilian\n> > ; Yunhui Cui ;\n> > Dong, Guo ; Tom Rini ; ron minnich\n> > ; Guo, Gua ; linux-\n> > acpi@vger.kernel.org; U-Boot Mailing List \n> > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory\n> > usages\n> >\n> > You are referring to a 2000 line patch so it is not 100% clear where to look tbh.\n> >\n> >\n> > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel wrote:\n> > >\n> > >\n> > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for\n> > related example code.\n> > >\n> >\n> > That refers to a 'memory-allocation' node, right? How does that relate to the\n> > 'reserved-memory' node?\n> >\n> > And crucially, how does this clarify in which way \"runtime-code\" and \"runtime-\n> > data\" reservations are being used?\n> >\n> > Since the very beginning of this discussion, I have been asking repeatedly for\n> > examples that describe the wider context in which these reservations are used.\n> > The \"runtime\" into runtime-code and runtime-data means that these regions have\n> > a special significance to the operating system, not just to the next bootloader\n> > stage. So I want to understand exactly why it is necessary to describe these\n> > regions in a way where the operating system might be expected to interpret this\n> > information and act upon it.\n> >\n>\n>\n> I think runtime code and data today are mainly for supporting UEFI runtime services - some BIOS functions for OS to utilize, OS may follow below ACPI spec to treat them as reserved range:\n> https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#uefi-memory-types-and-mapping-to-acpi-address-range-types\n>\n> Like I mentioned earlier, that PR is still in early phase and has not reflected all the required changes yet, but the idea is to build gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes.\n> UEFI generic Payload has DxeMain integrated, however Memory Types are platform-specific, for example, some platforms may need bigger runtime memory for their implementation, that's why we want such FDT reserved-memory node to tell DxeMain.\n>\n\n> The Payload flow will be like this:\n> Payload creates built-in default MemoryTypes table ->\n> FDT reserved-memory node to override if required (this also ensures the same memory map cross boots so ACPI S4 works) ->\n> Build gEfiMemoryTypeInformationGuid HOB by \"platfom specific\" MemoryTypes Table ->\n> DxeMain/GCD to consume this MemoryTypes table and setup memory service ->\n> Install memory types table to UEFI system table.Configuration table...\n>\n> Note: if Payload built-in default MemoryTypes table works fine for the platform, then FDT reserved-memory node does not need to provide such 'usage' compatible strings. (optional)\n> This FDT node could allow flexibility/compatibility without rebuilding Payload binary.\n>\n> Not sure if I answered all your questions, please highlight which area you need more information.\n>\n\nThe gEfiMemoryTypeInformationGuid HOB typically carries platform\ndefaults, and the actual memory type information is kept in a\nnon-volatile EFI variable, which gets updated when the memory usage\nchanges. Is this different for UefiPayloadPkg?\n\n(For those among the cc'ees less versed in EFI/EDK2: when you get the\n'config changed -rebooting' message from the boot firmware, it\ntypically means that this memory type table has changed, and a reboot\nis necessary.)\n\nSo the platform init needs to read this variable, or get the\ninformation in a different way. I assume it is the payload, not the\nplatform init that updates the variable when necessary. This means the\ninformation flows from payload(n) to platform init(n+1), where n is a\nmonotonic index tracking consecutive boots of the system.\n\nCan you explain how the DT fits into this? How are the runtime-code\nand runtime-data memory reservation nodes under /reserved-memory used\nto implement this information exchange between platform init and\npayload? And how do the HOB and the EFI variable fit into this\npicture?","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=sqxSU2SK;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.b=\"sqxSU2SK\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=kernel.org","phobos.denx.de; spf=pass smtp.mailfrom=ardb@kernel.org"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4SwtCJ0MQ1z1ySd\n\tfor ; Fri, 22 Dec 2023 01:31:07 +1100 (AEDT)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 636148786C;\n\tThu, 21 Dec 2023 15:31:01 +0100 (CET)","by phobos.denx.de (Postfix, from userid 109)\n id 1F3DC8785B; Thu, 21 Dec 2023 15:30:59 +0100 (CET)","from dfw.source.kernel.org (dfw.source.kernel.org\n [IPv6:2604:1380:4641:c500::1])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 22DE7876C6\n for ; Thu, 21 Dec 2023 15:30:56 +0100 (CET)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by dfw.source.kernel.org (Postfix) with ESMTP id 6AEB061937\n for ; Thu, 21 Dec 2023 14:30:54 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 11E37C433C7\n for ; Thu, 21 Dec 2023 14:30:54 +0000 (UTC)","by mail-lf1-f44.google.com with SMTP id\n 2adb3069b0e04-50e587fb62fso1304382e87.2\n for ; Thu, 21 Dec 2023 06:30:53 -0800 (PST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,\n SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no\n version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n s=k20201202; t=1703169054;\n bh=OEBZ6p63sjTkW3Yk5dnKU9NG+4OMfKh+D8wi0t4gbvI=;\n h=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n b=sqxSU2SKjq4jOLnNVZKMvhtezYvRUhITev29n1eiJrV6KHKvK32a8N98JqBX13gKL\n +OkLSfVCc3pzXUKumWzd8RaPCjYAwA973k5lQ76XhEmd+S7RXbidLj6h6HPA+h/b2r\n v3sRJtJ5dfX13Z7Z76mRY3LOMhO3pP0mLxgGXLPa7KTvnm8/lsQrEkpQ8qLZH9hlEZ\n n7vQnD6jJNsAadbmFeX1RN5dtVKvJGl+H6tDI0fi9xh/y5LAKBq+1/rAFx7nxlp5Km\n 3yXJa3ji+YQKhFXvmhHmEtnohhBo7FoiVQ+FXOWM1JwUqZWRzFTA2Ul2lhc3QRZZrH\n hdVi0NLA+r0jQ==","X-Gm-Message-State":"AOJu0YzVpj0TmxhoQV0H58qHyr6n2LlKspQSVizaMcEV+guhl2SXQnes\n 5FQOqPNB4Whi5IjCq37tf7dvse42976jrj+16Ok=","X-Google-Smtp-Source":"\n AGHT+IHPdxcsw7CIc8Zz9R57s+h3yCpmC0MOks9IUm441YI5k7PHlncS4N04abFTrQMbhLyNWoHo0BpkrAZ7Up7QGeI=","X-Received":"by 2002:ac2:419a:0:b0:50c:222b:2489 with SMTP id\n z26-20020ac2419a000000b0050c222b2489mr9235479lfh.135.1703169052253; Thu, 21\n Dec 2023 06:30:52 -0800 (PST)","MIME-Version":"1.0","References":"<20230926194242.2732127-1-sjg@chromium.org>\n <20230926194242.2732127-2-sjg@chromium.org>\n \n \n \n \n \n \n \n \n ","In-Reply-To":"\n ","From":"Ard Biesheuvel ","Date":"Thu, 21 Dec 2023 15:30:40 +0100","X-Gmail-Original-Message-ID":"\n ","Message-ID":"\n ","Subject":"Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages","To":"\"Chiu, Chasel\" ","Cc":"Simon Glass ,\n \"devicetree@vger.kernel.org\" ,\n Mark Rutland ,\n Rob Herring , \"Tan, Lean Sheng\" ,\n lkml , Dhaval Sharma ,\n \"Brune, Maximilian\" ,\n Yunhui Cui ,\n \"Dong, Guo\" , Tom Rini ,\n ron minnich , \"Guo, Gua\" ,\n \"linux-acpi@vger.kernel.org\" ,\n U-Boot Mailing List ","Content-Type":"text/plain; charset=\"UTF-8\"","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}}]