[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |