Page 2 of 2

Re: Avoid relocation issues with segmentation

Posted: Tue Mar 17, 2009 11:45 am
by Brynet-Inc
johnsa wrote:Yes... I know they "do" support 64bit code.. but the question was more a case of.. how well, is it solid enough under qemu/bochs to really test with.
Well, 64-bit versions of several popular operating systems appear to work well.. even on 32-bit hosts.

http://www.nongnu.org/qemu/status.html

A new version of qemu is out now as well, haven't tried it yet though..

Re: Avoid relocation issues with segmentation

Posted: Wed Mar 18, 2009 6:18 am
by johnsa
Hey,

So moving ahead with 64bit kernel model.. what is the best way to address the higher-half linking model? fixing the kernel at 3gig seems silly given that the limit of 4gig is now removed.. Would it be best to link the kernel now at 0 and allow the user app to be fixed at say 2gig+ so that it could take advantage of the full available memory in a linear fashion without having to page around the kernel in the middle?

Re: Avoid relocation issues with segmentation

Posted: Wed Mar 18, 2009 7:21 am
by Hyperdrive
johnsa wrote:So moving ahead with 64bit kernel model.. what is the best way to address the higher-half linking model? fixing the kernel at 3gig seems silly given that the limit of 4gig is now removed.. Would it be best to link the kernel now at 0 and allow the user app to be fixed at say 2gig+ so that it could take advantage of the full available memory in a linear fashion without having to page around the kernel in the middle?
What about for example giving 0x0000000000000000 - 0x00007FFFFFFFFFFF to user applications and 0xFFFF800000000000 - 0xFFFFFFFFFFFFFFFF for kernel space (assuming the current 48 bit implementation)?

--TS

Re: Avoid relocation issues with segmentation

Posted: Wed Mar 18, 2009 7:32 am
by johnsa
I guess that would be a reasonably long term solution :)
So half of the entire 64bit address space for user process, and half for kernel.
So the kernel code would always be linked to 0xFFFF800000000000 ...

Re: Avoid relocation issues with segmentation

Posted: Wed Mar 18, 2009 7:39 am
by Brendan
Hi,
johnsa wrote:So moving ahead with 64bit kernel model.. what is the best way to address the higher-half linking model? fixing the kernel at 3gig seems silly given that the limit of 4gig is now removed.. Would it be best to link the kernel now at 0 and allow the user app to be fixed at say 2gig+ so that it could take advantage of the full available memory in a linear fashion without having to page around the kernel in the middle?
IMHO for both 32-bit OSs and 64-bit OSs, it's best to setup paging (and map whatever physical pages the kernel happens to be loaded at into the correct linear addresses the kernel needs) before the kernel itself is started.

Also note that for 64-bit, the virtual address space has a huge hole in the middle. For example:

Code: Select all

0x0000000000000000 to 0x00007FFFFFFFFFFF = usable space
0x0000800000000000 to 0xFFFF7FFFFFFFFFFF = unusable (non-canonical)
0xFFFF800000000000 to 0xFFFFFFFFFFFFFFFF = usable space
This is because 64-bit virtual addresses are actually 48-bit addresses that are sign extended.

Eventually someone (Intel or AMD) will introduce a new method of doing paging in long mode, where the virtual addresses space is larger (e.g. 56-bit virtual addresses that are sign extended, or even maybe true 64-bit virtual addresses that aren't sign extended). This probably won't happen for a long time, but when it does happen, hopefully you'll only need to change your paging code to support it (and won't need to break compatibility with existing applications).

If some future extension adds support for 63-bit virtual addresses, then you'd have this:

Code: Select all

0x0000000000000000 to 0x3FFFFFFFFFFFFFFF = usable space
0x4000000000000000 to 0xBFFFFFFFFFFFFFFF = unusable (non-canonical)
0xC000000000000000 to 0xFFFFFFFFFFFFFFFF = usable space
And if/when support for true 64-bit virtual addresses is implemented, you'd have this:

Code: Select all

0x0000000000000000 to 0xFFFFFFFFFFFFFFFF = usable space
This means that regardless of what happens in the future, you could use the virtual address space like this:

Code: Select all

0x0000000000000000 to 0x00007FFFFFFFFFFF = guaranteed usable "user space"
0x0000800000000000 to 0xBFFFFFFFFFFFFFFF = potentially usable "user space" (depends on future extensions)
0xC000000000000000 to 0xFFFF7FFFFFFFFFFF = potentially usable "kernel space" (depends on future extensions)
0xFFFF800000000000 to 0xFFFFFFFFFFFFFFFF = guaranteed usable "kernel space"
Basically, what I'm trying to say is that it may be best to map the kernel high in kernel space (e.g. at 0xFFFFFFFFFFC00000) and use the space below that (e.g. from 0xFFFF800000000000 to 0xFFFFFFFFFFBFFFF) as dynamically allocated space (e.g. the kernel heap); so that in future (if/when paging is extended) you can still have the kernel at the same place and still use the space below the kernel (e.g. from "address that depends on which features the CPU supports" to 0xFFFFFFFFFFBFFFF) as dynamically allocated space.

The same applies to applications. At the moment applications would get the area from 0x0000000000000000 to 0x00007FFFFFFFFFFF, but if/when paging is extended they'd get the area from 0x0000000000000000 to "address that depends on which features the CPU supports".


Cheers,

Brendan