[Xen-devel] [PATCH] Revert "xen-hvm: increase maxmem before calling xc_domain_populate_physmap"

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

This reverts commit c1d322e6048796296555dd36fdd102d7fa2f50bf.

The original commit fixes a bug when assigning a large number of
devices which require option roms to a guest.  (One known
configuration that needs extra memory is having more than 4 emulated
NICs assigned.  Three or fewer NICs seems to work without this
functionality.)

However, by unilaterally increasing maxmem, it introduces two
problems.

First, now libxl's calculation of the required maxmem during migration
is broken -- any guest which exercised this functionality will fail on
migration.  (Guests which have the default number of devices are not
affected.)

Secondly, it makes it impossible for a higher-level toolstack or
administer to predict how much memory a VM will actually use, making
it much more difficult to effectively use all of the memory on a
machine.

The right solution to the original problem is to figure out a way for
qemu to take pages from the existing pool of guest memory, rather than
allocating more pages.

That fix will take more time to develop than we have until the feature
freeze.  In the mean time, the simplest way to fix the migration issue
is to revert this change.  That will re-introduce the original bug,
but it's an unusual corner case; and without migration it isn't fully
functional yet anyway.

Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
---
I do think this is the right approach, but I'm mainly sending this is
mainly to open up discussion.

CC: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
CC: Wei Liu <wei.liu2@xxxxxxxxxx>
CC: Ian Campbell <ian.campbell@xxxxxxxxxx>
CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
---
 xen-hvm.c | 24 ------------------------
 1 file changed, 24 deletions(-)

diff --git a/xen-hvm.c b/xen-hvm.c
index 42356b8..0408462 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -87,12 +87,6 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t 
*shared_page, int vcpu)
 #endif
 
 #define BUFFER_IO_MAX_DELAY  100
-/* Leave some slack so that hvmloader does not complain about lack of
- * memory at boot time ("Could not allocate order=0 extent").
- * Once hvmloader is modified to cope with that situation without
- * printing warning messages, QEMU_SPARE_PAGES can be removed.
- */
-#define QEMU_SPARE_PAGES 16
 
 typedef struct XenPhysmap {
     hwaddr start_addr;
@@ -250,8 +244,6 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, 
MemoryRegion *mr)
     unsigned long nr_pfn;
     xen_pfn_t *pfn_list;
     int i;
-    xc_domaininfo_t info;
-    unsigned long free_pages;
 
     if (runstate_check(RUN_STATE_INMIGRATE)) {
         /* RAM already populated in Xen */
@@ -274,22 +266,6 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, 
MemoryRegion *mr)
         pfn_list[i] = (ram_addr >> TARGET_PAGE_BITS) + i;
     }
 
-    if ((xc_domain_getinfolist(xen_xc, xen_domid, 1, &info) != 1) ||
-        (info.domain != xen_domid)) {
-        hw_error("xc_domain_getinfolist failed");
-    }
-    free_pages = info.max_pages - info.tot_pages;
-    if (free_pages > QEMU_SPARE_PAGES) {
-        free_pages -= QEMU_SPARE_PAGES;
-    } else {
-        free_pages = 0;
-    }
-    if ((free_pages < nr_pfn) &&
-        (xc_domain_setmaxmem(xen_xc, xen_domid,
-                             ((info.max_pages + nr_pfn - free_pages)
-                              << (XC_PAGE_SHIFT - 10))) < 0)) {
-        hw_error("xc_domain_setmaxmem failed");
-    }
     if (xc_domain_populate_physmap_exact(xen_xc, xen_domid, nr_pfn, 0, 0, 
pfn_list)) {
         hw_error("xen: failed to populate ram at " RAM_ADDR_FMT, ram_addr);
     }
-- 
1.9.1


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel