1. Acquire use of the signaling and response facility prior to system_reset
Hackaround to #806: "ARCHLVL cpu reset leading to interrupt handling race"
2. refactor: thread safe utility functions
Updates a few utility functions designated/considred MT-Safe by POSIX or most modern implementations (e.g., glibc).
Minor(?) tweak to ARCHLVL command processing: ALWAYS do an initial_cpu_reset on ALL processors *regardless* of whether a new/different ARCHLVL is being set or not (i.e. even when the *same* ARCHLVL is being set again, do an initial_cpu_reset anyway). This ensures an architecture's control registers are always correct and provides an easy (simple) and reliable way to reset all control registers to their initial power-on state whenever needed.
This commit not only resolves issue #94 "ARCHLVL S/370 MAINSIZE issues" but also completes resolution for issue #92 "Changing ARCHLVL does not do sysclear or sysreset clear" as well.
"A bit is set to one regardless of the current architectural mode if its meaning is true. A meaning applies to the current architectural mode unless it is said to apply to a specific architectural mode."
Closes issue #74: "Why do we have z/Arch facilities enabled for ESA/390".
Using the Hercules Virtual Architecture Level facility (archlvl command) to enable/disable ESA/390 and z/Architecture instructions for System/370 mode is cleaner and easier to manage than having to load the HDL S37X.dll instruction module.
Redundant FACILITY_CHECK macro removed from both instruction functions too. Other FACILITY_CHECK macros will be removed from other facility instructions in upcoming commits.
When a facility is disabled we update the opcode table for the instructions to route directly to program check operation exception. When the facility is enabled we restore the opcode table to its original value (route directly to the instruction function). This relieves each instruction function from having to do a separate FACILITY_CHECK each time it is executed allowing the instruction to execute more quickly.
The earlier "Derive actual facility table from each ARCH_DEP's facility table" commit (a2d88f5f05add3bc567ceac3350738a4fd8d2d8a) introduced a serious oversight (bug) that causes z/Arch operating systems to no longer IPL because the "z/Arch installed (available)" facility bit 1 was never getting set for ESA/390 (which is the mode that z/Arch operating systems currently always IPL in).
This commit corrects that oversight/bug.
This is precisely the type of bug the "LARGE Cosmetic: many renames and added comments" commit was designed to uncover (make obvious). Nevertheless I somehow missed this one. Don't ask me how but I did. Luckily though it was detected during a debugging session, thank goodness.