On Mon, Sep 07, 2020 at 03:22:22PM +0100, Grant Likely wrote: > I've not heard back, and I've got a conflict this afternoon. I'm going > to resched for later in the week. Going to aim for Wednesday.
Are you trying the schedule a full EBBR meeting or just a discussion about this thread? Daniel. > > g. > > On 02/09/2020 13:58, Grant Likely wrote: > > > > > > On 02/09/2020 07:52, Ard Biesheuvel wrote: > > > On Wed, 2 Sep 2020 at 09:48, Heinrich Schuchardt <[email protected]> > > > wrote: > > > > > > > > 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. > > > > > > > > > > There is definitely a gap, but reserved regions are already omitted > > > from the linear map in Linux, so that is not a problem, i.e., the > > > 'no-map' will be honoured as long as the firmware ensures that no-map > > > regions are described as EfiReservedMemory. > > > > > > In other words, today we just assume that the /reserved-memory node > > > and the EFI memory map do not contradict each other, but we have no > > > definition or explicit requirement anywhere what that actually means. > > > > Yeah, we need to clean this up and make it consistent. Would like to > > have a call about this and look at some examples before trying to draft > > the requirement. We probably need something in either DT or EBBR that > > specifies exactly what is expected when using the UEFI boot path. > > > > Does Monday 15:30BST work for a call? > > > > g. > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > 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
