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

Re: [Xen-devel] [PATCH v2 9/9] xen: support RAM at addresses 0 and 4096



On Fri, 2013-09-13 at 12:57 +0100, Jan Beulich wrote:
> >>> On 13.09.13 at 13:40, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
> > --- a/xen/common/page_alloc.c
> > +++ b/xen/common/page_alloc.c
> > @@ -257,11 +257,11 @@ unsigned long __init alloc_boot_pages(
> >   */
> >  
> >  #define MEMZONE_XEN 0
> > -#define NR_ZONES    (PADDR_BITS - PAGE_SHIFT)
> > +#define NR_ZONES    (PADDR_BITS - PAGE_SHIFT + 1)
> >  
> > -#define bits_to_zone(b) (((b) < (PAGE_SHIFT + 1)) ? 0 : ((b) - PAGE_SHIFT 
> > - 1))
> > +#define bits_to_zone(b) (((b) < (PAGE_SHIFT + 1)) ? 1 : ((b) - PAGE_SHIFT))
> >  #define page_to_zone(pg) (is_xen_heap_page(pg) ? MEMZONE_XEN :  \
> > -                          (fls(page_to_mfn(pg)) - 1))
> > +                          (fls(page_to_mfn(pg)) ? : 1))
> 
> So this puts both $subject pages into zone 1. If that's intended,
> and you verified that it's consistent (namely in that zone 1 now
> will have twice as many pages as one would expect),

Yes, they both end up in zone 1, I figured it was a minor quirk which
was unlikely to make any difference in practice.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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