A few back-channel communiques (rather bluntly) reminded me that I did not provide an entirely complete explanation of how this all works. As I said, "It's tricky." So, I tended to gloss over the details. What follows is a more detailed explanation.
Beginning with the z196, IBM introduced hardware facilities in support of z/VM's live-guest relocation. These facilities are not documented in the PoO or any other IBM-published document, however many of the details can be found in patent application US 2011-0320793 A1 and patent US 9851969 B2. These hardware facilities are used by the z/VM hypervisor to give the illusion that a guest machine is operating on an earlier model of the hardware. First, there is the instruction-blocking facility (IBF). This provides the means by which instructions — and newer functions of existing instructions — can be blocked if z/VM is providing a guest configuration for an earlier model. For example, when executing on a z196, z/VM could manage guest machines that looked like a z10; none of the newer z196 instructions would be available to a guest. Due to circuitry constraints, there is a limit of how many previous models can be inhibited (as I recall, you could only use IBF to block back two machine levels). A unique IBF level is applied to each virtual guest, so one guest may be running on the native hardware, another may be blocked back to the previous machine level, and another may be blocked back two machine levels. Second, there the function-indicating-instruction interception facility (FIIIF). This allows z/VM to intercept the query function of an instruction that has one (such as the message-security assist instructions). This allows z/VM to further restrict the indication of available functions for these instructions ... ever more than two machine levels back. Why go to all this trouble to provide a guest machine with the illusion that it's running on an older machine? As I mentioned in the previous posting in this thread, z/VM may be operating in a complex of multiple physical systems that are of different hardware levels. z/VM's live-guest relocation (LGR) facility lets it dispatch a guest OS on one machine, and subsequently — due to recovery conditions or even load balancing — dynamically uproot the guest from one machine and transplant it to a different machine. If the guest started out on the newer machine and was allowed to discover newer instructions and functions thereof, it would be unpleasantly surprised if it was redeployed on an older machine that did not have those functions. Ideally, the guest should discover the available facilities by using the STORE FACILITY LIST EXTENDED (STFLE) instruction. Because STFLE is intercepted by z/VM, it will only indicate the facilities that are available on all machines in a LGR environment (i.e., it blatantly lies through its teeth to protect you from yourself). However, z/VM development recognized that some programs — such as 3rd-party software or customer applications — may not use the kinder and gentler ways of discovering the presence of instructions and facilities. Rather, they still do it the old-fashioned way by test-executing the instruction or function, and recovering from the ensuing program interruption if it's not available. The IBF and FIIIF hardware was added to help manage these scenarios ... without the angst of having an application crap out when it's re-deployed in an older machine in a LGR environment. How do I tell what facility an instruction (or function thereof) is a part of? As noted before, check subcolumn 3 of the Characteristics column in the Summary of Instructions section in the PoO. Also, for each instruction that is model dependent, the list of Program Exceptions (toward the end of each instruction's description) will list an operation exception if the corresponding facility is not installed. Most (but not all) such instructions have a facility indication that is stored by STFLE. For example, if you wanted to exploit the ROTATE THEN INSERT SELECTED BITS (RISBG) instruction, you would see that it is part of the general-instructions extension facility (GEIF). Turning to the section "Facility Indications" (at the very end of Chapter 4), you would discover that the presence of GEIF is indicated by facility bit 34. If STFLE returns a result in which bit 34 is one, you have the sexiest instruction in the architecture at your disposal; otherwise, no joy. A brief note about STFLE: This is not the swiftest instruction in the machine, so it makes sense to execute it only once during the initialization of an application that needs its results, and subsequently test the stored result. For those running under z/OS, you don't even have to execute STFLE! z/OS stores a complete set of facility indications in some control block somewhere (as I'm retired, I no longer have access to the data areas books, but I think it's chained off the CVT). z/OS then copies the next several words of facility indications to real location 200 (C8 hex ... the same place where STFL stores its measly 32 bits). Because z/OS maps this low memory V=R, the data is available to any application running under z/OS. As I recall, z/OS copies 8 or 9 words of indications, so you've got access to all the currently-defined facility indications without having to shag down a chain of pointers to find the control block.
