qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: aik@ozlabs.ru, Bharata B Rao <bharata@linux.vnet.ibm.com>,
	mdroth@linux.vnet.ibm.com, agraf@suse.de, qemu-ppc@nongnu.org,
	tyreld@linux.vnet.ibm.com, nfont@linux.vnet.ibm.com,
	imammedo@redhat.com, david@gibson.dropbear.id.au
Subject: [Qemu-devel] [RFC PATCH v5 6/6] spapr: Don't allow memory hotplug to memory less nodes
Date: Thu, 25 Jun 2015 11:44:15 +0530	[thread overview]
Message-ID: <1435212855-21685-7-git-send-email-bharata@linux.vnet.ibm.com> (raw)
In-Reply-To: <1435212855-21685-1-git-send-email-bharata@linux.vnet.ibm.com>

Currently PowerPC kernel doesn't allow hot-adding memory to memory-less
node, but instead will silently add the memory to the first node that has
some memory. This causes two unexpected behaviours for the user.

Memory gets hotplugged to a different node than what the user specified.
Since pc-dimm subsystem in QEMU still thinks that memory belongs to
memory-less node, a reboot will set things accordingly and the previously
hotplugged memory now ends in the right node. This appears as if some
memory moved from one node to another.

So until kernel starts supporting memory hotplug to memory-less
nodes, just prevent such attempts upfront in QEMU.

Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
---
 hw/ppc/spapr.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index f4792b8..003ef14 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -2139,6 +2139,28 @@ static void spapr_machine_device_plug(HotplugHandler *hotplug_dev,
             return;
         }
 
+        /*
+         * Currently PowerPC kernel doesn't allow hot-adding memory to
+         * memory-less node, but instead will silently add the memory
+         * to the first node that has some memory. This causes two
+         * unexpected behaviours for the user.
+         *
+         * - Memory gets hotplugged to a different node than what the user
+         *   specified.
+         * - Since pc-dimm subsystem in QEMU still thinks that memory belongs
+         *   to memory-less node, a reboot will set things accordingly
+         *   and the previously hotplugged memory now ends in the right node.
+         *   This appears as if some memory moved from one node to another.
+         *
+         * So until kernel starts supporting memory hotplug to memory-less
+         * nodes, just prevent such attempts upfront in QEMU.
+         */
+        if (nb_numa_nodes && !numa_info[node].node_mem) {
+            error_setg(errp, "Can't hotplug memory to memory-less node %d",
+                       node);
+            return;
+        }
+
         spapr_memory_plug(hotplug_dev, dev, node, errp);
     }
 }
-- 
2.1.0

  parent reply	other threads:[~2015-06-25  6:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-25  6:14 [Qemu-devel] [PATCH v5 0/6] Memory hotplug for PowerPC sPAPR guests Bharata B Rao
2015-06-25  6:14 ` [Qemu-devel] [PATCH v5 1/6] spapr: Initialize hotplug memory address space Bharata B Rao
2015-06-26  5:21   ` David Gibson
2015-06-25  6:14 ` [Qemu-devel] [PATCH v5 2/6] spapr: Add LMB DR connectors Bharata B Rao
2015-06-26  5:38   ` David Gibson
2015-06-26  6:54     ` Bharata B Rao
2015-06-25  6:14 ` [Qemu-devel] [PATCH v5 3/6] spapr: Support ibm, dynamic-reconfiguration-memory Bharata B Rao
2015-06-26  5:28   ` David Gibson
2015-06-25  6:14 ` [Qemu-devel] [PATCH v5 4/6] spapr: Make hash table size a factor of maxram_size Bharata B Rao
2015-06-25  6:14 ` [Qemu-devel] [PATCH v5 5/6] spapr: Memory hotplug support Bharata B Rao
2015-06-26  5:31   ` David Gibson
2015-06-25  6:14 ` Bharata B Rao [this message]
2015-06-26  5:33   ` [Qemu-devel] [RFC PATCH v5 6/6] spapr: Don't allow memory hotplug to memory less nodes David Gibson
2015-06-26  5:43     ` Bharata B Rao
2015-06-26  6:06 ` [Qemu-devel] [PATCH v5 0/6] Memory hotplug for PowerPC sPAPR guests David Gibson

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=1435212855-21685-7-git-send-email-bharata@linux.vnet.ibm.com \
    --to=bharata@linux.vnet.ibm.com \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=david@gibson.dropbear.id.au \
    --cc=imammedo@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=nfont@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=tyreld@linux.vnet.ibm.com \
    /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).