On Mon, Feb 16, 2026 at 09:11:29AM +0100, Jan Beulich wrote: > On 13.02.2026 16:56, Roger Pau Monné wrote: > > On Fri, Feb 13, 2026 at 09:56:42AM +0100, Jan Beulich wrote: > >> On 13.02.2026 05:02, Marek Marczykowski-Górecki wrote: > >>> Hi, > >>> > >>> After fixing the xhci crash, I hit another issue - booting with 236MB > >>> initrd doesn't work, I get: > >>> > >>> (XEN) [ 3.151856] *** Building a PVH Dom0 *** > >>> ... > >>> (XEN) [ 3.593940] Unable to allocate memory with order 0! > >>> (XEN) [ 3.597110] Failed to setup Dom0 physical memory map > >>> (XEN) [ 3.599884] > >>> (XEN) [ 3.602482] **************************************** > >>> (XEN) [ 3.605272] Panic on CPU 0: > >>> (XEN) [ 3.607928] Could not construct d0 > >>> (XEN) [ 3.610692] **************************************** > >>> (XEN) [ 3.613463] > >>> (XEN) [ 3.616035] Reboot in five seconds... > >>> (XEN) [ 8.626565] Resetting with ACPI MEMORY or I/O RESET_REG. > >>> > >>> Full console log: > >>> https://gist.github.com/marmarek/c9dbc87bf07b76f2899781755762f565 > >>> > >>> If I skip initrd, then it boots just fine (but dom0 is not happy about > >>> that). 164MB initrd failed too, but 13MB started ok. > >>> Just in case, I tried skipping XHCI console, but it didn't change > >>> anything. > >>> > >>> Host has 16GB of memory, and there is no dom0_mem= parameter. Xen is > >>> started from GRUB, using MB2+EFI. > >> > >> Hmm, yes, there's an ordering issue: Of course we free initrd space (as > >> used > >> for passing from the boot loader to Xen) only after copying to the > >> designated > >> guest area. Yet dom0_compute_nr_pages(), intentionally, includes the space > >> in > >> its calculation (adding initial_images_nrpages()'s return value). PV Dom0 > >> isn't affected because to load huge initrd there, the kernel has to request > >> the initrd to not be mapped into the initial allocation. > > > > Right, on PV dom0 we do not copy the image to a new set of pages, we > > simply assign the pages where the initrd resides to the domain. We > > can't populate those pages in the p2m as-is, otherwise we would > > shatter super pages. > > > > I think the fix below should do it, it's likely the best we can do. > > That's at best a workaround imo. We definitely can do better, and the bigger > the initrd, the more important it may be that we actually do.
See the second patch I gave to Marek. That one is slightly better by accounting for the initial images space as part of the reserved space. > One option may > be to similarly use the pages directly (i.e. by assigning rather than > copying), accepting that we may not be able to use large page mappings then > for the respective GFN range. Hm, there's always going to be a trade-off. I think I would prefer having 1G pages in the p2m, rather than a bit more memory due to direct adding the initrd into the p2m. Thanks, Roger.
