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().
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de --- source/chapter2-uefi.rst | 4 ++++ source/references.rst | 4 ++++ 2 files changed, 8 insertions(+)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 2add2de..1e57164 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -74,6 +74,10 @@ that virtual addresses must equal physical addresses.
The default RAM allocated attribute must be EFI_MEMORY_WB.
+Reserved memory with property no-map [RESMEM]_ in the /reserved-memory +device-tree node shall not be included in the memory map returned by +GetMemoryMap(). + Configuration Tables --------------------
diff --git a/source/references.rst b/source/references.rst index 1eb0509..2434137 100644 --- a/source/references.rst +++ b/source/references.rst @@ -16,6 +16,10 @@ https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Interface.pdf`_ 30 January 2015, `Arm Limited http://arm.com`_
+.. [RESMEM] `Reserved memory regions + https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt`_, + 21 July 2020, Linux kernel + .. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0) https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirements.pdf`_ 8 March 2016, `Arm Limited http://arm.com`_ -- 2.28.0
On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt xypron.glpk@gmx.de 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().
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.
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)
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
source/chapter2-uefi.rst | 4 ++++ source/references.rst | 4 ++++ 2 files changed, 8 insertions(+)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 2add2de..1e57164 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -74,6 +74,10 @@ that virtual addresses must equal physical addresses.
The default RAM allocated attribute must be EFI_MEMORY_WB.
+Reserved memory with property no-map [RESMEM]_ in the /reserved-memory +device-tree node shall not be included in the memory map returned by +GetMemoryMap().
Configuration Tables
diff --git a/source/references.rst b/source/references.rst index 1eb0509..2434137 100644 --- a/source/references.rst +++ b/source/references.rst @@ -16,6 +16,10 @@ https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Interface.pdf`_ 30 January 2015, `Arm Limited http://arm.com`_
+.. [RESMEM] `Reserved memory regions
- https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt`_,
- 21 July 2020, Linux kernel
.. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0) https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirements.pdf`_ 8 March 2016, `Arm Limited http://arm.com`_ -- 2.28.0
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 8/31/20 9:01 PM, Ard Biesheuvel wrote:
On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt xypron.glpk@gmx.de 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?
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.
Best regards
Heinrich
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
source/chapter2-uefi.rst | 4 ++++ source/references.rst | 4 ++++ 2 files changed, 8 insertions(+)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 2add2de..1e57164 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -74,6 +74,10 @@ that virtual addresses must equal physical addresses.
The default RAM allocated attribute must be EFI_MEMORY_WB.
+Reserved memory with property no-map [RESMEM]_ in the /reserved-memory +device-tree node shall not be included in the memory map returned by +GetMemoryMap().
Configuration Tables
diff --git a/source/references.rst b/source/references.rst index 1eb0509..2434137 100644 --- a/source/references.rst +++ b/source/references.rst @@ -16,6 +16,10 @@ https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Interface.pdf`_ 30 January 2015, `Arm Limited http://arm.com`_
+.. [RESMEM] `Reserved memory regions
- https://www.kernel.org/doc/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt`_,
- 21 July 2020, Linux kernel
.. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0) https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirements.pdf`_ 8 March 2016, `Arm Limited http://arm.com`_ -- 2.28.0
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/31/20 9:01 PM, Ard Biesheuvel wrote:
On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt xypron.glpk@gmx.de 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.
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)
On 9/1/20 10:51 AM, Ard Biesheuvel wrote:
On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/31/20 9:01 PM, Ard Biesheuvel wrote:
On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt xypron.glpk@gmx.de 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 boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Wed, 2 Sep 2020 at 09:48, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 9/1/20 10:51 AM, Ard Biesheuvel wrote:
On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/31/20 9:01 PM, Ard Biesheuvel wrote:
On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt xypron.glpk@gmx.de 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.
On 02/09/2020 07:52, Ard Biesheuvel wrote:
On Wed, 2 Sep 2020 at 09:48, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 9/1/20 10:51 AM, Ard Biesheuvel wrote:
On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/31/20 9:01 PM, Ard Biesheuvel wrote:
On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt xypron.glpk@gmx.de 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.
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.
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 xypron.glpk@gmx.de wrote:
On 9/1/20 10:51 AM, Ard Biesheuvel wrote:
On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/31/20 9:01 PM, Ard Biesheuvel wrote:
On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt xypron.glpk@gmx.de 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.
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 xypron.glpk@gmx.de wrote:
On 9/1/20 10:51 AM, Ard Biesheuvel wrote:
On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 8/31/20 9:01 PM, Ard Biesheuvel wrote: > On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt > xypron.glpk@gmx.de 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 boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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 xypron.glpk@gmx.de wrote:
On 9/1/20 10:51 AM, Ard Biesheuvel wrote:
On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt xypron.glpk@gmx.de wrote: > > On 8/31/20 9:01 PM, Ard Biesheuvel wrote: >> On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt >> xypron.glpk@gmx.de 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 boot-architecture@lists.linaro.org 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.
On 07.09.20 16:56, Grant Likely wrote:
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.
Wednesday 17:30 UTC+2 would be fine for me.
Best regards
Heinrich
On Tue, 8 Sep 2020 at 09:39, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 07.09.20 16:56, Grant Likely wrote:
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.
Wednesday 17:30 UTC+2 would be fine for me.
Works for me
On 09/09/2020 09:38, Ard Biesheuvel wrote:
On Tue, 8 Sep 2020 at 09:39, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 07.09.20 16:56, Grant Likely wrote:
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.
Wednesday 17:30 UTC+2 would be fine for me.
Today at 17:30 UTC+2 it is. Here's a zoom meeting:
Join Zoom Meeting https://armltd.zoom.us/j/93820204268?pwd=S01QYzhEM25XRkw3WWlRdXV1L3BuZz09&am...
Meeting ID: 938 2020 4268 Passcode: 616751 One tap mobile +14086380968,,93820204268#,,,,,,0#,,616751# US (San Jose) +16465189805,,93820204268#,,,,,,0#,,616751# US (New York)
Dial by your location +1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston) Meeting ID: 938 2020 4268 Passcode: 616751 Find your local number: https://armltd.zoom.us/u/ab1GCAjvb8
Join by SIP 93820204268@zoomcrc.com
Join by H.323 162.255.37.11 (US West) 162.255.36.11 (US East) 115.114.131.7 (India Mumbai) 115.114.115.7 (India Hyderabad) 213.19.144.110 (Amsterdam Netherlands) 213.244.140.110 (Germany) 103.122.166.55 (Australia) 209.9.211.110 (Hong Kong SAR) 64.211.144.160 (Brazil) 69.174.57.160 (Canada) 207.226.132.110 (Japan) Meeting ID: 938 2020 4268 Passcode: 616751 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.
On 07/09/2020 15:56, Grant Likely wrote:
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.
Next EBBR meeting will be 16:00BST Monday, 14th Aug. I'll add you to the calendar invite.
g.
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 xypron.glpk@gmx.de wrote:
On 9/1/20 10:51 AM, Ard Biesheuvel wrote: > On Tue, 1 Sep 2020 at 09:15, Heinrich Schuchardt > xypron.glpk@gmx.de wrote: >> >> On 8/31/20 9:01 PM, Ard Biesheuvel wrote: >>> On Mon, 31 Aug 2020 at 19:37, Heinrich Schuchardt >>> xypron.glpk@gmx.de 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 boot-architecture@lists.linaro.org 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@lists.linaro.org
-
Ard Biesheuvel -
Daniel Thompson -
Grant Likely -
Heinrich Schuchardt