* Map the message buffer with access_type = VM_PROT_READ|VM_PROT_WRITE `just
because'.
* Map the file system buffers with access_type = VM_PROT_READ|VM_PROT_WRITE to
avoid possible problems with pagemove().
* Do not use VM_PROT_EXEC with either of the above.
* Map pages for /dev/mem with access_type = prot. Also, DO NOT use
pmap_kenter() for this, as we DO NOT want to lose modification information.
* Map pages in dumpsys() with VM_PROT_READ.
* Map pages in m68k mappedcopyin()/mappedcopyout() and writeback() with
access_type = prot.
* For now, bus_dma*(), pmap_map(), vmapbuf(), and similar functions still use
access_type = 0. This should probably be revisited.
allocated from a pool, and the MIPS and Alpha use KSEG to map pool
pages. So, mb_map wasn't actually being used. Saves around 4MB of
kernel virtual address space in a typical configuration.
Garbage-collect the related VM_MBUF_SIZE constant.
pointer to just underneath _start. Allows bootblocks (or other kernel
calling programs) to pass more than 4 arguments if it sets up the stack
properly.
The 4kB figure may be overkill - on the pmax it only needs to be a dozen
of so bytes.
tlbmod exception panics. This appears to have been incorrect even in the pica
pmap.c, which I pulled in for the pmax. Fixes Xcfbpmax crashes on R40x0
systems with sfb framebuffer.
Fix resident_count tracking so it doesn't go negative. UVM will change a
page mapping without removing the original mapping. That was causing a
problem early on when getting UVM working on the mips, and the explicit
pmap_remove() done by pmap_enter() was decrementing the resident_count.
Do the pmap_remove() first, then check if the current mapping is not valid
and increment the resident_count.
the *initial* stack pointer. The proc0 stack is being used by proc0 (i.e.
uvm_scheduler). This had been working because switch_exit() wasn't
overwriting any critical areas of the stack - unless kernel profiling
was turned on.
on 64 bit register that's not correctly signed extended. The R4x00 support
works again on DECstations. A similar change to the XTLBMiss handler probably
needs to be made, but I have not done that since I am unable to test any
changes to that.
Also re-order a couple of instructions to allow for delay with mfc0.
simonb