On 07/09/2020 15:55, Daniel Thompson wrote:
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?
Only about this thread. The next EBBR meeting will be next week Monday.
g.
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
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
