Re: [Xen-devel] [PATCH v3 3/6] xen/arm: keep track of reserved-memory regions

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 10 Jul 2019, Julien Grall wrote:
> Hi,
> 
> On 6/22/19 12:56 AM, Stefano Stabellini wrote:
> > As we parse the device tree in Xen, keep track of the reserved-memory
> > regions as they need special treatment (follow-up patches will make use
> > of the stored information.)
> > 
> > Reuse process_memory_node to add reserved-memory regions to the
> > bootinfo.reserved_mem array.
> > 
> > Refuse to continue once we reach the max number of reserved memory
> > regions to avoid accidentally mapping any portions of them into a VM.
> > 
> > Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx>
> > 
> > ---
> > It is cleaner to avoid sharing the whole function process_memory_node
> > between the normal memory case and the reserved-memory case. I'll do it
> > in the next version once I understand the best way do to it.
> 
> parse_reg(....)
> {
> 
> if (reg not present)
>   return -ENOPRESENT
> 
> /* parse regs */
> 
> return (full) ? -EFULL : 0;
> }
> 
> process_memory_node(....)
> {
>    return parse_reg(...);
> }
> 
> process_reserved_region()
> {
>     ret = parse_reg(...);
>     if ( ret == -EFULL )
>       panic(....);
>     else if ( ret != -ENOPRESENT )
>       return ret;
>     return 0;
> }

Thank you, that clarified things a lot!


> > ---
> > Changes in v3:
> > - match only /reserved-memory
> > - put the warning back in place for reg not present on a normal memory
> >    region
> > - refuse to continue once we reach the max number of reserved memory
> >    regions
> > 
> > Changes in v2:
> > - call process_memory_node from process_reserved_memory_node to avoid
> >    duplication
> > ---
> >   xen/arch/arm/bootfdt.c      | 38 +++++++++++++++++++++++++++++++------
> >   xen/include/asm-arm/setup.h |  1 +
> >   2 files changed, 33 insertions(+), 6 deletions(-)
> > 
> > diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> > index 611724433b..b24ab10cb9 100644
> > --- a/xen/arch/arm/bootfdt.c
> > +++ b/xen/arch/arm/bootfdt.c
> > @@ -135,6 +135,8 @@ static int __init process_memory_node(const void *fdt,
> > int node,
> >       const __be32 *cell;
> >       paddr_t start, size;
> >       u32 reg_cells = address_cells + size_cells;
> > +    struct meminfo *mem;
> > +    bool reserved = (bool)data;
> >         if ( address_cells < 1 || size_cells < 1 )
> >       {
> > @@ -143,29 +145,49 @@ static int __init process_memory_node(const void *fdt,
> > int node,
> >           return 0;
> >       }
> >   +    if ( reserved )
> > +        mem = &bootinfo.reserved_mem;
> > +    else
> > +        mem = &bootinfo.mem;
> 
> Rather than passing a bool, you could pass bootinfo.{mem, reserved_mem} in
> parameter.

I'll do that


> > +
> >       prop = fdt_get_property(fdt, node, "reg", NULL);
> >       if ( !prop )
> >       {
> > -        printk("fdt: node `%s': missing `reg' property\n", name);
> > +        if ( !reserved )
> > +            printk("fdt: node `%s': missing `reg' property\n", name);
> 
> I would just get rid of this print and return an error than allow the caller
> to decide what to do.

Yep


> >           return 0;
> >       }
> >         cell = (const __be32 *)prop->data;
> >       banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
> >   -    for ( i = 0; i < banks && bootinfo.mem.nr_banks < NR_MEM_BANKS; i++ )
> > +    for ( i = 0; i < banks && mem->nr_banks < NR_MEM_BANKS; i++ )
> >       {
> >           device_tree_get_reg(&cell, address_cells, size_cells, &start,
> > &size);
> >           if ( !size )
> >               continue;
> > -        bootinfo.mem.bank[bootinfo.mem.nr_banks].start = start;
> > -        bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
> > -        bootinfo.mem.nr_banks++;
> > +        mem->bank[mem->nr_banks].start = start;
> > +        mem->bank[mem->nr_banks].size = size;
> > +        mem->nr_banks++;
> >       }
> > +    /*
> > +     * We reached the max number of supported reserved-memory regions.
> > +     * Stop and refuse to continue. We don't want to risk Xen allocating
> > +     * those regions as normal memory to a VM.
> 
> The last sentence is confusing because reserved-region are normal memory that
> have been carved out for a specific usage. Also, the problem is not only with
> VM but any memory allocation.
> 
> So a better sentence would be: "We don't want to give the pages to the
> allocator".

Thanks, I'll make the change

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel