[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86: fix comment on super page alignment requirement



On Mon, Sep 24, 2018 at 05:19:12AM -0600, Jan Beulich wrote:
> >>> On 24.09.18 at 12:38, <wei.liu2@xxxxxxxxxx> wrote:
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -944,12 +944,13 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >  
> >      /*
> >       * Iterate backwards over all superpage-aligned RAM regions.
> > -     * 
> > -     * We require superpage alignment because the boot allocator is not yet
> > -     * initialised. Hence we can only map superpages in the address range
> > -     * 0 to BOOTSTRAP_DIRECTMAP_END, as this is guaranteed not to require
> > +     *
> > +     * We require superpage alignment because the boot allocator is
> > +     * not yet initialised. Hence we can only map superpages in the
> > +     * address range BOOTSTRAP_MAP_BASE to (BOOTSTRAP_MAP_BASE +
> > +     * BOOTSTRAP_MAP_LIMIT), as this is guaranteed not to require
> 
> The upper bound is not a sum. But there's then also an apparent
> disconnect: BOOTSTRAP_MAP_LIMIT !=
> (ARRAY_SIZE(l2_identmap) << L2_PAGETABLE_SHIFT) afaict, yet
> the latter is what is used for mapping (and what matches the value
> of BOOTSTRAP_DIRECTMAP_END in 4.0.4).

Yeah, I got a few surprises while reading that code. I'm trying to
figure out what the limit should be at the moment.

After playing with early boot code for a few hours, I'm sure that not
all of the three models described in common/page_alloc.c work.

> 
> Also, since you're touching almost the entire comment anyway,
> would you mind moving it down to where it belongs (immediately
> ahead of the for())? Over time more and more things got placed
> between the two.

Will do.

Wei.

> 
> Jan
> 
> 

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.