Re: E820 memory allocation issue on Threadripper platforms

[Branden Sherrell <sherrellbc@xxxxxxxxx>]

What is the reasoning that this fix be applied only to PVH domains? Taking a 
look at the fix logic it appears to walk the E820 to find a suitable range of 
memory to load the kernel into (assuming it can be determined that the kernel 
is also relocatable). Why can this logic not be applied to dom0 kernel load in 
general?

Branden.

> On Jun 24, 2024, at 8:54 AM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> 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