On Thu, 23 Mar 2017 11:40:29 +0530
Bharata B Rao <bharata....@gmail.com> wrote:
> On Wed, Mar 22, 2017 at 7:02 PM, Igor Mammedov <imamm...@redhat.com> wrote:
>
> > diff --git a/numa.c b/numa.c
> > index e01cb54..b6e71bc 100644
> > --- a/numa.c
> > +++ b/numa.c
> > @@ -294,9 +294,10 @@ static void validate_numa_cpus(void)
> > g_free(seen_cpus);
> > }
> >
> > -void parse_numa_opts(MachineClass *mc)
> > +void parse_numa_opts(MachineState *ms)
> > {
> > int i;
> > + MachineClass *mc = MACHINE_GET_CLASS(ms);
> >
> > for (i = 0; i < MAX_NODES; i++) {
> > numa_info[i].node_cpu = bitmap_new(max_cpus);
> > @@ -378,14 +379,16 @@ void parse_numa_opts(MachineClass *mc)
> > * rule grouping VCPUs by socket so that VCPUs from the same
> > socket
> > * would be on the same node.
> > */
> > + if (!mc->cpu_index_to_instance_props) {
> > + error_report("default CPUs to NUMA node mapping isn't
> > supported");
> > + exit(1);
> > + }
> >
>
> Just trying to understand the impact of the above enforcement. So targets
> and machine types that don't define ->cpu_index_to_instance_props() are
> expected not to boot ? Shouldn't they have a default to fall back upon ?
Currently there are 3 boards that support numa and with this series
they all implement cpu_index_to_instance_props callback,
so boards that has supported numa shouldn't be affected.
But if someone used '-numa' with a board that doesn't support numa,
it would stop booting with error message instead of silently parsing
not supported option or falling back bogus defaults (which aren't
used anyway).
> Regards,
> Bharata.
