Improved locking (not that we actually use it on a uniprocessor, but one day :)
Removed unneeded splvm's
tweaked pmap_clean_page code to only flush the cache if the page is mapped in the current pmap (based on diff from richard E)
Adopted pv entry allocation mechanism from i386.
Laid framework for returning ptp's when we've finished with them rather than holding onto them till the process exits.
ptp's are now allocated with a uvm object for the pmap, means that we can walk a list to free them off in pmap_release, until they get freed off by pmap_remove.
Also implemented a page zeroing function when the processor is idling. Note that hpcarm may wish to disable this.
I believe this code to be stable, if anyone has any problems please shout up.
Note that I've some ideas in the works on how to improve the pv handling, so the slow down is short term only.
Also added non-advertising licence and copyright to myself and richard.
Update some of the functions that use pmap_pte to pmap_map_ptes.
Note that there's a dummy macro for pmap_unmap_ptes, this is because at some point locking will be needed, so we need to be able to unlock them.
Performance gain seems to be minimal, however long term it should help improve things.
This is similair to the i386 pmap_map_ptes, however it's based on a version from Richard Earnshaw.
in arm/arm. This version is based on the arm26 version, and includes dumping
the contents of stack frames, with automatic determination of the save code
pointer offset.
- pmap_enter()
- pmap_remove()
- pmap_protect()
- pmap_kenter_pa()
- pmap_kremove()
as described in pmap(9).
These calls are relatively conservative. It may be possible to
optimize these a little more.
always points to the undefined instruction in question. It's up to the
handler to advance it to the next instruction if it wants execution to
continue there. This is how things have always worked on arm26.
co-processor. This is necessary so we can have several handlers for
CP0 (used as a catch-all for non-CP instructions).
Handlers are now removed using remove_coproc_handler(), rather than by calling
install_coproc_handler() with a NULL handler.
Because install_coproc_handler() can now allocate memory, there's a version
for use at boot time that doesn't.
chris