half-baked and resulted in one superfluous ASID bump if new pmaps
are created when pmap_asid_generation > 0. Need to initialize pmap
fields correctly.
Yet, this possibly might not be the perfect solution. If one
process bumped pmap_asid_generation _after_ a new pmap was created
and initialized with then-current pmap_asid_generation value. In
that case, the new pmap would have another (superfluous) ASID bump
when 2nd (not 1st) CPU tick is assigned. I'm not sure if this case
would happen.
Have pmap_max_asid variable to hold the maximum number of ASID
(TLBpid) supported by processor anticipating the possible runtime
cost of ((CPUISMIPS3)? MIPS3_TLB_NUM_ASIDS : MIPS1_TLB_NUM_PIDS).
ALPHA; mips1_TBIA, mips1_TBIAP, mips1_TBIS.
- Make sure TBIA and TBIAP ops to have an argument for the size of TLB
which varies across even for MIPS1 implementations.
- Nuke the unused cpu_isa field from processor personality list.
- XXX XXX XXX
it's less-than-optimal and likely a mistake to have TLBUpdate().
It's costy to try to invalidate a single TLB entry whenver a certain
PTE is going to be modified by traversing the entire TLB looking
for the modified PTE because the PTE in question is not in TLB in
most cases. ASID bump could do the invalidation smartly. Solution
is planned for now.
was used for debugg'n purposes which only make senses on particular
hardware configurations and has never been intended to extend pagesize
of NetBSD/mips.
* Remove the casts to vaddr_t from the round_page() and trunc_page() macros to
make them type-generic, which is necessary i.e. to operate on file offsets
without truncating them.
* In due course, cast pointer arguments to these macros to an appropriate
integral type (paddr_t, vaddr_t).
Originally done by Chuck Silvers, updated by myself.
(which disables the interrupts) is *not* a good idea. k0 (and k1) is used
by the kernel code such as the TLB miss handler, and the interrupt entry.
If an interrupt occurs after loading k0 and before the SR gets interrupts
disabled, k0 will be clobbered and when used to load the PC on exit from
the exception handler, results in various hangs and crashes.
don't stomp on the return address in k0. Also, don't need to account
for any load delays, as the last register restored (gp) isn't used in
the subsequent instruction.
simonb