aboutsummaryrefslogtreecommitdiff
path: root/target/s390x/cpu.h
diff options
context:
space:
mode:
authorDavid Hildenbrand <david@redhat.com>2018-02-19 18:42:31 +0100
committerCornelia Huck <cohuck@redhat.com>2018-02-26 12:55:26 +0100
commit82fab5c5b90e468f3e9d54cd614c89d9416d18cd (patch)
tree7231b258e466c28249b26cd54ed4b911358b1ec7 /target/s390x/cpu.h
parenta5a2b80d9538f5ca7b91ac201f1466ef58cf833f (diff)
s390x/sclp: remove memory hotplug support
From an architecture point of view, nothing can be mapped into the address space on s390x. All there is is memory. Therefore there is also not really an interface to communicate such information to the guest. All we can do is specify the maximum ram address and guests can probe in that range if memory is available and usable (TPROT). Also memory hotplug is strange. The guest can decide at some point in time to add / remove memory in some range. While the hypervisor can deny to online an increment, all increments have to be predefined and there is no way of telling the guest about a newly "hotplugged" increment. So if we specify right now e.g. -m 2G,slots=2,maxmem=20G An ordinary fedora guest will happily online (hotplug) all memory, resulting in a guest consuming 20G. So it really behaves rather like -m 22G There is no way to hotplug memory from the outside like on other architectures. This is of course bad for upper management layers. As the guest can create/delete memory regions while it is running, of course migration support is not available and tricky to implement. With virtualization, it is different. We might want to map something into guest address space (e.g. fake DAX devices) and not detect it automatically as memory. So we really want to use the maxmem and slots parameter just like on all other architectures. Such devices will have to expose the applicable memory range themselves. To finally be able to provide memory hotplug to guests, we will need a new paravirtualized interface to do that (e.g. something into the direction of virtio-mem). This implies, that maxmem cannot be used for s390x memory hotplug anymore and has to go. This simplifies the code quite a bit. As migration support is not working, this change cannot really break migration as guests without slots and maxmem don't see the SCLP features. Also, the ram size calculation does not change. Signed-off-by: David Hildenbrand <david@redhat.com> Message-Id: <20180219174231.10874-1-david@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com> [CH: tweaked patch description, as discussed on list] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Diffstat (limited to 'target/s390x/cpu.h')
-rw-r--r--target/s390x/cpu.h1
1 files changed, 0 insertions, 1 deletions
diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
index 802324b3e2..5bd6de7e8e 100644
--- a/target/s390x/cpu.h
+++ b/target/s390x/cpu.h
@@ -622,7 +622,6 @@ QEMU_BUILD_BUG_ON(sizeof(SysIB) != 4096);
#define SIGP_ORDER_MASK 0x000000ff
/* from s390-virtio-ccw */
-#define MEM_SECTION_SIZE 0x10000000UL
#define MAX_AVAIL_SLOTS 32
/* machine check interruption code */