| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home