Hi Rob, On Fri, 13 Oct 2023 at 13:42, Rob Herring <robh@xxxxxxxxxx> wrote: > > On Fri, Oct 6, 2023 at 7:03 PM Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > > > Hi Ard, > > > > On Fri, 6 Oct 2023 at 17:00, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > On Fri, 6 Oct 2023 at 20:17, Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > > > > > > > Hi Ard, > > > > > > > > On Fri, 6 Oct 2023 at 11:33, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > > > > > > > On Mon, 2 Oct 2023 at 19:54, Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > > > > > > > > > > > Hi Rob, > > > > > > > > > > > > On Tue, 26 Sept 2023 at 13:42, Simon Glass <sjg@xxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > It is common to split firmware into 'Platform Init', which does the > > > > > > > initial hardware setup and a "Payload" which selects the OS to be booted. > > > > > > > Thus an handover interface is required between these two pieces. > > > > > > > > > > > > > > Where UEFI boot-time services are not available, but UEFI firmware is > > > > > > > present on either side of this interface, information about memory usage > > > > > > > and attributes must be presented to the "Payload" in some form. > > > > > > > > > > > > > > This aims to provide an small schema addition for the memory mapping > > > > > > > needed to keep these two pieces working together well. > > > > > > > > > > > > > > Signed-off-by: Simon Glass <sjg@xxxxxxxxxxxx> > > > > > > > --- > > > > > > > > > > > > > > Changes in v7: > > > > > > > - Rename acpi-reclaim to acpi > > > > > > > - Drop individual mention of when memory can be reclaimed > > > > > > > - Rewrite the item descriptions > > > > > > > - Add back the UEFI text (with trepidation) > > > > > > > > > > > > I am again checking on this series. Can it be applied, please? > > > > > > > > > > > > > > > > Apologies for the delay in response. I have been away. > > > > > > > > OK, I hope you had a nice trip. > > > > > > > > > > Thanks, it was wonderful! > > > > > > > > > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > - Drop mention of UEFI > > > > > > > - Use compatible strings instead of node names > > > > > > > > > > > > > > Changes in v5: > > > > > > > - Drop the memory-map node (should have done that in v4) > > > > > > > - Tidy up schema a bit > > > > > > > > > > > > > > Changes in v4: > > > > > > > - Make use of the reserved-memory node instead of creating a new one > > > > > > > > > > > > > > Changes in v3: > > > > > > > - Reword commit message again > > > > > > > - cc a lot more people, from the FFI patch > > > > > > > - Split out the attributes into the /memory nodes > > > > > > > > > > > > > > Changes in v2: > > > > > > > - Reword commit message > > > > > > > > > > > > > > .../reserved-memory/common-reserved.yaml | 71 +++++++++++++++++++ > > > > > > > 1 file changed, 71 insertions(+) > > > > > > > create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml > > > > > > > > > > > > > > diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml b/dtschema/schemas/reserved-memory/common-reserved.yaml > > > > > > > new file mode 100644 > > > > > > > index 0000000..f7fbdfd > > > > > > > --- /dev/null > > > > > > > +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml > > > > > > > @@ -0,0 +1,71 @@ > > > > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > > > > > > +%YAML 1.2 > > > > > > > +--- > > > > > > > +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml# > > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > > > + > > > > > > > +title: Common memory reservations > > > > > > > + > > > > > > > +description: | > > > > > > > + Specifies that the reserved memory region can be used for the purpose > > > > > > > + indicated by its compatible string. > > > > > > > + > > > > > > > + Clients may reuse this reserved memory if they understand what it is for, > > > > > > > + subject to the notes below. > > > > > > > + > > > > > > > +maintainers: > > > > > > > + - Simon Glass <sjg@xxxxxxxxxxxx> > > > > > > > + > > > > > > > +allOf: > > > > > > > + - $ref: reserved-memory.yaml > > > > > > > + > > > > > > > +properties: > > > > > > > + compatible: > > > > > > > + description: | > > > > > > > + This describes some common memory reservations, with the compatible > > > > > > > + string indicating what it is used for: > > > > > > > + > > > > > > > + acpi: Advanced Configuration and Power Interface (ACPI) tables > > > > > > > + acpi-nvs: ACPI Non-Volatile-Sleeping Memory (NVS). This is reserved by > > > > > > > + the firmware for its use and is required to be saved and restored > > > > > > > + across an NVS sleep > > > > > > > + boot-code: Contains code used for booting which is not needed by the OS > > > > > > > + boot-code: Contains data used for booting which is not needed by the OS > > > > > > > + runtime-code: Contains code used for interacting with the system when > > > > > > > + running the OS > > > > > > > + runtime-data: Contains data used for interacting with the system when > > > > > > > + running the OS > > > > > > > + > > > > > > > + enum: > > > > > > > + - acpi > > > > > > > + - acpi-nvs > > > > > > > + - boot-code > > > > > > > + - boot-data > > > > > > > + - runtime-code > > > > > > > + - runtime-data > > > > > > > + > > > > > > > > > > As I mentioned a few times already, I don't think these compatibles > > > > > should be introduced here. > > > > > > > > > > A reserved region has a specific purpose, and the compatible should be > > > > > more descriptive than the enum above. If the consumer does not > > > > > understand this purpose, it should simply treat the memory as reserved > > > > > and not touch it. Alternatively, these regions can be referenced from > > > > > other DT nodes using phandles if needed. > > > > > > > > We still need some description of what these regions are used for, so > > > > that the payload can use the correct regions. I do not have any other > > > > solution to this problem. We are in v7 at present. At least explain > > > > where you want the compatible strings to be introduced. > > > > > > > > > > My point is really that by themselves, these regions are not usable by > > > either a payload or an OS that consumes this information. Unless there > > > is some other information being provided (via DT I imagine) that > > > describes how these things are supposed to be used, they are nothing > > > more than memory reservations that should be honored, and providing > > > this arbitrary set of labels is unnecessary. > > > > > > > What sort of extra detail are you looking for? Please be specific and > > > > preferably add some suggestions so I can close this out ASAP. > > > > > > > > > > A payload or OS can do nothing with a memory reservation called > > > 'runtime-code' it it doesn't know what is inside. > > Agreed. The question is WHAT runtime-code? The compatible needs to answer that. > > For example, we have 'ramoops' as a compatible in reserved memory. > That tells us *exactly* what's there. We know how to parse it. If we > know ramoops is not supported, then we know we can toss it out and > reclaim the memory. So if we said: compatible = "runtime-code-efi" would that be OK? We seem to be in catch 22 here, because if I don't mention EFI unhappy, but if I do, Ard is unhappy. What about the boottime code....you want to know which project it is from? + - acpi + - acpi-nvs Those two should be enough info, right? + - boot-code + - boot-data For these, they don't pertain to the OS, so perhaps they are OK? In any case, using a generic term like this makes some sense to me. We can always add a new compatible like "efi-boottime-services" later. It may be that the boottime services would be handled by the payload, so not needed in all cases. + - runtime-code + - runtime-data See above. > > > > > So there is another > > > DT node somewhere that describes this, and that can simply point to > > > this region (via a phandle) if it needs to describe the > > > correspondence. This is more idiomatic for DT afaik (but I am not the > > > expert). > > I don't see why we need that indirection. > > > > But more importantly, it avoids overloading some vague > > > labels with behavior (e.g., executable permissions for code regions) > > > that should only be displayed for regions with a particular use, > > > rather than for a ill defined class of reservations the purpose of > > > which is not clear. > > > > > > What I am trying to avoid is the OS ending up being forced to consume > > > this information in parallel to the EFI memory map, and having to > > > reconcile them. I'd be much happier if this gets contributed to a spec > > > that only covers firmware-to-firmware, and is prevented from leaking > > > into the OS facing interface. > > > > I don't know about "another DT node". We don't have one at present. > > > > There is already a note in the DT spec about this: > > > > > 3.5.4 /reserved-memory and UEFI > > > > > When booting via [UEFI], static /reserved-memory regions must also be listed in the system memory map obtained > > > via the GetMemoryMap() UEFI boot time service as defined in [UEFI] § 7.2. The reserved memory regions need to be > > > included in the UEFI memory map to protect against allocations by UEFI applications. > > > > > > Reserved regions with the no-map property must be listed in the memory map with type EfiReservedMemoryType. All > > > other reserved regions must be listed with type EfiBootServicesData. > > > > > > Dynamic reserved memory regions must not be listed in the [UEFI] memory map because they are allocated by the OS > > > after exiting firmware boot services. > > > > I don't fully understand what all that means, but does it cover your concern? > > This section is purely about using UEFI mechanisms to load and boot > the OS. If we're not talking about this stage of booting, then none of > this applies. OK Regards, Simon
