SUPPORT.md: extend security support for hosts to 12 TiB of memory

[PATCH] SUPPORT.md: extend security support for hosts to 12 TiB of memory

Posted by Jan Beulich 2 years, 1 month ago

c49ee0329ff3 ("SUPPORT.md: limit security support for hosts with very
much memory"), as a result of XSA-385, restricted security support to
8 TiB of host memory. Extend this to 12 TiB, putting in place a guest
restriction to 8 TiB in exchange.

A 12 TiB host was certified successfully for use with Xen 4.14 as per
https://www.suse.com/nbswebapp/yesBulletin.jsp?bulletinNumber=150753.
This in particular included running as many guests (2 TiB each) as
possible in parallel, to actually prove that all the memory can be used
like this. It may be relevant to note that the Optane memory there was
used in memory-only mode, with DRAM acting as cache.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -50,7 +50,7 @@ For the Cortex A57 r0p0 - r1p1, see Erra
 
 ### Physical Memory
 
-    Status: Supported up to 8 TiB
+    Status: Supported up to 12 TiB
 
 Hosts with more memory are supported, but not security supported.
 
@@ -121,6 +121,14 @@ ARM only has one guest type at the momen
 
     Status: Supported
 
+## Guest Limits
+
+### Memory
+
+    Status: Supported up to 8 TiB
+
+Guests with more memory are supported, but not security supported.
+
 ## Hypervisor file system
 
 ### Build info

Re: [PATCH] SUPPORT.md: extend security support for hosts to 12 TiB of memory

Posted by Julien Grall 2 years, 1 month ago

Hi,

On 06/04/2022 15:44, Jan Beulich wrote:
> c49ee0329ff3 ("SUPPORT.md: limit security support for hosts with very
> much memory"), as a result of XSA-385, restricted security support to
> 8 TiB of host memory. Extend this to 12 TiB, putting in place a guest
> restriction to 8 TiB in exchange.

And this is even without CONFIG_BIGMEM?

> 
> A 12 TiB host was certified successfully for use with Xen 4.14 as per
> https://www.suse.com/nbswebapp/yesBulletin.jsp?bulletinNumber=150753.
> This in particular included running as many guests (2 TiB each) as
> possible in parallel, to actually prove that all the memory can be used
> like this. It may be relevant to note that the Optane memory there was
> used in memory-only mode, with DRAM acting as cache.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -50,7 +50,7 @@ For the Cortex A57 r0p0 - r1p1, see Erra
>   
>   ### Physical Memory
>   
> -    Status: Supported up to 8 TiB
> +    Status: Supported up to 12 TiB

I am afraid this limit is going to be too high for Arm. Even the 
previous one was technically incorrect. From [1], it should be:
   - 5TB for arm64
   - 16GB for arm32

>   
>   Hosts with more memory are supported, but not security supported.
>   
> @@ -121,6 +121,14 @@ ARM only has one guest type at the momen
>   
>       Status: Supported
>   
> +## Guest Limits
> +
> +### Memory
> +
> +    Status: Supported up to 8 TiB

For Arm, this should be limited to 1TB for arm64 and 16GB for arm32.

> +
> +Guests with more memory are supported, but not security supported.

d->max_pages is a 32-bit value. So Xen can effectively only support up 
to 16TB of memory. AFAICT, it would require quite a bit rework to lift 
that limit. So I think it would be better to spell out the upper limit.

Cheers,

[1] https://wiki.xenproject.org/wiki/Xen_Project_Release_Features

-- 
Julien Grall

Re: [PATCH] SUPPORT.md: extend security support for hosts to 12 TiB of memory

Posted by Jan Beulich 2 years, 1 month ago

On 06.04.2022 17:15, Julien Grall wrote:
> On 06/04/2022 15:44, Jan Beulich wrote:
>> c49ee0329ff3 ("SUPPORT.md: limit security support for hosts with very
>> much memory"), as a result of XSA-385, restricted security support to
>> 8 TiB of host memory. Extend this to 12 TiB, putting in place a guest
>> restriction to 8 TiB in exchange.
> 
> And this is even without CONFIG_BIGMEM?

Yes. BIGMEM only matters when memory extends past the 16 TiB boundary
(i.e. when frame numbers with ore than 32 significant bits appear).

>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -50,7 +50,7 @@ For the Cortex A57 r0p0 - r1p1, see Erra
>>   
>>   ### Physical Memory
>>   
>> -    Status: Supported up to 8 TiB
>> +    Status: Supported up to 12 TiB
> 
> I am afraid this limit is going to be too high for Arm. Even the 
> previous one was technically incorrect. From [1], it should be:
>    - 5TB for arm64
>    - 16GB for arm32

May I ask that you submit a patch correcting this, and I'll rebase
on top of that? I can't really fit such an adjustment under the
umbrella of the title and purpose of this change.

>> @@ -121,6 +121,14 @@ ARM only has one guest type at the momen
>>   
>>       Status: Supported
>>   
>> +## Guest Limits
>> +
>> +### Memory
>> +
>> +    Status: Supported up to 8 TiB
> 
> For Arm, this should be limited to 1TB for arm64 and 16GB for arm32.

Sure, will do.

>> +
>> +Guests with more memory are supported, but not security supported.
> 
> d->max_pages is a 32-bit value. So Xen can effectively only support up 
> to 16TB of memory. AFAICT, it would require quite a bit rework to lift 
> that limit. So I think it would be better to spell out the upper limit.

Same here.

Jan

Re: [PATCH] SUPPORT.md: extend security support for hosts to 12 TiB of memory

Posted by Julien Grall 2 years, 1 month ago

Hi Jan,

On 06/04/2022 16:22, Jan Beulich wrote:
> On 06.04.2022 17:15, Julien Grall wrote:
>> On 06/04/2022 15:44, Jan Beulich wrote:
>>> c49ee0329ff3 ("SUPPORT.md: limit security support for hosts with very
>>> much memory"), as a result of XSA-385, restricted security support to
>>> 8 TiB of host memory. Extend this to 12 TiB, putting in place a guest
>>> restriction to 8 TiB in exchange.
>>
>> And this is even without CONFIG_BIGMEM?
> 
> Yes. BIGMEM only matters when memory extends past the 16 TiB boundary
> (i.e. when frame numbers with ore than 32 significant bits appear).

Thanks for the confirmation!

> 
>>> --- a/SUPPORT.md
>>> +++ b/SUPPORT.md
>>> @@ -50,7 +50,7 @@ For the Cortex A57 r0p0 - r1p1, see Erra
>>>    
>>>    ### Physical Memory
>>>    
>>> -    Status: Supported up to 8 TiB
>>> +    Status: Supported up to 12 TiB
>>
>> I am afraid this limit is going to be too high for Arm. Even the
>> previous one was technically incorrect. From [1], it should be:
>>     - 5TB for arm64
>>     - 16GB for arm32
> 
> May I ask that you submit a patch correcting this, and I'll rebase
> on top of that? I can't really fit such an adjustment under the
> umbrella of the title and purpose of this change.

Sure. I will submit one soon.

Cheers,

-- 
Julien Grall

Re: [PATCH] SUPPORT.md: extend security support for hosts to 12 TiB of memory

Posted by Julien Grall 2 years ago

Hi,

On 06/04/2022 16:23, Julien Grall wrote:
> On 06/04/2022 16:22, Jan Beulich wrote:
>> On 06.04.2022 17:15, Julien Grall wrote:
>>> On 06/04/2022 15:44, Jan Beulich wrote:
>>>> c49ee0329ff3 ("SUPPORT.md: limit security support for hosts with very
>>>> much memory"), as a result of XSA-385, restricted security support to
>>>> 8 TiB of host memory. Extend this to 12 TiB, putting in place a guest
>>>> restriction to 8 TiB in exchange.
>>>
>>> And this is even without CONFIG_BIGMEM?
>>
>> Yes. BIGMEM only matters when memory extends past the 16 TiB boundary
>> (i.e. when frame numbers with ore than 32 significant bits appear).
> 
> Thanks for the confirmation!
> 
>>
>>>> --- a/SUPPORT.md
>>>> +++ b/SUPPORT.md
>>>> @@ -50,7 +50,7 @@ For the Cortex A57 r0p0 - r1p1, see Erra
>>>>    ### Physical Memory
>>>> -    Status: Supported up to 8 TiB
>>>> +    Status: Supported up to 12 TiB
>>>
>>> I am afraid this limit is going to be too high for Arm. Even the
>>> previous one was technically incorrect. From [1], it should be:
>>>     - 5TB for arm64
>>>     - 16GB for arm32
>>
>> May I ask that you submit a patch correcting this, and I'll rebase
>> on top of that? I can't really fit such an adjustment under the
>> umbrella of the title and purpose of this change.
> 
> Sure. I will submit one soon.

I have submitted a patch: 
https://lore.kernel.org/xen-devel/20220427132246.52715-1-julien@xen.org/T/#u

Cheers,

-- 
Julien Grall