Re: [PATCH v2 2/9] xen/x86: Use enumerations to indicate NUMA status

[Jan Beulich <jbeulich@xxxxxxxx>]

On 14.07.2022 12:37, Jan Beulich wrote:
> On 14.07.2022 12:26, Wei Chen wrote:
>>> From: Jan Beulich <jbeulich@xxxxxxxx>
>>> Sent: 2022年7月14日 17:58
>>> To: Wei Chen <Wei.Chen@xxxxxxx>
>>>>
>>>> How about update the table like this:
>>>> +------------+----------+----------------+----------------+------------+
>>>> |  original  |          |                |                |            |
>>>> +------------+----------+----------------+----------------+------------+
>>>> | numa_off   | true     | true           | true           | true       |
>>>> | acpi_numa  | 0        | 1              | -1             | x          |
>>>> | numa_fake  | x        | x              | x              | fake_nodes |
>>>> | enum state | numa_off | numa_off       | numa_off       | numa_off   |
>>>> +------------+----------+----------------+----------------+------------+
>>>>
>>>> +------------+----------------+------------+-------------+------------+
>>>> |  original  |                |            |             |            |
>>>> +------------+----------------+------------+-------------+------------+
>>>> | numa_off   | false          | false      | false       | false      |
>>>> | acpi_numa  | 0              | 1          | -1          | x          |
>>>> | numa_fake  | x              | x          | x           | fake_nodes |
>>>> | enum state | numa_fw_nodata | numa_fw_ok | numa_fw_bad | numa_emu   |
>>>> +------------+----------------+------------+-------------+------------+
>>>
>>> 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
> convince myself that the new mapping fully represents all originally
> possible combinations (nor can I convince myself that in the existing
> code everything is working as intended).

Maybe the solution is to make numa_off common but keep acpi_numa
arch-specific? Then e.g. the replacement of srat_disabled() could
be

int numa_disabled(void)
{
    return numa_off || arch_numa_disabled();
}

with arch_numa_disabled() evaluating acpi_numa on x86.

Jan