218e99
From e4927c8d2802be4adeb25fbdfd538d15211d925e Mon Sep 17 00:00:00 2001
218e99
From: Markus Armbruster <armbru@redhat.com>
218e99
Date: Wed, 18 Sep 2013 09:31:07 +0200
218e99
Subject: [PATCH 23/29] exec: Clean up unnecessary S390 ifdeffery
218e99
218e99
RH-Author: Markus Armbruster <armbru@redhat.com>
218e99
Message-id: <1379496669-22778-7-git-send-email-armbru@redhat.com>
218e99
Patchwork-id: 54428
218e99
O-Subject: [PATCH 7.0 qemu-kvm 6/8] exec: Clean up unnecessary S390 ifdeffery
218e99
Bugzilla: 1009328
218e99
RH-Acked-by: Paolo Bonzini <pbonzini@redhat.com>
218e99
RH-Acked-by: Laszlo Ersek <lersek@redhat.com>
218e99
RH-Acked-by: Miroslav Rezanina <mrezanin@redhat.com>
218e99
218e99
From: Markus Armbruster <armbru@redhat.com>
218e99
218e99
Another issue missed in commit fdec991 is -mem-path: it needs to be
218e99
rejected only for old S390 KVM, not for any S390.  Not that I
218e99
personally care, but the ifdeffery in qemu_ram_alloc_from_ptr() annoys
218e99
me.
218e99
218e99
Note that this doesn't actually make -mem-path work, as the kernel
218e99
doesn't (yet?)  support large pages in the host for KVM guests.  Clean
218e99
it up anyway.
218e99
218e99
Thanks to Christian Borntraeger for pointing out the S390 kernel
218e99
limitations.
218e99
218e99
Signed-off-by: Markus Armbruster <armbru@redhat.com>
218e99
Acked-by: Laszlo Ersek <lersek@redhat.com>
218e99
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
218e99
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
218e99
Message-id: 1375276272-15988-7-git-send-email-armbru@redhat.com
218e99
Signed-off-by: Anthony Liguori <anthony@codemonkey.ws>
218e99
(cherry picked from commit e1e84ba050538bae24393e40b737078ecad99747)
218e99
---
218e99
 exec.c | 25 +++++++++++++++++++------
218e99
 1 file changed, 19 insertions(+), 6 deletions(-)
218e99
218e99
Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
218e99
---
218e99
 exec.c |   25 +++++++++++++++++++------
218e99
 1 files changed, 19 insertions(+), 6 deletions(-)
218e99
218e99
diff --git a/exec.c b/exec.c
218e99
index 185155c..a75c200 100644
218e99
--- a/exec.c
218e99
+++ b/exec.c
218e99
@@ -839,7 +839,7 @@ void qemu_mutex_unlock_ramlist(void)
218e99
     qemu_mutex_unlock(&ram_list.mutex);
218e99
 }
218e99
 
218e99
-#if defined(__linux__) && !defined(TARGET_S390X)
218e99
+#ifdef __linux__
218e99
 
218e99
 #include <sys/vfs.h>
218e99
 
218e99
@@ -942,6 +942,14 @@ static void *file_ram_alloc(RAMBlock *block,
218e99
     block->fd = fd;
218e99
     return area;
218e99
 }
218e99
+#else
218e99
+static void *file_ram_alloc(RAMBlock *block,
218e99
+                            ram_addr_t memory,
218e99
+                            const char *path)
218e99
+{
218e99
+    fprintf(stderr, "-mem-path not supported on this host\n");
218e99
+    exit(1);
218e99
+}
218e99
 #endif
218e99
 
218e99
 static ram_addr_t find_ram_offset(ram_addr_t size)
218e99
@@ -1075,12 +1083,17 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
218e99
         xen_ram_alloc(new_block->offset, size, mr);
218e99
     } else {
218e99
         if (mem_path) {
218e99
-#if defined (__linux__) && !defined(TARGET_S390X)
218e99
+            if (phys_mem_alloc != qemu_anon_ram_alloc) {
218e99
+                /*
218e99
+                 * file_ram_alloc() needs to allocate just like
218e99
+                 * phys_mem_alloc, but we haven't bothered to provide
218e99
+                 * a hook there.
218e99
+                 */
218e99
+                fprintf(stderr,
218e99
+                        "-mem-path not supported with this accelerator\n");
218e99
+                exit(1);
218e99
+            }
218e99
             new_block->host = file_ram_alloc(new_block, size, mem_path);
218e99
-#else
218e99
-            fprintf(stderr, "-mem-path option unsupported\n");
218e99
-            exit(1);
218e99
-#endif
218e99
         }
218e99
         if (!new_block->host) {
218e99
             new_block->host = phys_mem_alloc(size);
218e99
-- 
218e99
1.7.1
218e99