>>> "Tian, Kevin" <kevin.tian@xxxxxxxxx> 21.03.07 06:56 >>>
>Zone index for domain heap is derived from bits, while zone index for 
>xen heap takes 0 to catch all. This looks a bit messed which prevents 
>future extension. For example, if Xen can be located at higher memory:
> - The assumption that domheap starts from MEMZONE_XEN+1 
>doesn't hold true
> - The memory within the very bit but out of xenheap can't be 
>claimed by domheap since that bit belongs to xenheap exclusively
Zone 0 has no implications on bit width - the only thing it prevents is
allocating page zero through the domain heap allocator), which
clearly must never be allowed (as pfn/mfn zero is used as error
condition in various places). I also can't see why it would conflict
with moving Xen out of (relatively) low memory (a plan I also had for
a while, bt didn't get to so far).
>So how about moving MEMZONE_XEN to the last 
>(current NR_ZONES plus 1)? That can ensure domheap covering all
>possible bits exactly. 
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel