Re: Segments

[ws%tools.de@localhost (Wolfgang Solfrank)]

Hi,

> I'm confused. I am puzzled by how segments are handled, the translation
> which happens based on the upper nibble (4 bits) of the virtual address. I
> think you're describing the BAT, the Block address translation if I got
> the term right. They seem to cover large blocks of memory. They are, also,
> one of the few things that make sense about PPC memory. :-)

To the latter I can 100% agree :-)

Yes, you are right, I was talking about the BATs.  So let's talk about the
SRs:

> I thought we had 16 segment registers, one per VA nibble.

Correct.

The idea behind these SRs seems to be that you can easily share a 256 MB
region between processes by using the same SR contents.  This isn't used
in NetBSD/powerpc except for the mapping of user space into kernel virtual
space during a copyin/copyout operation (see previous mail for a more
detailed description).

> I'll refine the question a bit. How are the mappings set up for a user
> process, and for a kernel process (well, a process running in the kernel -
> could be in a system call, etc)?

Hmm, this sounds like you are not aware that the kernel does have only one
address space on all NetBSD implementations (well, to be honest, early
versions had different mappings for the user area, as any process had its
stack at the same address.  For most of the ports (including NetBSD/powerpc
from the beginning) this is no longer the case).  That is, kernel code sees
the same address space for all processes (again see previous mail for
a description of this kernel virtual address space).

The user space:

> How does the 4GB virtual space look to a user process? Does it notice the
> fact that it is made up of 16 256-MB segments?

No, the segmenting of the address space isn't visible to the user processes.
For a user process, the address space looks like this:

Initially the area from 0 to 0x1000 is normally unmapped (but may be mapped
by the user if he wishes).  The code starts at address 0x1000.  As with most
U*X like OSs, the data area is beyond the text (code) area, and the stack
grows from the maximum possible address downward.  As the address has to be
represented by a 32-bit number, the top of memory cannot be 0x100000000 and
would have to be 0, but that confuses the VM system.  Therefor the top of
memory is currently limited to 0xfffff000, i.e. one page below the full
4GB address space.

The current maximum sizes for the various areas is 16MB for the text,
512MB for data and 32MB for the stack, but they can easily be changed by
recompiling the kernel.

Hope this helps.

Ciao,
Wolfgang
-- 
ws%TooLs.DE@localhost     (Wolfgang Solfrank, TooLs GmbH)       +49-228-985800