Re:PMode in Boot Loader
Posted: Wed Mar 30, 2005 3:38 am
Hi,
Due to this gradually increasing number of bits I expect everything above 0xC000000000000000 will end up being considered as "kernel space". This "unusual" address comes from theoretical 63 bit linear addressing, where there'd be a hole from 0x4000000000000000 to 0xC000000000000000. The final step to full 64 bit removes the hole, and therefore removes the need to distinguish between memory areas above and below the hole.
As for my OS, the second stage boot loader (16 bit setup code) does check if all CPUs support 64 bit. If they do it will search the boot image for some 64 bit setup code, a 64 bit kernel setup driver and a suitable 64 bit kernel. If it finds all three the second stage boot loader will start a 64 bit boot using these components. Unfortunately none of these 64 bit components exist, so the 16 bit setup code defaults to 32 bit components instead.
The general idea is that I can write the 64 bit setup code, a 64 bit kernel setup driver and a 64 bit kernels in the future without modifying any of the first or second stage boot code, and a boot image can be created that will automatically select the most appropriate code to boot.
I've made sure that common data structures used during boot reserve space for 64 bit addressing. Also, my physical memory manager does handle 64 bit addressing (this was needed for PAE support anyway). I've also prevented user level code from using any addresses in kernel space (unlike the previous version of the OS, where certain kernel data structures could be read from directly). This is so 32 bit code will be able to access up to 4 Gb of linear space when run under the future 64 bit version of the OS.
I guess you could say I've done everything possible to make it easy to port the OS to 64 bit, without doing any 64 bit code - if anyone wants to send me a computer that supports 64 bit I'll be happy to provide a postal address ;D.
Cheers,
Brendan
I'd suggest that 0xFFFFFF8000000000 is "above 0x8000000000000000", if you consider the linear address as an unsigned number (which is something of a habit). I expect CPU manufacturers will increase the number of bits used for virtual addressing until (eventually) we end up with fully 64 bit CPUs (without a hole in the middle of the linear address space).Candy wrote:*cough* AMD64 and EM64T both have only 48 bits of actual address space. So, your pointers become 0x0000000100000000, 0xFFFFFF8000000000 and 0xFFFFFF8000000000. I thought your OS did 64-bit already?Brendan wrote: - if you ever want to support 64 bit (long mode) you may want legacy 32 bit applications to have up to 4 Gb of space (up to 0x0000000100000000), with the kernel above 0x8000000000000000. In this case the 32 bit/legacy software will need to be designed to use lower addresses. You can't do the reverse, with the kernel at lower address and legacy 32 bit software above 0x8000000000000000.
Due to this gradually increasing number of bits I expect everything above 0xC000000000000000 will end up being considered as "kernel space". This "unusual" address comes from theoretical 63 bit linear addressing, where there'd be a hole from 0x4000000000000000 to 0xC000000000000000. The final step to full 64 bit removes the hole, and therefore removes the need to distinguish between memory areas above and below the hole.
As for my OS, the second stage boot loader (16 bit setup code) does check if all CPUs support 64 bit. If they do it will search the boot image for some 64 bit setup code, a 64 bit kernel setup driver and a suitable 64 bit kernel. If it finds all three the second stage boot loader will start a 64 bit boot using these components. Unfortunately none of these 64 bit components exist, so the 16 bit setup code defaults to 32 bit components instead.
The general idea is that I can write the 64 bit setup code, a 64 bit kernel setup driver and a 64 bit kernels in the future without modifying any of the first or second stage boot code, and a boot image can be created that will automatically select the most appropriate code to boot.
I've made sure that common data structures used during boot reserve space for 64 bit addressing. Also, my physical memory manager does handle 64 bit addressing (this was needed for PAE support anyway). I've also prevented user level code from using any addresses in kernel space (unlike the previous version of the OS, where certain kernel data structures could be read from directly). This is so 32 bit code will be able to access up to 4 Gb of linear space when run under the future 64 bit version of the OS.
I guess you could say I've done everything possible to make it easy to port the OS to 64 bit, without doing any 64 bit code - if anyone wants to send me a computer that supports 64 bit I'll be happy to provide a postal address ;D.
Cheers,
Brendan