Hi Ayan,
On 03/01/2023 09:21, Ayan Kumar Halder wrote:
On 02/01/2023 14:49, Michal Orzel wrote:
Printing domain's memory size in hex without even prepending it
with 0x is not very useful and can be misleading. Switch to decimal
notation.
Signed-off-by: Michal Orzel <michal.or...@amd.com>
---
xen/arch/arm/domain_build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 829cea8de84f..7e204372368c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3774,7 +3774,7 @@ static int __init construct_domU(struct domain *d,
if ( rc != 0 )
return rc;
- printk("*** LOADING DOMU cpus=%u memory=%"PRIx64"KB ***\n",
d->max_vcpus, mem);
+ printk("*** LOADING DOMU cpus=%u memory=%"PRIu64"KB ***\n",
d->max_vcpus, mem);
I will prefer it to be printed in hex format with 0x prefixed. The
reason being the mem is obtained from device-tree domU's 'memory' prop
where the values are in hex. >
It will help the user to debug easily without requiring the the person
to manually calculate the hex equivalent and then trying to correlate it
with what is written in dts.
I am a bit confused with your reasoning. The value stored in the
device-tree is a 64-bit value. This is then up to the consumer to decide
whether the output provided is in hexadecimal or decimal.
So are you saying that the tool dumping the device-tree will show the
values in hexadecimal?
If so, the argument is the same for the number of CPUs (you could have
more than 15 vCPUs). So I think this argument to be used here.
TBH, I am a bit split between using hexadecimal and decimal here. For
smaller values, decimal is definitely easier to read but for larger one
(i.e. GB), then the hexadecimal would help (it is easier to do the math).
So I would leaning towards using hexadecimal for the memory (so adding
the 0x).
Cheers,
--
Julien Grall
