| Message ID | 5835df1e-8f92-79ce-94c5-1b5df9c9ff65@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] SUPPORT.md: extend security support for x86 hosts to 12 TiB of memory | expand |
> On May 25, 2022, at 10:21 AM, Jan Beulich <jbeulich@suse.com> 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. While subsequently further restricted for Arm, > extend this to 12 TiB on x86, putting in place a guest restriction to > 8 TiB (or yet less for Arm) in exchange. > > A 12 TiB x86 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> I haven’t been following the discussion, but the form &c LGTM: Acked-by: George Dunlap <george.dunlap@citrix.com>
Hi Jan, On 25/05/2022 10:21, 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. While subsequently further restricted for Arm, > extend this to 12 TiB on x86, putting in place a guest restriction to > 8 TiB (or yet less for Arm) in exchange. > > A 12 TiB x86 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> > --- > v2: Rebase over new host limits for Arm. Refine new guest values for > Arm. > > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -50,7 +50,7 @@ For the Cortex A57 r0p0 - r1p1, see Erra > > ### Physical Memory > > - Status, x86: Supported up to 8 TiB. Hosts with more memory are supported, but not security supported. > + Status, x86: Supported up to 12 TiB. Hosts with more memory are supported, but not security supported. > Status, Arm32: Supported up to 12 GiB > Status, Arm64: Supported up to 2 TiB > > @@ -121,6 +121,17 @@ ARM only has one guest type at the momen > > Status: Supported > > +## Guest Limits > + > +### Memory > + > + Status, x86: Supported up to 8 TiB > + Status, Arm64: Supported up to 1 TiB > + Status, Arm32: Supported up to 32 GiB IIRC, the max the architecture would allow us is 16 Gib. Here we are limited with how much physical memory is supported by Xen. So this wants to be 12 GiB. > + > +Guests with more memory, but less than 16 TiB, are supported, > +but not security supported. On Arm32, we definitely can't support up to 16 TiB. On Arm64, we would need some work to support it. So I would move this sentence in the "Status, x86" section. Cheers,
On 25.05.2022 12:58, Julien Grall wrote: > On 25/05/2022 10:21, Jan Beulich wrote: >> --- a/SUPPORT.md >> +++ b/SUPPORT.md >> @@ -50,7 +50,7 @@ For the Cortex A57 r0p0 - r1p1, see Erra >> >> ### Physical Memory >> >> - Status, x86: Supported up to 8 TiB. Hosts with more memory are supported, but not security supported. >> + Status, x86: Supported up to 12 TiB. Hosts with more memory are supported, but not security supported. >> Status, Arm32: Supported up to 12 GiB >> Status, Arm64: Supported up to 2 TiB >> >> @@ -121,6 +121,17 @@ ARM only has one guest type at the momen >> >> Status: Supported >> >> +## Guest Limits >> + >> +### Memory >> + >> + Status, x86: Supported up to 8 TiB >> + Status, Arm64: Supported up to 1 TiB >> + Status, Arm32: Supported up to 32 GiB > > IIRC, the max the architecture would allow us is 16 Gib. Here we are > limited with how much physical memory is supported by Xen. So this wants > to be 12 GiB. Hmm, while I don't know where I took the 32 from, it was you who suggested (in reply to v1) I put 16 here. Though yes, with the host limit now set to just 12, putting more here would be odd. I didn't cross check the numbers, I'll admit. >> + >> +Guests with more memory, but less than 16 TiB, are supported, >> +but not security supported. > > On Arm32, we definitely can't support up to 16 TiB. On Arm64, we would > need some work to support it. So I would move this sentence in the > "Status, x86" section. Sure, I can do that. Would have been nice if you had said so right on v1. As to Arm64 though - the host limit is 2 TiB. Going beyond that being impossible (without becoming at least unsupported), is the uniform upper bound of 16 TiB really a problem here (IOW do guests really only function up to 1 TiB)? For Arm32 it would be even less of an issue, as hosts with more than 12 GiB are unsupported. (I'm trying to avoid moving the line up not the least because it'll be even more of a line length violation than what was necessary to accept for the host limits.) Jan
Hi Jan, On 25/05/2022 12:11, Jan Beulich wrote: > On 25.05.2022 12:58, Julien Grall wrote: >> On 25/05/2022 10:21, Jan Beulich wrote: >>> --- a/SUPPORT.md >>> +++ b/SUPPORT.md >>> @@ -50,7 +50,7 @@ For the Cortex A57 r0p0 - r1p1, see Erra >>> >>> ### Physical Memory >>> >>> - Status, x86: Supported up to 8 TiB. Hosts with more memory are supported, but not security supported. >>> + Status, x86: Supported up to 12 TiB. Hosts with more memory are supported, but not security supported. >>> Status, Arm32: Supported up to 12 GiB >>> Status, Arm64: Supported up to 2 TiB >>> >>> @@ -121,6 +121,17 @@ ARM only has one guest type at the momen >>> >>> Status: Supported >>> >>> +## Guest Limits >>> + >>> +### Memory >>> + >>> + Status, x86: Supported up to 8 TiB >>> + Status, Arm64: Supported up to 1 TiB >>> + Status, Arm32: Supported up to 32 GiB >> >> IIRC, the max the architecture would allow us is 16 Gib. Here we are >> limited with how much physical memory is supported by Xen. So this wants >> to be 12 GiB. > > Hmm, while I don't know where I took the 32 from, it was you who > suggested (in reply to v1) I put 16 here. Hmmm... I am pretty sure I wrote 16 in v1 [1]. > Though yes, with the > host limit now set to just 12, putting more here would be odd. > I didn't cross check the numbers, I'll admit. > >>> + >>> +Guests with more memory, but less than 16 TiB, are supported, >>> +but not security supported. >> >> On Arm32, we definitely can't support up to 16 TiB. On Arm64, we would >> need some work to support it. So I would move this sentence in the >> "Status, x86" section. > > Sure, I can do that. Would have been nice if you had said so right > on v1. I only spotted this oddity now. Sorry. > As to Arm64 though - the host limit is 2 TiB. Going beyond > that being impossible (without becoming at least unsupported), is > the uniform upper bound of 16 TiB really a problem here (IOW do > guests really only function up to 1 TiB)? The guest memory layout has only been defined for up to 1TB. Hopefully this is the only place where the assumption is baked. But as I don't have such machine in hand, I can't easily confirm it. So I think we need to clarify that the 16TB limit only applies to x86. > For Arm32 it would be > even less of an issue, as hosts with more than 12 GiB are > unsupported. This is only obvious if you know that Xen doesn't support memory overcommitting. Admittely, this could be considered as basic Xen knowledge. Cheers, [1] https://lore.kernel.org/xen-devel/6ec0e3d9-374c-1caa-9889-f091dcf894e3@xen.org/
--- a/SUPPORT.md +++ b/SUPPORT.md @@ -50,7 +50,7 @@ For the Cortex A57 r0p0 - r1p1, see Erra ### Physical Memory - Status, x86: Supported up to 8 TiB. Hosts with more memory are supported, but not security supported. + Status, x86: Supported up to 12 TiB. Hosts with more memory are supported, but not security supported. Status, Arm32: Supported up to 12 GiB Status, Arm64: Supported up to 2 TiB @@ -121,6 +121,17 @@ ARM only has one guest type at the momen Status: Supported +## Guest Limits + +### Memory + + Status, x86: Supported up to 8 TiB + Status, Arm64: Supported up to 1 TiB + Status, Arm32: Supported up to 32 GiB + +Guests with more memory, but less than 16 TiB, are supported, +but not security supported. + ## Hypervisor file system ### Build info
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. While subsequently further restricted for Arm, extend this to 12 TiB on x86, putting in place a guest restriction to 8 TiB (or yet less for Arm) in exchange. A 12 TiB x86 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> --- v2: Rebase over new host limits for Arm. Refine new guest values for Arm.