Re: [Xen-devel] [PATCH v3 16/25] xen/arm: rename allocate_memory to allocate_memory_11

[Julien Grall <julien.grall@xxxxxxx>]

Hi Stefano,

On 08/15/2018 09:26 PM, Stefano Stabellini wrote:
> On Mon, 13 Aug 2018, Julien Grall wrote:
> > Hi,
> >
> > On 01/08/18 00:27, Stefano Stabellini wrote:
> > > allocate_memory only deals with directly mapped memory. Rename it to
> > > allocate_memory_11.
> > >
> > > Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx>
> > >
> > > ---
> > > Changes in v3:
> > > - add patch
> > > ---
> > >    xen/arch/arm/domain_build.c | 7 ++++---
> > >    1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > > index 066dd75..ab72c36 100644
> > > --- a/xen/arch/arm/domain_build.c
> > > +++ b/xen/arch/arm/domain_build.c
> > > @@ -244,7 +244,8 @@ fail:
> > >     * (as described above) we allow higher allocations and continue until
> > >     * that runs out (or we have allocated sufficient dom0 memory).
> > >     */
> > > -static void __init allocate_memory(struct domain *d, struct kernel_info
> > > *kinfo)
> > > +static void __init allocate_memory_11(struct domain *d,
> > > +                                      struct kernel_info *kinfo)
> > >    {
> > >        const unsigned int min_low_order =
> > >            get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
> > > @@ -2240,7 +2241,7 @@ static int __init construct_domU(struct domain *d,
> > > struct dt_device_node *node)
> > >        /* type must be set before allocate memory */
> > >        d->arch.type = kinfo.type;
> > >    #endif
> > > -    allocate_memory(d, &kinfo);
> > > +    allocate_memory_11(d, &kinfo);
> > I don't think your patches are correctly ordered. This is adding a lot of
> > confusion in the review because the DomU memory layout is fixed, yet here you
> > rename the function to 1:1 mapping.
> >
> > Most likely you want to do add the new memory function before introducing
> > DomU.
> If I do that there will be no callers for the new function and
> compilation fails. Bisectibility is the reason why I had to reorder the
> patches.
I understand but I don't want to give the impression that 1:1 mapping is 
used for guests. I can see a couple of solutions:
        - Implement allocate_memory in a static inline/#if 0 #endif.
	- Provide a dummy call for the memory that will be implemented later 
(similar to you do for construct_domU).
Cheers,

--
Julien Grall

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