On 9/1/20 10:51 AM, Ard Biesheuvel wrote: > On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt <[email protected]> wrote: >> >> On 8/31/20 9:01 PM, Ard Biesheuvel wrote: >>> On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt <[email protected]> >>> wrote: >>>> >>>> Closes: #52 >>>> >>>> The no-map property of the /reserved-memory DT node is used by Linux to >>>> signal that a memory region shall not be mapped and that speculative access >>>> shall not be permitted. >>>> >>>> The memory map returned by GetMemoryMap() does not have a flag >>>> corresponding to no-map. So the closest thing we can do is not to include >>>> no-map reserved memory into the map returned by GetMemoryMap(). >>>> >> >> Dear Ard, >> >> thanks for reviewing. >> >>> >>> This violates the UEFI spec, which stipulates that the memory map >>> describes all memory, no matter how it is used. It also interferes >>> with the heuristics we use in Linux to decide which memory attributes >>> to use when the code gets mapped explicitly (i.e., by a driver), which >>> is permitted in the context of the /reserved-memory node (the no-map >>> attribute applies to the linear map, but the region may still be >>> mapped for other reasons). Note that an omitted region cannot carry >>> EFI_MEMORY_WC/WT/WB attributes either. >> >> Do you have an example of a no-map /reserved-memory node used in Linux? >> > > Linux ignores DT provided memory reservations entirely when booting in > UEFI mode, which is why it is important that the EFI memory map is > synchronized. I am not aware of any examples.
Hello Ard, I found the following compatibility strings for no-map areas in the Linux device trees: compatible = "shared-dma-pool" compatible = "qcom,rmtfs-mem" compatible = "qcom,cmd-db" If Linux simply ignores the no-map property from the device-tree when booting via UEFI and in UEFI we simply map those areas as reserved, there is a conceptual gap as you already stated in a separate mail. Best regards Heinrich > >>> >>> So a better approach would be to mandate that these regions are listed >>> in the EFI memory map as EFI reserved regions, with appropriate memory >>> attributes. (Note that on ARM, regions that are really memory rather >>> than MMIO registers, and that are expected to be used with unaligned >>> accesses and/or DC ZVA instructions must be mapped as memory, and so >>> the default of EFI_MEMORY_UC is not appropriate) >>> >> >> It is unclear to me which memory attributes you regard as appropriate. >> > > Memory attributes (WB/WT/WC) as opposed to device attributes (UC). A > region mapped as device memory does not behave as memory in terms of > the architecture or the UEFI bindings for ARM (which specify that > unaligned accesses should be permitted, for instance) > _______________________________________________ > boot-architecture mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/boot-architecture > _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
