qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu -numa option and non-contiguous CPU ranges


From: Eduardo Habkost
Subject: Re: [Qemu-devel] qemu -numa option and non-contiguous CPU ranges
Date: Fri, 22 Jun 2012 12:18:29 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Jun 22, 2012 at 11:00:57AM +0100, Daniel P. Berrange wrote:
> On Thu, Jun 21, 2012 at 11:39:46PM +0200, Andre Przywara wrote:
> > 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.
> 
> Lets just use a ';' or ':' as the seperator instead ?

Sounds like a better option, instead of making the -numa option parsing
be different from all other options. I was just wondering if it was
worth making some effort to make qemu compatible with the current
libvirt code. (I am inclined to say it is not worth it, as it never
worked before)

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]