xen/balloon: Fix return value interpretation for XENMEM_get_pod_target

Unfortunately c/s 989 didn't consider what I would call a quirk in
pre-3.4 Xen, resulting in XENMEM_get_pod_target calls to not return
-ENOSYS as one would normally expect.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

diff --git a/drivers/xen/balloon/balloon.c b/drivers/xen/balloon/balloon.c
index c8bd48e19825fad77d0e0c5bba513d9bae606d90..b7532bdba49eab1af88628c831ce9296e69fe881 100644 (file)
--- a/drivers/xen/balloon/balloon.c
+++ b/drivers/xen/balloon/balloon.c
@@ -522,6 +522,7 @@ static int __init balloon_init(void)
        } xen_pod_target_t;
 # endif
        xen_pod_target_t pod_target = { .domid = DOMID_SELF };
+       int rc;
 #elif defined(CONFIG_X86)
        unsigned long pfn;
        struct page *page;
@@ -536,11 +537,17 @@ static int __init balloon_init(void)
        bs.current_pages = min(xen_start_info->nr_pages, max_pfn);
        totalram_pages   = bs.current_pages;
 #else 
-       totalram_bias = HYPERVISOR_memory_op(
-               HYPERVISOR_memory_op(XENMEM_get_pod_target,
-                       &pod_target) != -ENOSYS
-               ? XENMEM_maximum_reservation
-               : XENMEM_current_reservation,
+       rc = HYPERVISOR_memory_op(XENMEM_get_pod_target, &pod_target);
+       /*
+        * Xen prior to 3.4.0 masks the memory_op command to 4 bits, thus
+        * converting XENMEM_get_pod_target to XENMEM_decrease_reservation.
+        * Fortunately this results in a request with all input fields zero,
+        * but (due to the way bit 4 and upwards get interpreted) a starting
+        * extent of 1. When start_extent > nr_extents (>= in newer Xen), we
+        * simply get start_extent returned.
+        */
+       totalram_bias = HYPERVISOR_memory_op(rc != -ENOSYS && rc != 1
+               ? XENMEM_maximum_reservation : XENMEM_current_reservation,
                &pod_target.domid);
        if ((long)totalram_bias != -ENOSYS) {
                BUG_ON(totalram_bias < totalram_pages);