lkml.org 
[lkml]   [2023]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v7 2/2] schemas: Add some common reserved-memory usages
    Hi,

    On Mon, 11 Dec 2023 at 10:52, Simon Glass <sjg@chromium.org> wrote:
    >
    > Hi,
    >
    > On Tue, 28 Nov 2023 at 13:31, Chiu, Chasel <chasel.chiu@intel.com> wrote:
    > >
    > >
    > >
    > >
    > > > -----Original Message-----
    > > > From: Ard Biesheuvel <ardb@kernel.org>
    > > > Sent: Tuesday, November 28, 2023 10:08 AM
    > > > To: Chiu, Chasel <chasel.chiu@intel.com>
    > > > Cc: Simon Glass <sjg@chromium.org>; devicetree@vger.kernel.org; Mark Rutland
    > > > <mark.rutland@arm.com>; Rob Herring <robh@kernel.org>; Tan, Lean Sheng
    > > > <sheng.tan@9elements.com>; lkml <linux-kernel@vger.kernel.org>; Dhaval
    > > > Sharma <dhaval@rivosinc.com>; Brune, Maximilian
    > > > <maximilian.brune@9elements.com>; Yunhui Cui <cuiyunhui@bytedance.com>;
    > > > Dong, Guo <guo.dong@intel.com>; Tom Rini <trini@konsulko.com>; ron minnich
    > > > <rminnich@gmail.com>; Guo, Gua <gua.guo@intel.com>; linux-
    > > > acpi@vger.kernel.org; U-Boot Mailing List <u-boot@lists.denx.de>
    > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
    > > > usages
    > > >
    > > > You are referring to a 2000 line patch so it is not 100% clear where to look tbh.
    > > >
    > > >
    > > > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel <chasel.chiu@intel.com> wrote:
    > > > >
    > > > >
    > > > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for
    > > > related example code.
    > > > >
    > > >
    > > > That refers to a 'memory-allocation' node, right? How does that relate to the
    > > > 'reserved-memory' node?
    > > >
    > > > And crucially, how does this clarify in which way "runtime-code" and "runtime-
    > > > data" reservations are being used?
    > > >
    > > > Since the very beginning of this discussion, I have been asking repeatedly for
    > > > examples that describe the wider context in which these reservations are used.
    > > > The "runtime" into runtime-code and runtime-data means that these regions have
    > > > a special significance to the operating system, not just to the next bootloader
    > > > stage. So I want to understand exactly why it is necessary to describe these
    > > > regions in a way where the operating system might be expected to interpret this
    > > > information and act upon it.
    > > >
    > >
    > >
    > > 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:
    > > https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#uefi-memory-types-and-mapping-to-acpi-address-range-types
    > >
    > > 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.
    > > 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.
    > >
    > > The Payload flow will be like this:
    > > Payload creates built-in default MemoryTypes table ->
    > > FDT reserved-memory node to override if required (this also ensures the same memory map cross boots so ACPI S4 works) ->
    > > Build gEfiMemoryTypeInformationGuid HOB by "platfom specific" MemoryTypes Table ->
    > > DxeMain/GCD to consume this MemoryTypes table and setup memory service ->
    > > Install memory types table to UEFI system table.Configuration table...
    > >
    > > 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)
    > > This FDT node could allow flexibility/compatibility without rebuilding Payload binary.
    > >
    > > Not sure if I answered all your questions, please highlight which area you need more information.
    >
    > Any more thoughts on this? If not, I would like to see this patch
    > applied, please.

    I am really not sure who or what is holding this up, so far.

    Can we perhaps get this applied in time for Christmas? It would be a
    nice end to the year.

    Regards,
    Simon

    \
     
     \ /
      Last update: 2023-12-20 05:47    [W:6.066 / U:0.140 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site