Hi Jan,
> -----Original Message-----
> From: Jan Beulich <[email protected]>
> Sent: 2022年7月14日 18:58
> To: Wei Chen <[email protected]>
> Cc: nd <[email protected]>; Andrew Cooper <[email protected]>; Roger Pau
> Monné <[email protected]>; Wei Liu <[email protected]>; xen-
> [email protected]
> Subject: Re: [PATCH v2 2/9] xen/x86: Use enumerations to indicate NUMA
> status
>
> On 14.07.2022 12:49, Wei Chen wrote:
> >> From: Jan Beulich <[email protected]>
> >> Sent: 2022年7月14日 18:37
> >> status
> >>>>
> >>>> Well, this makes the table complete, but it doesn't explain how you
> >> mean
> >>>> to fold the settings of the two command line options into one
> variable.
> >>>>
> >>>
> >>> No matter how many separate "numa=" parameters have been parsed from
> >>> Command line, the values of these original variables are determined
> >>> after parsing the command line. So the determined status can be mapped
> >>> to the new one variable from above table.
> >>
> >> Hmm, I was partly wrong - the initial values of both variables are
> >> indeed set from just the single "numa=" parsing. But later on they
> >> "evolve" independently, and multiple "numa=" on the command line
> >> can also have "interesting" effects. I'm afraid I still can't
> >
> > Can you provide some examples? This way I can better understand your
> > concerns.
>
> Take bad_srat(): you convert "acpi_numa = -1" to setting numa_no_acpi.
> Yet imo (matching the present model) numa_off shouldn't be affected.
> While your change is fine in practice for (current) x86, it is wrong
> in the abstract model (which is relevant when making things common).
>
Thanks, I understand your concerns now. In this case, I agree with your
suggestion in previous e-mail:
> int numa_disabled(void)
> {
> return numa_off || arch_numa_disabled();
> }
>
> with arch_numa_disabled() evaluating acpi_numa on x86.
I would update this patch like above sample in next version. And in
this way, I think We don't need the new enumerations and mapping table.
Cheers,
Wei Chen
> Jan
