[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
- [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option, Bandan Das, 2013/06/18
- Re: [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option, Igor Mammedov, 2013/06/19
- Re: [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option,
Eduardo Habkost <=
- Re: [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option, Eduardo Habkost, 2013/06/20
- Re: [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option, Paolo Bonzini, 2013/06/20
- Re: [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option, Bandan Das, 2013/06/20
- Re: [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option, Wanlong Gao, 2013/06/21
- Re: [Qemu-devel] [PATCH v3] vl.c: Support multiple CPU ranges on -numa option, Bandan Das, 2013/06/21