All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@linux.vnet.ibm.com>
To: Bharata B Rao <891525@bugs.launchpad.net>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 891525] [NEW] Guest kernel crashes when booting a NUMA guest	without explicitly specifying cpus= in -numa option
Date: Fri, 18 Nov 2011 11:57:27 +0530	[thread overview]
Message-ID: <20111118062727.GD4993@in.ibm.com> (raw)
In-Reply-To: <20111117085751.16490.43574.malonedeb@chaenomeles.canonical.com>

The reason for guest kernel crash is because qemu enumerates the VCPUs
in a round robin fashion between the nodes. As per this comment from
vl.c, guest kernel is supposed to handle this:

/* assigning the VCPUs round-robin is easier to implement, guest OSes
 * must cope with this anyway, because there are BIOSes out there in
 * real machines which also use this scheme.
 */

I am not sure if this would be considered a bug in the guest kernel,
but I have verifed that enumerating the VCPUs in a serial manner between
nodes fixes the problem for me. I am not aware of the history behind
round robin assignment nor do I understand the full implications of
changing it, but here is a potential patch that fixes the problem for me.
---

Fix VCPU enumeration between nodes

From: Bharata B Rao <bharata@linux.vnet.ibm.com>

Currently VCPUs are assigned to nodes in round robin manner.
This is seen to break guest kernel for x86_64-softmmu. Hence assign
VCPUs serially between nodes.

Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
---

 vl.c |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)


diff --git a/vl.c b/vl.c
index f5afed4..75348d0 100644
--- a/vl.c
+++ b/vl.c
@@ -3307,13 +3307,18 @@ int main(int argc, char **argv, char **envp)
             if (node_cpumask[i] != 0)
                 break;
         }
-        /* assigning the VCPUs round-robin is easier to implement, guest OSes
-         * must cope with this anyway, because there are BIOSes out there in
-         * real machines which also use this scheme.
-         */
+        /* Assign VCPUs to nodes in serial manner */
         if (i == nb_numa_nodes) {
+            int cpus_per_node = smp_cpus / nb_numa_nodes;
+
             for (i = 0; i < smp_cpus; i++) {
-                node_cpumask[i % nb_numa_nodes] |= 1 << i;
+                int nodeid = i / cpus_per_node;
+
+                /* Extra VCPUs goto Node 0 */
+                if (nodeid >= nb_numa_nodes) {
+                    nodeid = 0;
+                }
+                node_cpumask[nodeid] |= 1 << i;
             }
         }
     }

  reply	other threads:[~2011-11-18  6:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-17  8:57 [Qemu-devel] [Bug 891525] [NEW] Guest kernel crashes when booting a NUMA guest without explicitly specifying cpus= in -numa option Bharata B Rao
2011-11-18  6:27 ` Bharata B Rao [this message]
2016-11-08 10:21 ` [Qemu-devel] [Bug 891525] " Thomas Huth
2017-01-08  4:17 ` Launchpad Bug Tracker

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=20111118062727.GD4993@in.ibm.com \
    --to=bharata@linux.vnet.ibm.com \
    --cc=891525@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.