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

[Tao Xu]

On 10/26/2019 3:44 AM, Markus Armbruster wrote:
> Igor Mammedov <address@hidden> 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.