Matt Dillon posted an interesting bit about what’s needed/planned for non-emulated use of the AMD64:

(post quoted)

” It’s going to be a while before we can actually boot into long
mode, but not too long. I am guessing a month or two. The work
is as follows:

• import the long capable boot loader from FreeBSD-5.
• bring gcc 3.x in as an alternative compiler
• setup for cross compilation
• the actual code work to convert i386 to amd64 {
  • adjust register frames and all related code
  • adjust page table entity sizes (PAE-like)
  • rework the MMU mappings
  • 32 bit emulation (define additional selectors)
  • 32 bit syscall support (isn’t it nice that
    David has made so much progress on the syscall separation
    code!).

  }

Apart from the wider regs and the fact that there are more of them,
the main issue is going to be the MMU. The MMU is 4 layers deep and
entries are 64 bits wide instead of 32. But AMD is still using 4K
pages so it makes for a weird layering breakdown:

PML4 Represents 512GB per entry (x512 entries) (256TB total)
PDP Represents 1GB per entry (x512 entries)
PDE Represents 2MB per entry (x512 entries)
PTE Represents 4KB per entry (x512 entries)

I intend to create a per-cpu PML4 table, essentially making it ‘fixed’
and therefore a NOP from a programming standpoint. Each cpu will get its
own. The current process’s page table will be one entry in the PML4
table. The per-cpu data area will be another entry (we will be able to
do away with the %fs prefix code, which is nice!), A 1:1 physical memory
map will be another entry, and KVM will be another entry.

Each user process (well, pmap) will have at least one PDP table (at least
until it needs more then 512G of address space), with at least 4 PDE
table entries covering program, text, stack, etc.”