AMD64 Support

[km b]

On 2/14/07, Ernesto Bascon <ebasconp at gmail.com> wrote:

Great!!!
I am a C, C++, some x86 assembler, Java, C# application developer, so,
I have no experience working on kernel development!
If you could "show me the way" from the start, should be perfect for me  :)
Basically ,  porting DragonFly to amd64 platform doesn't involve only
kernel work.
We need to port kernel as well as userland.
I read a mail from 'corecode' that he cleaned up the userland so that
he was able to make buildworld with TARGET_ARCH=amd64 but I couldn't
find the patch. Anyway first we need a kernel in place.
"Well, basically I've only focussed on locore and pmap right now. I have
some header files done, locore.s, and I'm still shuffling files around
between platform/pc64 and cpu/x86_64. I think that once the layout of
KVA and the pmap code are reasonably done, the rest of the kernel side
can be worked on.
If you are familiar with the FreeBSD booting process then the file
locore.s contains the code which is a starting point from loader to
the real kernel. In FreeBSD locore.s sets up bootstack and calls
hammer_stack (sys/amd64/amd64/machdep.c) which is a machine dependent
initialization and then it calls mi_startup(sys/kern/init_main.c)
which mounts root file system and creates process 0.  The pmap.c code
is machine dependent interface to the memory management unit. The
machine independent (virtual memory subsystem) code is in
/usr/src/sys/vm directory.
As far as the VA space is concerned, I am thinking that we shouldn't
reserve the entire upper half of usable VA space (the 256 uppermost
entries in the PML4 that's active), because I don't want to consume too
much memory for the kernel, even though the usable VA space is (way)
larger than the usable PA space. I don't think the kernel will ever need
the full 128TiB the upper half of usable VA space maps; Whereas it is
currently hard to imagine DFly ever running on machines with such
amounts of RAM, I don't see it impossible in the future; and I'd rather
have userland apps be able to consume >128TiB of memory, than the kernel
having 128TiB which it won't ever use. Ofcourse, given the limitations
in the current x86_64 implementations regarding PA space, that's not
really realistic right now, but I guess you got my point."
</Thomas>
I think we should follow the Matt's design for the same. Read the
following post from Matt.
http://leaf.dragonflybsd.org/mailarchive/commits/2004-02/msg00011.html
Cheers
kmb
--
Something is wrong up on cloud # 9!