With the P2M pages pool bounding the domain memory runtime allocation
and the documented minimal size requirement of the static heap, it is
safe to mark static heap feature as supported.

Signed-off-by: Henry Wang <Henry.Wang@arm.com>
---
 SUPPORT.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index cf2ddfacaf..ddcf8a13a7 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -298,7 +298,7 @@ pre-defined by configuration using physical address ranges.
 Allow reserving parts of RAM through the device tree using physical
 address ranges as heap.
 
-    Status, ARM: Tech Preview
+    Status, ARM: Supported
 
 ### Memory Sharing
 
-- 
2.17.1

On Thu, 13 Oct 2022, Henry Wang wrote:
> With the P2M pages pool bounding the domain memory runtime allocation
> and the documented minimal size requirement of the static heap, it is
> safe to mark static heap feature as supported.

Usually we wait at least one release cycle before marking a feature as
supported. However, I can see that this case is a bit different because
effectively static heap memory is a safety/security feature.

Julien, Bertrand, I'll let you know decide on this one




> Signed-off-by: Henry Wang <Henry.Wang@arm.com>
> ---
>  SUPPORT.md | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index cf2ddfacaf..ddcf8a13a7 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -298,7 +298,7 @@ pre-defined by configuration using physical address ranges.
>  Allow reserving parts of RAM through the device tree using physical
>  address ranges as heap.
>  
> -    Status, ARM: Tech Preview
> +    Status, ARM: Supported
>  
>  ### Memory Sharing
>  
> -- 
> 2.17.1
>

Hi Stefano,

On 14/10/2022 00:55, Stefano Stabellini wrote:
> On Thu, 13 Oct 2022, Henry Wang wrote:
>> With the P2M pages pool bounding the domain memory runtime allocation
>> and the documented minimal size requirement of the static heap, it is
>> safe to mark static heap feature as supported.
> 
> Usually we wait at least one release cycle before marking a feature as
> supported. However, I can see that this case is a bit different because
> effectively static heap memory is a safety/security feature.

Even with patch #1 merged, we are still missing some information on how 
to size the heap. But see below...

> 
> Julien, Bertrand, I'll let you know decide on this one

It doesn't seem to make sense to security support the static heap when 
allocating statically memory for domains are still in tech preview.

That's because if you want to have your system security supported, then 
you will need all the allocations to come from the heap. At which point, 
restricting the heap seems pointless.

So I think it would be better to wait until the static memory is fully 
supported.

Cheers,

-- 
Julien Grall

Hi,

> On 14 Oct 2022, at 09:35, Julien Grall <julien@xen.org> wrote:
> 
> Hi Stefano,
> 
> On 14/10/2022 00:55, Stefano Stabellini wrote:
>> On Thu, 13 Oct 2022, Henry Wang wrote:
>>> With the P2M pages pool bounding the domain memory runtime allocation
>>> and the documented minimal size requirement of the static heap, it is
>>> safe to mark static heap feature as supported.
>> Usually we wait at least one release cycle before marking a feature as
>> supported. However, I can see that this case is a bit different because
>> effectively static heap memory is a safety/security feature.
> 
> Even with patch #1 merged, we are still missing some information on how to size the heap. But see below...
> 
>> Julien, Bertrand, I'll let you know decide on this one
> 
> It doesn't seem to make sense to security support the static heap when allocating statically memory for domains are still in tech preview.
> 
> That's because if you want to have your system security supported, then you will need all the allocations to come from the heap. At which point, restricting the heap seems pointless.
> 
> So I think it would be better to wait until the static memory is fully supported.
> 

I think this should stay a tech preview in 4.17.

Cheers
Bertrand

> Cheers,
> 
> -- 
> Julien Grall