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
