qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa o


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option
Date: Wed, 19 Jun 2013 10:26:42 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Jun 19, 2013 at 01:42:52PM +0200, Igor Mammedov wrote:
> On Tue, 18 Jun 2013 16:09:49 -0400
> Bandan Das <address@hidden> wrote:
> 
> > 
> > This allows us to use the cpu property multiple times
> > to specify multiple cpu (ranges) to the -numa option :
> > 
> > -numa node,cpu=1,cpu=2,cpu=4
> > or
> > -numa node,cpu=1-3,cpu=5
> > 
> > Signed-off-by: Bandan Das <address@hidden>
> > ---
> >  v3: Convert to using QemuOpts
> >  Use -cpu rather than -cpus which probably probably makes it more 
> > meaningful for non-range arguments
> > 
> > Sorry for reviving this up :)
> > 
> > This is a follow up to earlier proposals sent by Eduardo.
> > 
> > References :
> > 1. http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg03832.html
> > 2. https://lists.gnu.org/archive/html/qemu-devel/2013-02/msg03857.html
> > 
> > So, basically the format seemed easier to work with if we are thinking 
> > of using QemuOpts for -numa. Using -cpu rather than cpus probably
> > makes it less ambiguous as well IMO. However, it's probably not a good idea
> > if the current syntax is well established ?

libvirt uses the "cpus" option already, so we have to keep it working.

> In context of x86, allowing to specify CPU threads using cpu_index isn't 
> correct,
> since node calculated from APIC ID and node it gets from ACPI table could 
> differ.
> 
> It could be better for CLI interface to accept socket number and build always
> correct NUMA mapping internally using APIC IDs from CPUs, as it's done in real
> hardware.
> 
> In addition it would allow to deprecate use of cpu_index on CLI interface, and
> simplify following re-factoring to use socket/[core/]thread as means to 
> address/
> specify specific CPUs there and later in monitor/qmp interface as well.

What about simply accepting a QOM object path? Today we could only
accept CPU thread objects (because there are no socket/core objects
yet), but the day we introduce CPU socket objects, we can change the
code to accept them without changing the syntax.

-- 
Eduardo



reply via email to

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