On Wed, Mar 22, 2017 at 02:32:25PM +0100, Igor Mammedov wrote: > Changes since RFC: > * convert all targets that support numa (Eduardo) > * add numa CLI tests > * support wildcard matching with "-numa cpu,..." (Paolo) > > Series introduces a new CLI option to allow mapping cpus to numa > nodes using public properties [socket|core|thread]-ids instead of > internal cpu_index and moving internal handling of cpu<->node > mapping from cpu_index based global bitmaps to MachineState. > > New '-numa cpu' option is supported only on PC and SPAPR > machines that implement hotpluggable-cpus query. > ARM machine user-facing interface stays cpu_index based due to > lack of hotpluggable-cpus support, but internally cpu<->node > mapping will be using the common for PC/SPAPR/ARM approach > (i.e. store mapping info in MachineState:possible_cpus) > > It only provides CLI interface to do mapping, there is no QMP > one as I haven't found a suitable place/way to update/set mapping > after machine_done for QEMU started with -S (stopped mode) so that > mgmt could query hopluggable-cpus first, then map them to numa nodes > in runtime before actually allowing guest to run. > > Another alternative I've been considering is to add CLI option > similar to -S but that would pause initialization before machine_init() > callback is run so that user can get CPU layout with hopluggable-cpus, > then map CPUs to numa nodes and unpause to let machine_init() initialize > machine using previously predefined numa mapping. > Such option might also be useful for other usecases.
I would support this approach. This would help on other use cases as well, and it's what I suggsted at KVM Forum last year: http://www.linux-kvm.org/images/4/46/03x06A-Eduardo_HabkostMachine-type_Introspection_and_Configuration_Where_Are_We_Going.pdf But I would treat it as a future plan, as it might take some time until we refactor the main-loop/QMP code to allow this to happen. -- Eduardo
