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

RE: [Xen-devel] Move MEMZONE_XEN to the last



>From: Jan Beulich [mailto:jbeulich@xxxxxxxxxx]
>Sent: 2007年3月21日 18:29
>
>>>> "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).

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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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