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

[Igor Mammedov]

On Wed, 19 Jun 2013 10:26:42 -0300
Eduardo Habkost <address@hidden> wrote:

> 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.
Sure, we can leave it as it's now for some time while a new interface is
introduced/adopted. And than later deprecate "cpus".

> 
> > 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.
It doesn't matter if it's socket=N or QOM path, the idea is not to allow
individual CPU threads there to avoid misconfiguration, but use socket entities 
in some form in interface part. Sockets could be dummy containers for initial
implementation so not to delay sanitizing NUMA code.