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