From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C3D841C90; Tue, 28 Nov 2023 18:08:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XWiG9o0D" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CADF9C433CD; Tue, 28 Nov 2023 18:08:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701194883; bh=4DwB38wbaKFqe7hUkjoK0KTOX2HU0BmeTqXJcyORlu4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=XWiG9o0Dtq787TusZ2eK1KJKrxDR6ZWsvWOUs1UhQwi/EqTGjSVzPy1M+BcivIXz8 nKM4NnDzVmlPy4d56Q2UCesllUtMPZGL/0QkX7IMNeaphkjFm2UDe7x33QM08aSyNg HT+7MRyZ5Ty1ggpvUZ0/+5D4vejZIgr5QVPyS7fPyIAE7W8mxdCvLJL9bT57/U9ZSM 5KfMaTnpcjctst3YM+476nbFzErxYqznvVsXBJ+2Ovg6wsBotr7yBLXpwoWP9LvQci glX1WDuLypxtZc6NAtIkU+q16SZ7p4PwqSyOVYlSslQcaGx7xyqM26ZGNPB+3i2to5 XGQqVb9QkNvWQ== Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2c9b8363683so9606181fa.3; Tue, 28 Nov 2023 10:08:03 -0800 (PST) X-Gm-Message-State: AOJu0YykdBSVQZeJ/uQbgEdgEgpTbvgOz+fxikU1OYw7/ewtiK8U7EUo 0Rm4X68zssgfIvKV8SzzOjwwz8QJ5jE4w3mIjgY= X-Google-Smtp-Source: AGHT+IEMmvfyq0v5/2oBeBE/oqLc1Eu+CJpsjOxQOhU1mp+t/ys+FzWHNt4xUEoc92KVGBiOkt8B0IacbD0oqbAchGI= X-Received: by 2002:a2e:b0e1:0:b0:2c9:b9db:73 with SMTP id h1-20020a2eb0e1000000b002c9b9db0073mr988987ljl.20.1701194881929; Tue, 28 Nov 2023 10:08:01 -0800 (PST) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20230926194242.2732127-1-sjg@chromium.org> <20230926194242.2732127-2-sjg@chromium.org> In-Reply-To: From: Ard Biesheuvel Date: Tue, 28 Nov 2023 19:07:50 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages To: "Chiu, Chasel" Cc: Simon Glass , "devicetree@vger.kernel.org" , Mark Rutland , Rob Herring , "Tan, Lean Sheng" , lkml , Dhaval Sharma , "Brune, Maximilian" , Yunhui Cui , "Dong, Guo" , Tom Rini , ron minnich , "Guo, Gua" , "linux-acpi@vger.kernel.org" , U-Boot Mailing List Content-Type: text/plain; charset="UTF-8" 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 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. > > > -----Original Message----- > > From: Chiu, Chasel > > Sent: Tuesday, November 21, 2023 10:34 AM > > To: Ard Biesheuvel ; Simon Glass > > Cc: devicetree@vger.kernel.org; Mark Rutland ; Rob > > Herring ; Tan, Lean Sheng ; lkml > > ; Dhaval Sharma ; Brune, > > Maximilian ; Yunhui Cui > > ; Dong, Guo ; Tom Rini > > ; ron minnich ; Guo, Gua > > ; linux-acpi@vger.kernel.org; U-Boot Mailing List > boot@lists.denx.de>; Chiu, Chasel > > Subject: RE: [PATCH v7 2/2] schemas: Add some common reserved-memory > > usages > > > > > > Hi Ard, > > > > Here is the POC PR for your reference: > > https://github.com/tianocore/edk2/pull/4969/files#diff- > > ccebabae5274b21634723a2111ee0de11bed6cfe8cb206ef9e263d9c5f926a9cR26 > > 8 > > Please note that this PR is still in early phase and expected to have significant > > changes. > > > > The idea is that payload entry will create gEfiMemoryTypeInformationGuid HOB > > with payload default memory types and allow FDT to override if correspond node > > present. > > Please let me know if you have questions or suggestions. > > > > Thanks, > > Chasel > > > > > > > -----Original Message----- > > > From: Ard Biesheuvel > > > Sent: Tuesday, November 21, 2023 8:42 AM > > > To: Simon Glass > > > Cc: Chiu, Chasel ; devicetree@vger.kernel.org; > > > Mark Rutland ; Rob Herring ; > > > Tan, Lean Sheng ; lkml > > > ; Dhaval Sharma ; > > > Brune, Maximilian ; Yunhui Cui > > > ; Dong, Guo ; Tom Rini > > > ; ron minnich ; Guo, Gua > > > ; linux- acpi@vger.kernel.org; U-Boot Mailing List > > > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory > > > usages > > > > > > On Mon, 20 Nov 2023 at 21:12, Simon Glass wrote: > > > > > > > > Hi, > > > > > > > > On Mon, 13 Nov 2023 at 11:09, Chiu, Chasel wrote: > > > > > > > > > > > > > > > Hi Ard, > > > > > > > > > > Please see my reply below inline. > > > > > > > > > > Thanks, > > > > > Chasel > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ard Biesheuvel > > > > > > Sent: Saturday, November 11, 2023 3:04 AM > > > > > > To: Chiu, Chasel > > > > > > Cc: Simon Glass ; devicetree@vger.kernel.org; > > > > > > Mark Rutland ; Rob Herring > > > > > > ; Tan, Lean Sheng ; > > > > > > lkml ; Dhaval Sharma > > > > > > ; Brune, Maximilian > > > > > > ; Yunhui Cui > > > > > > ; Dong, Guo ; Tom > > > > > > Rini ; ron minnich ; > > > > > > Guo, Gua ; linux- acpi@vger.kernel.org; > > > > > > U-Boot Mailing List > > > > > > Subject: Re: [PATCH v7 2/2] schemas: Add some common > > > > > > reserved-memory usages > > > > > > > > > > > > On Sat, 11 Nov 2023 at 04:20, Chiu, Chasel > > wrote: > > > > > > > > > > > > > > > > > > > > > Just sharing some usage examples from UEFI/EDK2 scenario. > > > > > > > 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) > > > > > > > > > > > > So how would EDK2 reconstruct the entire EFI memory map from > > > > > > just these unannotated /reserved-memory nodes? The EFI memory > > > > > > map contains much more information than that, and all of it has > > > > > > to match the pre-hibernate situation, right? Can you given an example? > > > > > > > > > > > > > > > Here we listed only typically memory types that may change cross > > > > > different > > > platforms. > > > > > 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. > > > > > In the future if we see a need to add new memory types we will > > > > > discuss and > > > add it to FDT schema. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > Agreed. But can you explain how a EDK2 payload might make > > > > > > meaningful use of 'runtime-code' regions provided via DT by the > > > > > > non-EDK2 platform init? Can you give an example? > > > > > > > > > > > > > > > Runtime-code/data is used by UEFI payload for booting UEFI OS > > > > > which > > > required UEFI runtime services. > > > > > 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. > > > > > 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) > > > > > > > > > > > > > > > > > > > > > > > Under below assumption: > > > > > > > FDT OS impact has been evaluated and taken care by > > > > > > > relevant > > > > > > experts/stakeholders. > > > > > > > Reviewed-by: Chasel Chiu > > > > > > > > > > > > > > > > > > > I am sorry but I don't know what 'FDT OS impact' means. We are > > > > > > talking about a firmware-to-firmware abstraction that has the > > > > > > potential to leak into the OS visible interface. > > > > > > > > > > > > I am a maintainer in the Tianocore project myself, so it would > > > > > > help if you could explain who these relevant experts and > > > > > > stakeholders are. Was this discussed on the edk2-devel mailing > > > > > > list? If so, apologies for missing it but I may not have been cc'ed perhaps? > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > 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) > > > > > > > > > > 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. > > > > > 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. > > > > > > > > We discussed this and just to clarify, 'FDT OS' is not a special OS, > > > > it is just Linux. > > > > > > > > So, with the above, are we all on the same page? Can the patch be > > > > applied, perhaps? If not, what other discussion is needed? > > > > > > > > > > An example of how a platform-init/payload combination would make > > > meaningful use of such runtime-code/data regions.