Re: [PATCH v13 06/12] numa: Extend CLI to provide memory latency and bandwidth information

[Tao Xu <tao3.xu@intel.com>]

On 10/26/2019 3:44 AM, Markus Armbruster wrote:
> Igor Mammedov <imammedo@redhat.com> writes:
> 
[...]
>>>>    1st: above is applicable to both bw and lat values and should be documented as such
>>>>    2nd: 'max NUM is 65534' when different suffixes is fleeting target,
>>>>         spec says that entry with 0xFFFF is unreachable, so how about documenting
>>>>         unreachable value as 0xFFFFFFFFFFFFFFFF (then CLI parsing code will
>>>>         exclude it from range detection and acpi table building code translate it
>>>>         to internal 0xFFFF it could fit into the tables)
>>>>    
>>>
>>> If we input 0xFFFFFFFFFFFFFFFF, qemu will raise error that parameter
>>> expect a size value.
>>
>> opts_type_size() can't handle values >= 0xfffffffffffffc00
>>
>> commit f46bfdbfc8f (util/cutils: Change qemu_strtosz*() from int64_t to uint64_t)
>>
>> so behavior would change depending on if the value is parsed by CLI (size) or QMP (unit64) parsers.
> 
> Do these values matter?  Is there a use case for passing
> 18446744073709550593 via CLI?
> 

There is a case that we need to input 0xFFFF as ACPI HMAT entry (an 
unreachable case). But I am thinking drop this case because Linux kernel 
HMAT as blow:

          /*
          * Check for invalid and overflow values
          */
         if (entry == 0xffff || !entry)
                 return 0;
         else if (base > (UINT_MAX / (entry)))
                 return 0;

So 0xFFFF and 0 are the same.

>> we can cannibalize 0x0 as the unreachable value and an absent bandwidth/lat option
>> for not specified case.
>> It would be conflicting with matrix [1] values in spec, but CLI/QMP deals with
>> absolute values which are later processed into HMAT substructure.
>>
>> Markus,
>> Can we make opts_type_size() handle full range of uint64_t?
> 
> Maybe.
>