From: Cornelia Huck <cohuck@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: qemu-s390x@nongnu.org, qemu-devel@nongnu.org,
Richard Henderson <rth@twiddle.net>,
Alexander Graf <agraf@suse.de>,
Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: [Qemu-devel] [PATCH RFC] s390x/sclp: remove memory hotplug support
Date: Mon, 19 Feb 2018 18:08:31 +0100 [thread overview]
Message-ID: <20180219180831.2f36ec1e.cohuck@redhat.com> (raw)
In-Reply-To: <20180219143341.4290-1-david@redhat.com>
On Mon, 19 Feb 2018 15:33:41 +0100
David Hildenbrand <david@redhat.com> wrote:
> 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. And nobody can really hinder it
> from doing so. 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.
Agreed. Memory hotplug as architected on s390x is at odds with every
other implementation, and the code is horribly complex (I remember
getting headaches when I first looked at it...) Given that, it is
unlikely to be useful as it stands now, and it's probably a good idea
to put it on the pile of s390x features we don't implement.
>
> As migration support is not working, this change cannot really break
> migration. As the memory hotplug device was always created, we can
> simply continue faking support for SCLP_FC_ASSIGN_ATTACH_READ_STOR and
> expose the same information just as if no maxmem and slots parameter was
> given on the command line (to not break migration of ordinary guests).
I'm a bit worried here, though. Doesn't that imply a guest-visible
change?
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> hw/s390x/sclp.c | 261 ++++--------------------------------------------
> include/hw/s390x/sclp.h | 19 ----
> target/s390x/cpu.h | 2 -
> 3 files changed, 18 insertions(+), 264 deletions(-)
Nice diffstat :)
>
> diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
> index 276972b59f..0a2114e592 100644
> --- a/hw/s390x/sclp.c
> +++ b/hw/s390x/sclp.c
> @@ -15,9 +15,7 @@
> #include "qemu/osdep.h"
> #include "qapi/error.h"
> #include "cpu.h"
> -#include "exec/memory.h"
> #include "sysemu/sysemu.h"
> -#include "exec/address-spaces.h"
> #include "hw/boards.h"
> #include "hw/s390x/sclp.h"
> #include "hw/s390x/event-facility.h"
> @@ -57,10 +55,8 @@ static void read_SCP_info(SCLPDevice *sclp, SCCB *sccb)
> {
> ReadInfo *read_info = (ReadInfo *) sccb;
> MachineState *machine = MACHINE(qdev_get_machine());
> - sclpMemoryHotplugDev *mhd = get_sclp_memory_hotplug_dev();
> int cpu_count;
> int rnsize, rnmax;
> - int slots = MIN(machine->ram_slots, s390_get_memslot_count());
> IplParameterBlock *ipib = s390_ipl_get_iplb();
>
> /* CPU information */
> @@ -78,38 +74,9 @@ static void read_SCP_info(SCLPDevice *sclp, SCCB *sccb)
> read_info->conf_char_ext);
>
> read_info->facilities = cpu_to_be64(SCLP_HAS_CPU_INFO |
> - SCLP_HAS_IOA_RECONFIG);
> -
> - /* Memory Hotplug is only supported for the ccw machine type */
> - if (mhd) {
> - mhd->standby_subregion_size = MEM_SECTION_SIZE;
> - /* Deduct the memory slot already used for core */
> - if (slots > 0) {
> - while ((mhd->standby_subregion_size * (slots - 1)
> - < mhd->standby_mem_size)) {
> - mhd->standby_subregion_size = mhd->standby_subregion_size << 1;
> - }
> - }
> - /*
> - * Initialize mapping of guest standby memory sections indicating which
> - * are and are not online. Assume all standby memory begins offline.
> - */
> - if (mhd->standby_state_map == 0) {
> - if (mhd->standby_mem_size % mhd->standby_subregion_size) {
> - mhd->standby_state_map = g_malloc0((mhd->standby_mem_size /
> - mhd->standby_subregion_size + 1) *
> - (mhd->standby_subregion_size /
> - MEM_SECTION_SIZE));
> - } else {
> - mhd->standby_state_map = g_malloc0(mhd->standby_mem_size /
> - MEM_SECTION_SIZE);
> - }
> - }
> - mhd->padded_ram_size = ram_size + mhd->pad_size;
> - mhd->rzm = 1 << mhd->increment_size;
> + SCLP_HAS_IOA_RECONFIG |
> + SCLP_FC_ASSIGN_ATTACH_READ_STOR);
>
> - read_info->facilities |= cpu_to_be64(SCLP_FC_ASSIGN_ATTACH_READ_STOR);
> - }
Previously we only indicated this facility if we actually had standby
mem, didn't we?
(...)
> static void assign_storage(SCLPDevice *sclp, SCCB *sccb)
> {
> - MemoryRegion *mr = NULL;
> - uint64_t this_subregion_size;
> - AssignStorage *assign_info = (AssignStorage *) sccb;
> - sclpMemoryHotplugDev *mhd = get_sclp_memory_hotplug_dev();
> - ram_addr_t assign_addr;
> - MemoryRegion *sysmem = get_system_memory();
> -
> - if (!mhd) {
> - sccb->h.response_code = cpu_to_be16(SCLP_RC_INVALID_SCLP_COMMAND);
> - return;
> - }
> - assign_addr = (be16_to_cpu(assign_info->rn) - 1) * mhd->rzm;
> -
> - if ((assign_addr % MEM_SECTION_SIZE == 0) &&
> - (assign_addr >= mhd->padded_ram_size)) {
> - /* Re-use existing memory region if found */
> - mr = memory_region_find(sysmem, assign_addr, 1).mr;
> - memory_region_unref(mr);
> - if (!mr) {
> -
> - MemoryRegion *standby_ram = g_new(MemoryRegion, 1);
> -
> - /* offset to align to standby_subregion_size for allocation */
> - ram_addr_t offset = assign_addr -
> - (assign_addr - mhd->padded_ram_size)
> - % mhd->standby_subregion_size;
> -
> - /* strlen("standby.ram") + 4 (Max of KVM_MEMORY_SLOTS) + NULL */
> - char id[16];
> - snprintf(id, 16, "standby.ram%d",
> - (int)((offset - mhd->padded_ram_size) /
> - mhd->standby_subregion_size) + 1);
> -
> - /* Allocate a subregion of the calculated standby_subregion_size */
> - if (offset + mhd->standby_subregion_size >
> - mhd->padded_ram_size + mhd->standby_mem_size) {
> - this_subregion_size = mhd->padded_ram_size +
> - mhd->standby_mem_size - offset;
> - } else {
> - this_subregion_size = mhd->standby_subregion_size;
> - }
> -
> - memory_region_init_ram(standby_ram, NULL, id, this_subregion_size,
> - &error_fatal);
> - /* This is a hack to make memory hotunplug work again. Once we have
> - * subdevices, we have to unparent them when unassigning memory,
> - * instead of doing it via the ref count of the MemoryRegion. */
> - object_ref(OBJECT(standby_ram));
> - object_unparent(OBJECT(standby_ram));
> - memory_region_add_subregion(sysmem, offset, standby_ram);
> - }
> - /* The specified subregion is no longer in standby */
> - mhd->standby_state_map[(assign_addr - mhd->padded_ram_size)
> - / MEM_SECTION_SIZE] = 1;
> - }
> + /* FIXME, is there really no error code to indicate? */
> sccb->h.response_code = cpu_to_be16(SCLP_RC_NORMAL_COMPLETION);
Again, I think we did not actually have a mhd if we did not have
standby mem, so this already returned invalid command before? What am I
missing?
next prev parent reply other threads:[~2018-02-19 17:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-19 14:33 [Qemu-devel] [PATCH RFC] s390x/sclp: remove memory hotplug support David Hildenbrand
2018-02-19 17:08 ` Cornelia Huck [this message]
2018-02-19 17:12 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180219180831.2f36ec1e.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=david@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).