xen/arm: change DomU memory property size from u64 to u32

Commit Message

Viktor Mitin July 9, 2019, 7:49 a.m. UTC

While checking xen dom0less documentation it has been found
that domU memory property requires extra 0x0 in case of arm64.

There is no need to keep memory size in u64, 32 bits is
enough for domU memory size.

Tested that in case of arm64 dom0less domU works
without adding extra 0x0 to domU memory property with this patch.

Signed-off-by: Viktor Mitin <[e-mail]>
---
 xen/arch/arm/domain_build.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Julien Grall July 9, 2019, 12:29 p.m. UTC | #1

Hi Viktor,

On 7/9/19 8:49 AM, Viktor Mitin wrote:
> While checking xen dom0less documentation it has been found
> that domU memory property requires extra 0x0 in case of arm64.

And this matches the binding docs/misc/arm/device-tree/booting.txt which 
requires a 64-bit value.

> 
> There is no need to keep memory size in u64, 32 bits is
> enough for domU memory size.
Definitely not. The memory is given in KB so 32-bits only allows to 
cover 4TB. While I agree that none of the DomU created by Xen will be 
bigger than a few gigabytes today, user exposed interfaces should always 
cater for the future.

In any case, the interface changes you suggest is going to break user 
properly using the bindings.

Regards,

Viktor Mitin July 9, 2019, 5:22 p.m. UTC | #2

Hi Julien,

On Tue, Jul 9, 2019 at 3:29 PM Julien Grall <[e-mail]> wrote:
>
> Hi Viktor,
>
> On 7/9/19 8:49 AM, Viktor Mitin wrote:
> > While checking xen dom0less documentation it has been found
> > that domU memory property requires extra 0x0 in case of arm64.
>
> And this matches the binding docs/misc/arm/device-tree/booting.txt which
> requires a 64-bit value.
>
> >
> > There is no need to keep memory size in u64, 32 bits is
> > enough for domU memory size.
> Definitely not. The memory is given in KB so 32-bits only allows to
> cover 4TB. While I agree that none of the DomU created by Xen will be
> bigger than a few gigabytes today, user exposed interfaces should always
> cater for the future.
>
> In any case, the interface changes you suggest is going to break user
> properly using the bindings.
>

You are right. Please ignore this patch.
I will add extra 0x0 to dom0less documentation instead.

Thanks

> Regards,
>
> --
> Julien Grall

Patch

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d9836779d1..2c1a8c243e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2012,9 +2012,9 @@  static int __init construct_domU(struct domain *d,
 {
     struct kernel_info kinfo = {};
     int rc;
-    u64 mem;
+    u32 mem;
 
-    rc = dt_property_read_u64(node, "memory", &mem);
+    rc = dt_property_read_u32(node, "memory", &mem);
     if ( !rc )
     {
         printk("Error building DomU: cannot read \"memory\" property\n");
@@ -2022,7 +2022,7 @@  static int __init construct_domU(struct domain *d,
     }
     kinfo.unassigned_mem = (paddr_t)mem * SZ_1K;
 
-    printk("*** LOADING DOMU cpus=%u memory=%"PRIx64"KB ***\n", d->max_vcpus, mem);
+    printk("*** LOADING DOMU cpus=%u memory=%"PRIx32"KB ***\n", d->max_vcpus, mem);
 
     kinfo.vpl011 = dt_property_read_bool(node, "vpl011");