On Wed, Jun 19, 2013 at 01:42:52PM +0200, Igor Mammedov wrote: > On Tue, 18 Jun 2013 16:09:49 -0400 > Bandan Das <b...@redhat.com> 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 <b...@redhat.com> > > --- > > 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
