[PATCH v2 11/14] x86/PVH: prefer smaller E820 regions for stealing from

[Jan Beulich <jbeulich@xxxxxxxx>]

Nibbling from the end of large regions tends to split full 2Mb (or even
full 1Gb) ranges, which Dom0 may otherwise be able to use superpage
mappings for (when, like Linux, it e.g. has a direct-map).

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
---
On one of my test systems this doesn't work as neatly anymore as it did
before. In v1, since the kernel range wasn't removed from the candidate
set, the (relatively large) E820 region covering it wasn't used for the
small ACPI ranges we need; instead a range of about 2.5Mb size next to
the host's ACPI data was the best candidate there. Now, with the kernel
starting at 2Mb, the 1Mb range [1Mb,2Mb) is the smallest candidate, which
is a little unusual a place to put ACPI data.
---
v2: Re-do from scratch, due to changes earlier in the series.

--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -184,8 +184,9 @@ static int __init pvh_populate_memory_ra
 }
 
 struct steal_info {
-    unsigned long size, align;
+    unsigned long size, align, region_size;
     paddr_t addr, end;
+    bool nosteal;
 };
 
 static int cf_check __init find_ram(
@@ -197,10 +198,12 @@ static int cf_check __init find_ram(
     {
         paddr_t addr = (e + 1 - info->size) & ~(info->align - 1);
 
-        if ( addr >= s )
+        if ( addr >= s &&
+             (info->nosteal || e - s <= info->region_size) )
         {
             info->addr = addr;
             info->end = e;
+            info->region_size = e - s;
         }
     }
 
@@ -219,7 +222,9 @@ static int __init pvh_steal_ram(struct r
     struct steal_info info = {
         .size = size,
         .align = align ?: 1,
+        .region_size = -1,
         .addr = INVALID_PADDR,
+        .nosteal = !end,
     };
 
     rangeset_report_ranges(ram, MB(1), limit - 1, find_ram, &info);