Hi Julien

> -----Original Message-----
> From: Julien Grall <jul...@xen.org>
> Sent: Friday, August 13, 2021 9:12 PM
> To: Penny Zheng <penny.zh...@arm.com>; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis <bertrand.marq...@arm.com>; Wei Chen
> <wei.c...@arm.com>; nd <n...@arm.com>
> Subject: Re: [PATCH V4 09/10] xen/arm: check "xen,static-mem" property
> during domain construction
> 
> Hi,
> 
> On 28/07/2021 11:27, Penny Zheng wrote:
> > This commit checks "xen,static-mem" device tree property in /domUx
> > node, to determine whether domain is on Static Allocation, when
> > constructing domain during boot-up.
> >
> > Right now, the implementation of allocate_static_memory is missing,
> > and will be introduced later. It just BUG() out at the moment.
> 
> I think the code is small enough to fold it in patch #10. In fact...
> 

Ok. I'll combine.

> >
> > Signed-off-by: Penny Zheng <penny.zh...@arm.com>
> > ---
> >   xen/arch/arm/domain_build.c | 37
> ++++++++++++++++++++++++++++++++++++-
> >   1 file changed, 36 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 6c86d52781..cdb16f2086 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -2425,6 +2425,37 @@ static int __init construct_domU(struct domain *d,
> >       struct kernel_info kinfo = {};
> >       int rc;
> >       u64 mem;
> > +    const struct dt_property *static_mem_prop;
> > +    u32 static_mem_addr_cells, static_mem_size_cells;
> > +    bool static_mem = false;
> 
> You don't need those information outside of allocate_static_memory(). So I
> think it would be best to move the code in that function.
> 

Sure.

> > +
> > +    /*
> > +     * Guest RAM could be static memory which will be specified through
> > +     * "xen,static-mem" property.
> > +     */
> > +    static_mem_prop = dt_find_property(node, "xen,static-mem", NULL);
> > +    if ( static_mem_prop )
> > +    {
> > +        static_mem = true;
> > +
> > +        if ( !dt_property_read_u32(node, "#xen,static-mem-address-cells",
> > +                                   &static_mem_addr_cells) )
> > +        {
> > +            printk("Error building DomU: cannot read "
> > +                   "\"#xen,static-mem-address-cells\" property\n");
> We don't split comment over multi-line (even they are more than 80
> characters). This is to help grep message in the code.
> 
> Although for this one I would replaced "Error building Domu:" with simply
> with the domain ID (you can use %pd and 'd'). The caller will then print there
> was an error during building.
> 

Thanks for the explanation, learned.

> 
> > +            return -EINVAL;
> > +        }
> > +
> > +        if ( !dt_property_read_u32(node, "#xen,static-mem-size-cells",
> > +                                   &static_mem_size_cells) )
> > +        {
> > +            printk("Error building DomU: cannot read "
> > +                   "\"#xen,static-mem-size-cells\" property\n");
> 
> My remark applies here as well.
> 
> > +            return -EINVAL;
> > +        }
> > +
> > +        BUG_ON(static_mem_size_cells > 2 || static_mem_addr_cells >
> > + 2);
> 
> Did we validate the DT before hand? If not, then I think
> 

Yeah... I think I did the check in first parse. It's redundant.

> > +    }
> 
> 
> >
> >       rc = dt_property_read_u64(node, "memory", &mem);
> >       if ( !rc )
> > @@ -2452,7 +2483,11 @@ static int __init construct_domU(struct domain *d,
> >       /* type must be set before allocate memory */
> >       d->arch.type = kinfo.type;
> >   #endif
> > -    allocate_memory(d, &kinfo);
> > +    if ( !static_mem )
> 
> With my suggestion above, the check can be replaced with:
> 
> if ( !dt_find_property(node, "xen,static-mem", NULL) )
> 

Sure, That’s more simple.

> > +        allocate_memory(d, &kinfo);
> > +    else
> > +        /* TODO: allocate_static_memory(...). */
> > +        BUG();
> >
> >       rc = prepare_dtb_domU(d, &kinfo);
> >       if ( rc < 0 )
> >
> 
> Cheers,
> 
> --

Cheers

--
Penny
> Julien Grall

Reply via email to