Re: [PATCH 13/15] x86/hyperlaunch: add memory parsing to domain config

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.12.2024 19:02, Daniel P. Smith wrote:
> On 12/2/24 07:14, Jan Beulich wrote:
>> On 23.11.2024 19:20, Daniel P. Smith wrote:
>>> @@ -160,6 +161,42 @@ static int __init process_domain_node(
>>>               else
>>>                   printk("PV\n");
>>>           }
>>> +        if ( match_fdt_property(fdt, prop, "memory" ) )
>>> +        {
>>> +            uint64_t kb;
>>> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
>>> +            {
>>> +                printk("  failed processing memory for domain %s\n",
>>> +                       name == NULL ? "unknown" : name);
>>> +                return -EINVAL;
>>> +            }
>>> +            bd->mem_pages = PFN_DOWN(kb * SZ_1K);
>>> +            printk("  memory: %ld\n", bd->mem_pages << PAGE_SHIFT);
>>> +        }
>>> +        if ( match_fdt_property(fdt, prop, "mem-min" ) )
>>> +        {
>>> +            uint64_t kb;
>>> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
>>> +            {
>>> +                printk("  failed processing memory for domain %s\n",
>>> +                       name == NULL ? "unknown" : name);
>>> +                return -EINVAL;
>>> +            }
>>> +            bd->min_pages = PFN_DOWN(kb * SZ_1K);
>>> +            printk("  min memory: %ld\n", bd->min_pages << PAGE_SHIFT);
>>> +        }
>>> +        if ( match_fdt_property(fdt, prop, "mem-max" ) )
>>> +        {
>>> +            uint64_t kb;
>>> +            if ( fdt_prop_as_u64(prop, &kb) != 0 )
>>> +            {
>>> +                printk("  failed processing memory for domain %s\n",
>>> +                       name == NULL ? "unknown" : name);
>>> +                return -EINVAL;
>>> +            }
>>> +            bd->max_pages = PFN_DOWN(kb * SZ_1K);
>>> +            printk("  max memory: %ld\n", bd->max_pages << PAGE_SHIFT);
>>> +        }
>>
>> Since the values logged are all multiples of 1k, why make reading the logs
>> more complicated by logging byte-granular values? I instead wonder whether
>> converting to more coarse grained values (leaving, say, between 4 and 6
>> significant digits while using kb, Mb, Gb, etc) wouldn't be yet better.
> 
> Sure we can make it report in a friendlier format. To support dynamic 
> sizing, is there already an existing formatter, I would hate to 
> re-invent the wheel on this, or I could just statically report in kb.

I don't recall use having any formatter for this, so for now I'd just report
kb values.

Jan