On Tue, 28 Nov 2023 at 21: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-m...
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.
The gEfiMemoryTypeInformationGuid HOB typically carries platform defaults, and the actual memory type information is kept in a non-volatile EFI variable, which gets updated when the memory usage changes. Is this different for UefiPayloadPkg?
(For those among the cc'ees less versed in EFI/EDK2: when you get the 'config changed -rebooting' message from the boot firmware, it typically means that this memory type table has changed, and a reboot is necessary.)
So the platform init needs to read this variable, or get the information in a different way. I assume it is the payload, not the platform init that updates the variable when necessary. This means the information flows from payload(n) to platform init(n+1), where n is a monotonic index tracking consecutive boots of the system.
Can you explain how the DT fits into this? How are the runtime-code and runtime-data memory reservation nodes under /reserved-memory used to implement this information exchange between platform init and payload? And how do the HOB and the EFI variable fit into this picture?