218e99
From b65927de7dd0ac9a52fa9b855cd17860c5303e6c Mon Sep 17 00:00:00 2001
218e99
From: Markus Armbruster <armbru@redhat.com>
218e99
Date: Wed, 18 Sep 2013 09:31:06 +0200
218e99
Subject: [PATCH 22/29] exec: Drop incorrect & dead S390 code in qemu_ram_remap()
218e99
218e99
RH-Author: Markus Armbruster <armbru@redhat.com>
218e99
Message-id: <1379496669-22778-6-git-send-email-armbru@redhat.com>
218e99
Patchwork-id: 54426
218e99
O-Subject: [PATCH 7.0 qemu-kvm 5/8] exec: Drop incorrect & dead S390 code in qemu_ram_remap()
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
Old S390 KVM wants guest RAM mapped in a peculiar way.  Commit 6b02494
218e99
implemented that.
218e99
218e99
When qemu_ram_remap() got added in commit cd19cfa, its code carefully
218e99
mimicked the allocation code: peculiar way if defined(TARGET_S390X) &&
218e99
defined(CONFIG_KVM), else normal way.
218e99
218e99
For new S390 KVM, we actually want the normal way.  Commit fdec991
218e99
changed qemu_ram_alloc_from_ptr() accordingly, but forgot to update
218e99
qemu_ram_remap().  If qemu_ram_alloc_from_ptr() maps RAM the normal
218e99
way, but qemu_ram_remap() remaps it the peculiar way, remapping
218e99
changes protection and flags, which it shouldn't.
218e99
218e99
Fortunately, this can't happen, as we never remap on S390.
218e99
218e99
Replace the incorrect code with an assertion.
218e99
218e99
Thanks to Christian Borntraeger for help with assessing the bug's
218e99
(non-)impact.
218e99
218e99
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
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
Message-id: 1375276272-15988-6-git-send-email-armbru@redhat.com
218e99
Signed-off-by: Anthony Liguori <anthony@codemonkey.ws>
218e99
(cherry picked from commit 2eb9fbaab56c6350c7d137428f4bd0bc79168214)
218e99
---
218e99
 exec.c | 13 +++++++------
218e99
 1 file changed, 7 insertions(+), 6 deletions(-)
218e99
218e99
Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
218e99
---
218e99
 exec.c |   13 +++++++------
218e99
 1 files changed, 7 insertions(+), 6 deletions(-)
218e99
218e99
diff --git a/exec.c b/exec.c
218e99
index 42a0005..185155c 100644
218e99
--- a/exec.c
218e99
+++ b/exec.c
218e99
@@ -1201,15 +1201,16 @@ void qemu_ram_remap(ram_addr_t addr, ram_addr_t length)
218e99
                     area = mmap(vaddr, length, PROT_READ | PROT_WRITE,
218e99
                                 flags, block->fd, offset);
218e99
                 } else {
218e99
-#if defined(TARGET_S390X) && defined(CONFIG_KVM)
218e99
-                    flags |= MAP_SHARED | MAP_ANONYMOUS;
218e99
-                    area = mmap(vaddr, length, PROT_EXEC|PROT_READ|PROT_WRITE,
218e99
-                                flags, -1, 0);
218e99
-#else
218e99
+                    /*
218e99
+                     * Remap needs to match alloc.  Accelerators that
218e99
+                     * set phys_mem_alloc never remap.  If they did,
218e99
+                     * we'd need a remap hook here.
218e99
+                     */
218e99
+                    assert(phys_mem_alloc == qemu_anon_ram_alloc);
218e99
+
218e99
                     flags |= MAP_PRIVATE | MAP_ANONYMOUS;
218e99
                     area = mmap(vaddr, length, PROT_READ | PROT_WRITE,
218e99
                                 flags, -1, 0);
218e99
-#endif
218e99
                 }
218e99
                 if (area != vaddr) {
218e99
                     fprintf(stderr, "Could not remap addr: "
218e99
-- 
218e99
1.7.1
218e99