summaryrefslogtreecommitdiffstats
path: root/hw/unicore32
diff options
context:
space:
mode:
authorMarkus Armbruster <armbru@redhat.com>2013-07-31 15:11:09 +0200
committerAnthony Liguori <anthony@codemonkey.ws>2013-09-12 11:45:31 -0500
commit2eb9fbaab56c6350c7d137428f4bd0bc79168214 (patch)
treea0a420f0f3823626a1e9197749861ec5aab77bb3 /hw/unicore32
parent91138037cb341a04a66e4c43b6cb31d5d8a43a73 (diff)
downloadhqemu-2eb9fbaab56c6350c7d137428f4bd0bc79168214.zip
hqemu-2eb9fbaab56c6350c7d137428f4bd0bc79168214.tar.gz
exec: Drop incorrect & dead S390 code in qemu_ram_remap()
Old S390 KVM wants guest RAM mapped in a peculiar way. Commit 6b02494 implemented that. When qemu_ram_remap() got added in commit cd19cfa, its code carefully mimicked the allocation code: peculiar way if defined(TARGET_S390X) && defined(CONFIG_KVM), else normal way. For new S390 KVM, we actually want the normal way. Commit fdec991 changed qemu_ram_alloc_from_ptr() accordingly, but forgot to update qemu_ram_remap(). If qemu_ram_alloc_from_ptr() maps RAM the normal way, but qemu_ram_remap() remaps it the peculiar way, remapping changes protection and flags, which it shouldn't. Fortunately, this can't happen, as we never remap on S390. Replace the incorrect code with an assertion. Thanks to Christian Borntraeger for help with assessing the bug's (non-)impact. Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Message-id: 1375276272-15988-6-git-send-email-armbru@redhat.com Signed-off-by: Anthony Liguori <anthony@codemonkey.ws>
Diffstat (limited to 'hw/unicore32')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud