true, all mappings have been removed, the pmap is totally cleared out, and
UVM can then avoid doing the work to call pmap_remove() for each map entry.
If false, either nothing has been done, or some helpful arch-specific voodoo
has taken place.
check from a (soft) interrupt handler. But if a platform does not otherwise
require the pmap_tlb_miss_lock, then where will be a brief window of
inconsistency that, while harmless, will still fire an assertion in the
consistency check.
Fix this with the following changes:
1- Refactor the pmap_tlb_miss_lock into MI code and rename it from
pmap_tlb_miss_lock_{enter,exit}() to pmap_tlb_miss_lock_{enter,exit}().
MD code can still define the "md" hooks as necessary, and if so, will
override the common implementation.
2- Provde a pmap_bootstrap_common() function to perform common pmap bootstrap
operations, namely initializing the pmap_tlb_miss_lock if it's needed.
If MD code overrides the implementation, it's responsible for initializing
its own lock.
3- Call pmap_bootstrap_common() from the mips, powerpc booke, and riscv
pmap_bootstrap() routines. (This required adding one for riscv.)
4- Switch powerpc booke to the common pmap_tlb_miss_lock.
5- Enable pmap_tlb_miss_lock if DEBUG is defined, even if it's not otherwise
required.
PR port-mips/55062 (Failed assertion in pmap_md_tlb_check_entry())
that TLBINFO_ASID_INUSE_P() returns just 0 or 1; the underlying
__BITMAP_ISSET() actually returns the matching bit nowadays, which
caused miscounting
fixes PR kern/53054 by Sevan Janiyan
KERNEL_PID> to avoid triggering KASSERT() checking allocated asid
is bigger than KERNEL_PID; adjust also TLBINFO_ASID_INITIAL_FREE()
accordingly
discussed with Nick
it possible to override the ASID bitmap length; default to 256 ASIDs as before
XXX NFCI; compile tested only on evbpcc and evbmips, unfortunately didn't
find any combination of port using the MI pmap_tlb.c and working in QEMU
in PR kern/52639, as well as some general cleaning-up...
(As proposed on tech-kern@ with additional changes and enhancements.)
Details of changes:
* All history arguments are now stored as uintmax_t values[1], both in
the kernel and in the structures used for exporting the history data
to userland via sysctl(9). This avoids problems on some architectures
where passing a 64-bit (or larger) value to printf(3) can cause it to
process the value as multiple arguments. (This can be particularly
problematic when printf()'s format string is not a literal, since in
that case the compiler cannot know how large each argument should be.)
* Update the data structures used for exporting kernel history data to
include a version number as well as the length of history arguments.
* All [2] existing users of kernhist(9) have had their format strings
updated. Each format specifier now includes an explicit length
modifier 'j' to refer to numeric values of the size of uintmax_t.
* All [2] existing users of kernhist(9) have had their format strings
updated to replace uses of "%p" with "%#jx", and the pointer
arguments are now cast to (uintptr_t) before being subsequently cast
to (uintmax_t). This is needed to avoid compiler warnings about
casting "pointer to integer of a different size."
* All [2] existing users of kernhist(9) have had instances of "%s" or
"%c" format strings replaced with numeric formats; several instances
of mis-match between format string and argument list have been fixed.
* vmstat(1) has been modified to handle the new size of arguments in the
history data as exported by sysctl(9).
* vmstat(1) now provides a warning message if the history requested with
the -u option does not exist (previously, this condition was silently
ignored, with only a single blank line being printed).
* vmstat(1) now checks the version and argument length included in the
data exported via sysctl(9) and exits if they do not match the values
with which vmstat was built.
* The kernhist(9) man-page has been updated to note the additional
requirements imposed on the format strings, along with several other
minor changes and enhancements.
[1] It would have been possible to use an explicit length (for example,
uint64_t) for the history arguments. But that would require another
"rototill" of all the users in the future when we add support for an
architecture that supports a larger size. Also, the printf(3) format
specifiers for explicitly-sized values, such as "%"PRIu64, are much
more verbose (and less aesthetically appealing, IMHO) than simply
using "%ju".
[2] I've tried very hard to find "all [the] existing users of kernhist(9)"
but it is possible that I've missed some of them. I would be glad to
update any stragglers that anyone identifies.
