After having fixed the bugs (*) that I discovered in the RRBM (Reset Reference Bits Multiple) instruction, I discovered much to my dismay that whenever I would run my test program under z/VM with CP tracing active, z/VM would always display the mnemonic for the RRBM instruction as '?', indicating it was not recognizing the instruction as being a valid instruction! To confirm this, I forced the instruction to be intercepted, and sure enough a Program Interrupt (Operation Exception) was thrown.

This issue came to light during my research into (and testing of) Hercules's storage key handling. The problem is, at no time does z/VM ever set that field to a non-zero value! It is always NULL! This simple fact ends up causing the guest's facility bits to always be exactly equal the host's facility bits (which based on my testing is wrong!). That is to say, that might have been the way IBM originally designed it (although I could find no evidence to support that other than Jan having originally coded it that way), but that is certainly NOT the way it is handled with today's z/VM. This is Jan's original 'Virtual Architecture Level support' commit made on August 29, 2010, commit f29a38c.Д«ut this appears to either be completely wrong, or else IBM changed the way the SIE2BK 'fld' field is handled sometime after Jan coded his change. :(Д¬urrently, in sie.c, if FEATURE_VIRTUAL_ARCHITECTURE_LEVEL is defined, we first initialize the guest's facility bits to the same value as the host's, and then depending on whether the SIE2BK 'fld' field (Facility List Designation) was defined or not, we then and-off the facility bits in the guest's copy (i.e. I've stumbled across what appears to be a rather serious bug in Hercules's facility handling under SIE.ДЄ partial fix has already been committed, but I'm kind of stuck as to where to go from here.

Installing z/vm on hercules