Re: E820 memory allocation issue on Threadripper platforms

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.06.2024 14:40, Branden Sherrell wrote:
> I recently found this mailing list thread when searching for information on a 
> related issue regarding conflicting E820 on a Threadripper platform. For 
> those interested in additional data points, I am using the ASUS WRX80E-SAGE 
> SE Wifi II motherboard that presents the following E820 to Xen:
> 
> (XEN) EFI RAM map:
> (XEN)  [0000000000000000, 0000000000000fff] (reserved)
> (XEN)  [0000000000001000, 000000000008ffff] (usable)
> (XEN)  [0000000000090000, 0000000000090fff] (reserved)
> (XEN)  [0000000000091000, 000000000009ffff] (usable)
> (XEN)  [00000000000a0000, 00000000000fffff] (reserved)
> (XEN)  [0000000000100000, 0000000003ffffff] (usable)
> (XEN)  [0000000004000000, 0000000004020fff] (ACPI NVS)
> (XEN)  [0000000004021000, 0000000009df1fff] (usable)
> (XEN)  [0000000009df2000, 0000000009ffffff] (reserved)
> (XEN)  [000000000a000000, 00000000b5b04fff] (usable)
> (XEN)  [00000000b5b05000, 00000000b8cd3fff] (reserved)
> (XEN)  [00000000b8cd4000, 00000000b9064fff] (ACPI data)
> (XEN)  [00000000b9065000, 00000000b942afff] (ACPI NVS)
> (XEN)  [00000000b942b000, 00000000bb1fefff] (reserved)
> (XEN)  [00000000bb1ff000, 00000000bbffffff] (usable)
> (XEN)  [00000000bc000000, 00000000bfffffff] (reserved)
> (XEN)  [00000000c1100000, 00000000c1100fff] (reserved)
> (XEN)  [00000000e0000000, 00000000efffffff] (reserved)
> (XEN)  [00000000f1280000, 00000000f1280fff] (reserved)
> (XEN)  [00000000f2200000, 00000000f22fffff] (reserved)
> (XEN)  [00000000f2380000, 00000000f2380fff] (reserved)
> (XEN)  [00000000f2400000, 00000000f24fffff] (reserved)
> (XEN)  [00000000f3680000, 00000000f3680fff] (reserved)
> (XEN)  [00000000fea00000, 00000000feafffff] (reserved)
> (XEN)  [00000000fec00000, 00000000fec00fff] (reserved)
> (XEN)  [00000000fec10000, 00000000fec10fff] (reserved)
> (XEN)  [00000000fed00000, 00000000fed00fff] (reserved)
> (XEN)  [00000000fed40000, 00000000fed44fff] (reserved)
> (XEN)  [00000000fed80000, 00000000fed8ffff] (reserved)
> (XEN)  [00000000fedc2000, 00000000fedcffff] (reserved)
> (XEN)  [00000000fedd4000, 00000000fedd5fff] (reserved)
> (XEN)  [00000000ff000000, 00000000ffffffff] (reserved)
> (XEN)  [0000000100000000, 000000703f0fffff] (usable)
> (XEN)  [000000703f100000, 000000703fffffff] (reserved)
> 
> And of course the default physical link address of the x86_64 kernel is 16MiB 
> which clearly conflicts with the EfiACPIMemoryNVS memory starting at 
> 0x4000000. On latest Debian (12.5.0, bookworm) the decompressed kernel is 
> more than 60MiB, so it obviously overflows into the adjacent region. I can 
> also confirm that loading the Debian kernel at 2MiB also works as expected. 
> Debian is also built with CONFIG_RELOCATABLE=y, so it should be capable of 
> being loaded with this new feature in Xen. 
> 
> I see the link at this ticket was implemented and committed (dfc9fab0) on 
> April 8, 2024 but it appears to not have made its way into the latest (4.18) 
> Xen release. Though there seem to be more recent commits cherry picked into 
> that branch. When is this fix expected to make it into a release?

It's not tagged as a bugfix, and PVH Dom0 also isn't "supported" in 4.18.
Hence it wasn't picked into the set of backports. I also doubt it'll help
you, as I would guess you're still using PV Dom0.

Jan