When XENBUS is unloaded, it is necessary to re-populate the memory hole
that was created to host the shared info page, grant table shared frames,
etc. The hole is created by doing an order 9 XENMEM_decrease_reservation,
but this does not necessarily mean that Xen can re-populate it with an
order 9 allocation (i.e. a 2M super-page). Currently, such a failure will
cause an immediate BUG(), whereas what the code should do is to re-try
using order 0 (i.e. normal 4k page) allocations, and only BUG() if that
doesn't work.
This patch fixes the issue.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
PFN_NUMBER Pfn;
LONGLONG Start;
ULONG Count;
+ ULONG Index;
NTSTATUS status;
Mdl = Fdo->Mdl;
Trace("%08x - %08x\n", Start, Start + Count - 1);
- if (MemoryPopulatePhysmap(PAGE_ORDER_2M, 1, &Pfn) != 1)
- BUG("FAILED TO RE-POPULATE HOLE");
+ ASSERT3U(Count & ((1u << PAGE_ORDER_2M) - 1), ==, 0);
+ if (MemoryPopulatePhysmap(PAGE_ORDER_2M, 1, &Pfn) == 1)
+ goto done;
+
+ for (Index = 0; Index < Count; Index++) {
+ if (MemoryPopulatePhysmap(PAGE_ORDER_4K, 1, &Pfn) != 1)
+ BUG("FAILED TO RE-POPULATE HOLE");
+ Pfn++;
+ }
+
+done:
status = XENBUS_RANGE_SET(Get,
&Fdo->RangeSetInterface,
Fdo->RangeSet,