[parisc-linux] depi?

[John David Anglin]

> 
> John David Anglin wrote:
> > 
> > I think what is being suggested is to run with the space registers all
> > zero and swap the TLB contents on context switches in order to changing
> > the mapping from virtual to physical.  However, I doubt this is efficient.
> 
> This is what I undesrtand now too, at first I though it was flat 4Gb shared
> between the OS and the processes (ala 2Gb each), then space flip enter in
> action with flat 4Gb per threads (pardon proceses for now), and then a flat
> 4Gb for the kernel itself.

The architecture that I proposed was suggested by figure 3-1 of the
Precision Architecture and Instruction Set Manual (1989).  On a level 1
machine there 2**16-1 virtual 4GB spaces.  Thus, each process can
have its own virtual space.  The physical page directory contains
the mapping for the kernel and all processes.  The algorithm for
updating the TLB(s) from the page directory is very important for
efficiency and also for security.

I assume threads will run in a processes virtual space for efficiency.

> I don't really see the implementation of a previous mail of someone saying the
> user VAS quad usage would be TEXT/DATA/SHARED1/SHARE2 if all the SR's are the
> same, I still have some ProtID problem I don't see how efficiently sharing is
> implemented (TEXT/SHARED1/SHARED2). I bet this is adressed, I just don't have
> the design document.

This was me again.  The TEXT/DATA/SHARED1/SHARE2 architecture is described
in the 32-bit PA-RISC Runtime Architecture Document.  It is how hpux 10.20
does it.  Take a look at Table 1, "Space Register Usage".  However, it doesn't
really tell you anything about the OS implementation details.  I do know
that hpux uses different spaces for text and data.  As a result, branches
that cross quadrants must be interspace branches.  The space of the caller
must be saved and restored on return.  If the same space id is used in SR4-SR7
for any given process, then I don't think it would be necessary to save
and restore the instruction space register across calls except for system
calls where the virtual space changes.

The one advantage to reserving the fourth quadrant for the OS is that in
a system call the OS has direct access to the first three quadrants
of the processes address space as well as its own space.  What I am
suggesting here is that the TLB page table mapping for the fourth quadrant
would be more or less the same except for access rights for the kernel
and user processes.  Of course, hardware registers wouldn't be mapped
in process space.  There could be a gateway page that messes with the
mapping to allow the kernel to run at a different location.  But then
I think the system would have a more difficult job in accessing user
virtual space.  Possibly, some special provisions would have to be made
for PDC calls in virtual mode.

I know that there are restrictions using mmap with hpux 10.X.  More or
less, the problem is that you can't put a shared data area where you want
and this causes problems with many apps that assume a more general
implementation.  The system chooses where shared data goes.  This needs
to be looked at in more detail.

SR0 to SR4 can be changed by a non-privileged process.  Thus, access
identities have to be setup properly to prevent a process from flipping
through the virtual address space and doing bad stuff.  The OS must also
be prepared for a process that messes with SR4.  A nasty process might
be able change the space id in SR4 to that of another process or the
kernel, and do a system call that writes to this region.

For PA_RISC 2.0, the architecture is changed for 64-bit operation.  I quote

	"The OS will use a different address space layout for 64-bit processes,
	so we will not be able to specify that main program text is at the
	low end of Quadrant 0, nor will we be able to use absolute addressing
	at all.  This will affect millicode calls, long calls, plabel
	materialization, and non-PIC literal references.

	Compilers must avoid any explicit reference to space registers, so
	there is no need to specify any association between particular
	segments and quadrants of the address space."

Further, the 64-bit architecture defines a single PIC compilation model.
I have to say that the 64-bit document as of Version 3.3 (1997) is vague.

Probably, we should ignore the 64 bit issues and use an architecture
that is good for 32 bit level 1 machines and above.

> ------------------------------------------

> Some may say, linux is not doc, it is hack n run, but on the long run I'm
> affraid that hack n run will type more text (try and fail code) than writing
> the design options. For instance the ASL document for HP-UX wide is 22 pages
> total, with TOC and figures, and pseudo-code algorithm.
> Remember Djikstra (well the old timer may, the bambinos may take Kurt Cobain
> as an example :-) "You should pay the programmers a very good salary, don't
> hesitate to bump their salary, BUT make them pay any puch in their punched
> card" The idea behind, think before code after, Kurt tried it the other way,
> he choose to shoot first and think after oops :-)

Agree totally.

In summary, I think that each process slot should be assigned a unique
space id.  At least initially, the same id would be used for SR4-SR7 in
each process.  Link the OS at 0xc0000000 and go with a 3GB process/1GB OS
virtual address model.  All the physical memory in the machine can 
therefore be used, up to the ~ 4GB limit in the PA 1.X architecture.
I think this model is compatible with the PA 1.1 architecture and hopefully
also the x86 architecture.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)