Omit needless membar in pmap_kenter_pa while here -- caller must
ensure pmap_kenter_pa on one CPU happens before use of the VA on
another CPU anyway, so there is no benefit to a membar here.
ok thorpej@
- exception_return(): Use GET_CURLWP directly, rather than a dance
acount GET_CPUINFO.
- Introduce SET_CURLWP(), to set the curlwp value.
- Garbage-collect GET_FPCURLWP.
PROM console routines are being used (only on KN8AE). We have access to
the sam information via curlwp, so use that, and eliminate the need to set
cpu_info::ci_curpcb when context switching, which saves an extra all into
PALcode.
reads 0. Issue a memory barrier between the atomic swap and performing
the work.
- alpha_send_ipi(): Issue a memory barrier before setting the ipimask
to ensure all memory accesses prior to signalling the IPI have
completed. Also issue a memory barrier getween setting the ipimask
and calling PALcode to write the IPIR.
exceptions on QNaNs.
- alpha_fp_interpret(): Instructions are 32-bits wide, so don't use a
uint64_t to contain them.
- alpha_fp_complete(): Operations on NaNs trap on Alpha, but the exception
summary reports INV (invalid operation) rather than SWC (software
completion) in this case. So also interpret the instruction if INV
is set in the exception summary. This will emulate operations on
NaN and correctly suppress FP traps for QNaNs.
This fixes bin/55633, which was caused by:
-> Input string "nanotime" is passed to awk's internal is_number().
-> strtod() interprets as "nan" and returns QNaN as the result.
-> Result compared against HUGE_VAL, blows up because cmptle is called
with a NaN operand, and the hardware doesn't care that it's quiet.
inside Qemu by consulting the system serial number, and quickly abort
calls into the PROM if we are.
This is a temporary measure until I can figure out why calling into
the Qemu PROM interface blows up.
function. Call in from pmap_bootstrap() for the boot CPU, and
from cpu_hatch() for secondaary CPUs.
- Eliminiate the dedicated I-stream memory barrier IPI; handle it all from
the TLB shootdown IPI. Const poison, and add some additional memory
barriers and a TBIA to the PAUSE IPI.
- Completly rewrite TLB management in the alpha pmap module, borrowing
somoe ideas from the x86 pmap and adapting them to the alpha environment.
See the comments for theory of operation. Add a bunch of stats that
can be reported (disabled by default).
- Add some additional symbol decorations to improve cache behavior on
MP systems. Ensure coherency unit alignment for several structures
in the pmap module. Use hashed locks for pmap structures.
- Start out all new processes on the kernel page tables until their
first trip though pmap_activate() to avoid the potential of polluting
the current ASN in TLB with cross-process mappings.
comment explaining why we don't need to act on IDLE+REMOTE.
- cpu_signotify(): Move to machdep.c, and if we're asked to notify
an LWP running on another CPU, send an AST IPI to that CPU. Add some
assertions.
- cpu_need_proftick(): Move to machdep.c, add some assertions.
a mutex twice, and that upsets LOCKDEBUG. But instead of seeing a
proper message about it, the output happens before the PROM console
interfcace is initialized, we would end up with a translation fault
back into SRM.
pmap_activate(). As of rev 1.211, the pmap::pm_lev1map field is
stable across the life of the pmap, and so the conditino that
the change in 1.264 was intended to avoid would not have happened
anyway.
- Explicitly use __cacheline_aligned / COHERENCY_UNIT rather than 64
in a couple of places.
- Update comments around the lev1map lifecycle, and add some assertions
to enforce the assumptions being described.
- Remove some dubious DEBUG tests that are not MP-safe.
- Chage some long-form #ifdef DIAGNOSTIC checks / panics to KASSERTs.
- Remove the PMAP_ACTIVATE() macro because it's no longer used anywhere
except for pmap_activate(). Just open-code the equivalent there.
- In pmap_activate(), only perform the SWPCTX if either the PTBR or the
ASN are different than what the PCB already has. Also assert that
preemption is disabled and that the specified lwp is curlwp.
- In pmap_deactivate(), add similar assertions, and add a comment explaining
why a SWPCTX to get off of the deactivated lev1map is not necessaray.
- Refactor some duplicated code in pmap_growkernel() into a new
pmap_kptpage_alloc() function.
- In pmap_growkernel(), assert that any user pmap published on the all-pmaps
list does not reference the kernel_lev1map.
- In pmap_asn_alloc(), get out early if we're called with the kernel pmap,
since all kernel mappings are ASM. Remove bogus assertions around the
value of pmap::pm_lev1map and the current ASN, and simply assert that
pmap::pm_lev1map is never kernel_lev1map. Also assert that preemption
is disabled, since we're manipulating per-cpu data structures.
- Convert the "too much uptime" panic to a simple KASSERT, and update the
comment to reflect that we're only subject to the longer 75 billion year
ASN generation overflow (because CPUs that don't implement ASNs never go
through this code path).
the lev1map associated with l2's pmap. Otherwise, the first time we
SWPCTX to l2, we'll be on l1's page tables until the first pmap_activate()
call for l2.
architectures.
Notes:
- On alpha and ia64 the function is kept but gets renamed locally to avoid
symbol collision. This is because on these two arches, I am not sure
whether the ASM callers do not rely on fixed registers, so I prefer to
keep the ASM body for now.
- On Vax, only the symbol is removed, because the body is used from other
functions.
- On RISC-V, this change fixes a bug: copystr() was just a wrapper around
strlcpy(), but strlcpy() makes the operation less safe (strlen on the
source beyond its size).
- The kASan, kCSan and kMSan wrappers are removed, because now that
copystr() is in C, the compiler transformations are applied to it,
without the need for manual wrappers.
Could test on amd64 only, but should be fine.
cached value will do, or if the very latest total must be fetched. It can
be called thousands of times a second and fetching the totals impacts not
only the calling LWP but other CPUs doing unrelated activity in the VM
system.
