On some Qualcomm platforms the firwmare, or hardware, does not
gracefully handle memory protection of the rmtfs memory region when
placed adjacent to other protected region. Some DeviceTree authors have
worked around this issue by explicitly reserving the space around the
region, but this prevents such author to use rely on the OS to place the
region, through the use of "size" (instead of a fixed location).
Introduce a flag to indicate that guard pages need be carved at the
beginning and end of the memory region. The user shall account for the
two 4k blocks in the defined size.
Signed-off-by: Bjorn Andersson <[email protected]>
---
.../devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
index bab982f00485..2d7be508c5a0 100644
--- a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
+++ b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
@@ -26,6 +26,17 @@ properties:
description: >
identifier of the client to use this region for buffers
+ qcom,use-guard-pages:
+ type: boolean
+ description: >
+ Indicates that the firmware, or hardware, does not gracefully handle
+ memory protection of this region when placed adjacent to other protected
+ memory regions, and that padding around the used portion of the memory
+ region is necessary.
+
+ When this is set, the first and last 4kB should be left unused, and the
+ effective size of the region will thereby shrink with 8kB.
+
qcom,vmid:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: >
--
2.25.1
On 9/21/23 04:37, Bjorn Andersson wrote:
> On some Qualcomm platforms the firwmare, or hardware, does not
> gracefully handle memory protection of the rmtfs memory region when
> placed adjacent to other protected region. Some DeviceTree authors have
> worked around this issue by explicitly reserving the space around the
> region, but this prevents such author to use rely on the OS to place the
> region, through the use of "size" (instead of a fixed location).
>
> Introduce a flag to indicate that guard pages need be carved at the
> beginning and end of the memory region. The user shall account for the
> two 4k blocks in the defined size.
>
> Signed-off-by: Bjorn Andersson <[email protected]>
> ---
> .../devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
> index bab982f00485..2d7be508c5a0 100644
> --- a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
> +++ b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml
> @@ -26,6 +26,17 @@ properties:
> description: >
> identifier of the client to use this region for buffers
>
> + qcom,use-guard-pages:
> + type: boolean
> + description: >
> + Indicates that the firmware, or hardware, does not gracefully handle
> + memory protection of this region when placed adjacent to other protected
> + memory regions, and that padding around the used portion of the memory
> + region is necessary.
> +
> + When this is set, the first and last 4kB should be left unused, and the
> + effective size of the region will thereby shrink with 8kB.
kiB
Konrad
On 21/09/2023 04:37, Bjorn Andersson wrote:
> On some Qualcomm platforms the firwmare, or hardware, does not
> gracefully handle memory protection of the rmtfs memory region when
> placed adjacent to other protected region. Some DeviceTree authors have
> worked around this issue by explicitly reserving the space around the
> region, but this prevents such author to use rely on the OS to place the
> region, through the use of "size" (instead of a fixed location).
>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
> +
> + When this is set, the first and last 4kB should be left unused, and the
> + effective size of the region will thereby shrink with 8kB.
Maybe we should not reference the actual size (4 and 8 kB), but rather
page - "the first and last pages in mapping should be left unused ..." etc?
Best regards,
Krzysztof