From: Andre Przywara <andre.przywara@amd.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: libvir-list@redhat.com, qemu-devel@nongnu.org,
Bharata B Rao <bharata@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] qemu -numa option and non-contiguous CPU ranges
Date: Thu, 21 Jun 2012 23:39:46 +0200 [thread overview]
Message-ID: <4FE394A2.8070709@amd.com> (raw)
In-Reply-To: <20120621175125.GJ5073@otherpad.lan.raisama.net>
On 06/21/2012 07:51 PM, Eduardo Habkost wrote:
> Hi,
>
> I just noticed libvirt tries to use the -numa option in a way that qemu
> never understood: if a node is configured to have a non-contiguous set
> of CPUs, it tries to generate a command-line option that looks like:
>
> "-numa node,nodeid=...,cpus=0,2,4,mem=..."
> ^^^^^
>
> But this format was never supported by qemu. This format is even a bit
> weird, as "," is an option separator, and it is being used as a
> separator _inside_ an option.
Exactly this was the reason back then to not support non-contiguous set
of CPUs. Inside qemu there is no reason why this shouldn't work, it was
just hard to write on the command line. So after a short discussion we
decided to drop this for the time being. If you have a great idea how to
specify this (I think a comma will not work, because it will be catched
earlier), I am all ears.
Regards,
Andre.
> My question is: should we support this option format in qemu, or should
> we change libvirt to use another format (that has yet to be implemented,
> because currently there's no way to specify a non-contiguous set of CPUs
> for a NUMA node).
>
> Any suggestions?
>
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
next prev parent reply other threads:[~2012-06-21 22:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-21 17:51 [Qemu-devel] qemu -numa option and non-contiguous CPU ranges Eduardo Habkost
2012-06-21 21:39 ` Andre Przywara [this message]
2012-06-22 10:00 ` Daniel P. Berrange
2012-06-22 15:18 ` Eduardo Habkost
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=4FE394A2.8070709@amd.com \
--to=andre.przywara@amd.com \
--cc=bharata@linux.vnet.ibm.com \
--cc=ehabkost@redhat.com \
--cc=libvir-list@redhat.com \
--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.