[win-pv-devel] [PATCH] Don't BUG() just because we can't get a super-page

[Paul Durrant <paul.durrant@xxxxxxxxxx>]

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@xxxxxxxxxx>
---
 src/xenbus/fdo.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/xenbus/fdo.c b/src/xenbus/fdo.c
index 7047f6a..27837b2 100644
--- a/src/xenbus/fdo.c
+++ b/src/xenbus/fdo.c
@@ -3096,6 +3096,7 @@ FdoDestroyHole(
     PFN_NUMBER      Pfn;
     LONGLONG        Start;
     ULONG           Count;
+    ULONG           Index;
     NTSTATUS        status;
 
     Mdl = Fdo->Mdl;
@@ -3107,9 +3108,18 @@ FdoDestroyHole(
 
     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,
-- 
2.5.3


_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/win-pv-devel