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 So how about moving MEMZONE_XEN to the last (current NR_ZONES plus 1)? That can ensure domheap covering all possible bits exactly. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> "Tian, Kevin" <kevin.tian@intel.com> 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 exclusivelyZone 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@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Jan Beulich [mailto:jbeulich@novell.com] >Sent: 2007年3月21日 18:29 > >>>> "Tian, Kevin" <kevin.tian@intel.com> 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).Since 0-1Mb (grabbed by dom_io) is not initialized into either xen heap or domain heap, zone 0 will be always null for domain heap even not given to Xen. :-) But yes, now I''m inclined to agree with you no confliction with moving Xen to other place, if anyway MEMZONE_XEN has no implication on bit width while zone 0 is free to use. Thanks, Kevin> >>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@lists.xensource.com http://lists.xensource.com/xen-devel