On Mon, Jun 16, 2014 at 05:53:53PM +1000, Alexey Kardashevskiy wrote:
> Currently NUMA nodes must go consequently and QEMU ignores nodes
> with @nodeid bigger than the number of NUMA nodes in the command line.
Why would somebody need a NUMA node with nodeid bigger than the number
of NUMA nodes? NUMA node IDs must be in the [0, numa_nodes-1] range.
> This prevents us from creating memory-less nodes which is possible
> situation in POWERPC under pHyp or Sapphire.
Why? If I recall correctly, nodes without any CPUs or any memory are
already allowed.
How exactly would this patch help you? How do you expect the
command-line to look like for your use case?
>
> This makes nb_numa_nodes a total number of nodes or the biggest node
> number + 1 whichever is greater.
>
> Signed-off-by: Alexey Kardashevskiy <a...@ozlabs.ru>
> ---
> vl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/vl.c b/vl.c
> index ac0e3d7..f1b75cb 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1356,7 +1356,7 @@ static void numa_add(const char *optarg)
> if (get_param_value(option, 128, "cpus", optarg) != 0) {
> numa_node_parse_cpus(nodenr, option);
> }
> - nb_numa_nodes++;
> + nb_numa_nodes = MAX(nb_numa_nodes + 1, nodenr + 1);
I would instead suggest that if any node in the [0, max_node_id] range
is not present on the command-line, QEMU should instead reject the
command-line.
> } else {
> fprintf(stderr, "Invalid -numa option: %s\n", option);
> exit(1);
> --
> 2.0.0
>
--
Eduardo
