Mailing List Archive

[Xen-devel] x86-64's __PAGE_OFFSET
What, if any, is the reason for x86-64 xenlinux to have a different
__PAGE_OFFSET value than native? While merging, it would seem reasonable
to drop this difference if not motivated technically.

Thanks, Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
RE: [Xen-devel] x86-64's __PAGE_OFFSET [ In reply to ]
Jan Beulich wrote:
>>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 06.01.06 15:10:13 >>>
>>
>> On 6 Jan 2006, at 13:50, Jan Beulich wrote:
>>
>>> What, if any, is the reason for x86-64 xenlinux to have a different
>>> __PAGE_OFFSET value than native? While merging, it would seem
>>> reasonable to drop this difference if not motivated technically.
>>
>> Jun might remember if there was a particular reason, but I can't
>> think
>
>> of any insurmountable technical reason why the native __PAGE_OFFSET
>> value shouldn't work.
>
> There must be a reason - the system dies immediately with that change.
> But I'd really like to understand why this is so, perhaps to check
> with Andi whether then we couldn't generally go with the Xen value...
>
> Jan

__PAGE_OFFSET for the native 0xffff810000000000UL has a conflict with
Xen's address map (xen/include/asm-x86/config.h):

* 0xffff810000000000 - 0xffff817fffffffff [512GB, 2^39 bytes,
PML4:258]
* Guest linear page table.
* 0xffff818000000000 - 0xffff81ffffffffff [512GB, 2^39 bytes,
PML4:259]
* Shadow linear page table.
* 0xffff820000000000 - 0xffff827fffffffff [512GB, 2^39 bytes,
PML4:260]
* Per-domain mappings (e.g., GDT, LDT).
* 0xffff828000000000 - 0xffff8283ffffffff [16GB, 2^34 bytes,
PML4:261]
* Machine-to-phys translation table.
* 0xffff828400000000 - 0xffff8287ffffffff [16GB, 2^34 bytes,
PML4:261]
* Page-frame information array.
* 0xffff828800000000 - 0xffff828bffffffff [16GB, 2^34 bytes,
PML4:261]
* ioremap()/fixmap area.
* 0xffff828c00000000 - 0xffff82ffffffffff [464GB,
PML4:261]
* Reserved for future use.
* 0xffff830000000000 - 0xffff83ffffffffff [1TB, 2^40 bytes,
PML4:262-263]
* 1:1 direct mapping of all physical memory. Xen and its heap live
here.
* 0xffff840000000000 - 0xffff87ffffffffff [4TB, 2^42 bytes,
PML4:264-271]
* Reserved for future use.
* 0xffff880000000000 - 0xffffffffffffffff [120TB, PML4:272-511]
* Guest-defined use.

So 0xffff880000000000UL was chosen for __PAGE_OFFSET in XenLinux.

Jun
---
Intel Open Source Technology Center

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Re: [Xen-devel] x86-64's __PAGE_OFFSET [ In reply to ]
On 7 Jan 2006, at 05:22, Nakajima, Jun wrote:

>>> Jun might remember if there was a particular reason, but I can't
>>> think
>>
>>> of any insurmountable technical reason why the native __PAGE_OFFSET
>>> value shouldn't work.
>>
>> There must be a reason - the system dies immediately with that change.
>> But I'd really like to understand why this is so, perhaps to check
>> with Andi whether then we couldn't generally go with the Xen value...
>>
>> Jan
>
> __PAGE_OFFSET for the native 0xffff810000000000UL has a conflict with
> Xen's address map (xen/include/asm-x86/config.h):

Well, that is a good reason for the modified __PAGE_OFFSET. :-)

I guess we stick with a Xen-specific value then.

-- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel