[head tinderbox] build report (i386)

Matthew Dillon dillon at apollo.backplane.com
Fri Nov 7 20:02:23 PST 2003


:
:On Nov 7, 2003, at 5:34 PM, Matthew Dillon wrote:
:>     The kernel's going to be broken for a bit if PNPBIOS is
:>     defined.  I am bringing in a bunch of infrastructure from
:>     FreeBSD-5.x.
:
:
:Let me know if you need me to test anything. I'm anxiously
:awaiting to boot into long mode with a DF kernel. :-) I've also
:got a lot of free time now that I've got a few more important
:pieces of the claims processing system HIPPA compliant.
:
:-DR

    This is interesting enough that I am going to post it to the kernel
    list.

    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.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>





More information about the Kernel mailing list