[Xen-devel] [PATCH 30 of 32 RFC] libxl: drop 8M slack for PV guests

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

# HG changeset patch
# User Ian Campbell <ian.campbell@xxxxxxxxxx>
# Date 1326713350 0
# Node ID 7ffc8e870fbb5a9edcd6f8d46f2b0296d38cb5ed
# Parent  feeea78c60ef4a0ec5d4d827bb15cc004ece9774
libxl: drop 8M slack for PV guests.

As far as I can tell this serves no purpose. I think it relates to the old
8M to "account for backend allocations" which we used to add. This leaves a bit
of unpopulated space in the Pseudo-physical address space which can be used by
backends when mapping foreign memory. However 8M is not representative of that
any more and modern kernels do not operate in this way anyway.

I suspect an argument could be made for removing this from the libxl API
altogether but instead lets jsut set the overhead to 0.

Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

diff -r feeea78c60ef -r 7ffc8e870fbb tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c        Mon Jan 16 11:25:49 2012 +0000
+++ b/tools/libxl/libxl_create.c        Mon Jan 16 11:29:10 2012 +0000
@@ -89,18 +89,6 @@ int libxl_init_build_info(libxl_ctx *ctx
     b_info->device_model_stubdomain = false;
     b_info->device_model = NULL;
 
-    switch (b_info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = 8 * 1024;
-        break;
-    default:
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                   "invalid domain type %s in create info",
-                   libxl_domain_type_to_string(b_info->type));
-        return ERROR_INVAL;
-    }
     return 0;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel