[PATCH 00/15] x86: PVH Dom0 loading rework

[Jan Beulich <jbeulich@xxxxxxxx>]

The primary goal is to accommodate large initrd-s without requiring people
to restrict Dom0's memory just for that. Other issues are being addressed
as well, though, and some cleanup is done, in part even outside of the main
target area of this series.

01: EFI: guard against oversized modules
02: PV: make better use of assign_pages()
03: setup: break out E820_RAM accumulation
04: setup: special treatment of initrd for PVH Dom0
05: PVH: split pvh_load_kernel()
06: PVH: keep a copy of Dom0's initial E820 map
07: PVH: lift E820 alignment requirement
08: PVH: split pvh_setup_acpi()
09: PVH: split pvh_setup_acpi()
10: PVH: convert find_memory() to using a rangeset
11: PVH: try to map initrd directly into Dom0
12: PVH: heed the kernel in pvh_steal_ram()
13: PVH: prefer smaller E820 regions for stealing from
14: PVH: log Dom0's E820 map earlier
15: PVH: simplify writing of Dom0's RSDP

While repeatedly looking at the logs, the memory allocation stats logged
further suggested that we may be able to do better in populating the P2M.
I was hoping that by going backwards, we might be able to allow for one
more 1G mapping. Yet testing that (now omitted) change on two sufficiently
different systems resulted in "makes no difference". I conclude (without
having proven it) that perhaps earlier during boot we shatter an order-18
page, when perhaps we could avoid doing so.

Jan