STHYI Instruction

[arfineman]

It appears that Hyperion by default is turning on facility bit 74 (STHYI) that is reserved for zVM. However, STHYI instruction is not supported and causes Operation Exception. Hercules does support many zVM exclusive instructions like Diagnose 0 and 8. But I don't think the bit should be on, if the instruction is not supported. This bit is off on Hercules 3.13.

[arfineman]

Of course the problem can easily be circumvented by the Facility Disable BIT74.

[Fish-Git]

The STHYI instruction is supported. It's VM that's throwing the Operation Exception due to its choice to not intercept and handle it itself:

hyperion/sie.c

Lines 1994 to 2015 in 5857860

	#if defined( FEATURE_074_STORE_HYPER_INFO_FACILITY )
	/*-------------------------------------------------------------------*/
	/* B256 STHYI - CP Store Hypervisor Information [RRE] */
	/*-------------------------------------------------------------------*/
	/* This instruction is part of z/VM's "CMMA" (Collaborative Memory */
	/* Management) facility/feature. It is NOT a valid z/Architecture */
	/* instruction and will always cause a program check when attempted */
	/* to be executed natively. It is a z/VM-ONLY instruction that can */
	/* only be used (executed) by guests running under z/VM via z/VM */
	/* instruction interception and simulation. An operation execption */
	/* program interrupt will always occur if this instruction is not */
	/* intercepted by z/VM. */
	/* Ref: page 895 of SC24-6272-03 "zVM 7.1 CP Programming Services" */
	/*-------------------------------------------------------------------*/
	DEF_INST( store_hypervisor_information )
	{
	int r1, r2;
	RRE( inst, regs, r1, r2 );
	SIE_INTERCEPT( regs );
	ARCH_DEP( program_interrupt )( regs, PGM_OPERATION_EXCEPTION );
	}
	#endif

Perhaps it's a privileged instruction and your guest is trying to execute it from Problem State code?  (That's just a guess; I'm too lazy to check the manual right now to see whether it is indeed a privileged instruction or not.)

OR...   you could just manually disable that particular facility in your Hercules configuration file to see whether that fixes your problem or not:

   FACILITY  DISABLE  074_STORE_HYPER_INFO

I'm going to close this issue as "Invalid (likely user error)". If you feel this is wrong, please let me know and I'll re-open it (or you can yourself!) so we can investigate the matter further.

I will readily admit I was mostly guessing regarding the implementation of both the STHYI Store Hypervisor Information and ESSA Extract and Set Storage Attributes instructions. My implementation could very well be very wrong. I don't believe it is, but then I'm no expert at these things either.

[Fish-Git]

Aaron, is your code issuing the STFLE instruction beforehand and then checking the bits that z/VM is returning to you to make sure the bit is on before you attempt executing it?

The bit that Hercules is setting is so z/VM can know whether or not the hardware supports the instruction or not (since, looking at the manual, it appears the instruction can be executed in Problem state or Supervisor state), but whether or not the z/VM you're using supports it or not (or whether the z/VM you're using chooses to allow you to use it or not) is entirely up to z/VM, not Hercules.

As you can see in our code, Hercules only throws the Program Check if z/VM chooses not to intercept it. So I think you need to try and determine why z/VM is choosing not to intercept it.

Can we see the Hercules log message that's issued when the Program Check occurs?

[arfineman]

You posted the answer to the problem yourself. And that is:

 /* ............................. It is NOT a valid z/Architecture    */ 
 /* instruction and will always cause a program check when attempted  */ 
 /* to be executed natively. ........................................ */

All I'm saying is the bit should be default to off, meaning the instruction is not supported. zVM will turn it on, because it supports it.

I run my own OS natively and it is always in supervisor state. There is no zVM involved. It always issues a STFLE and checks for bit 74 before issuing STHYI. It works fine under zVM. And I just disabled the bit74 and everything works fine. Just wanted to let you know. The bottom line is, no real hardware should turn bit 74 on, because STHYI is not supported on a real hardware.

Here is the log:

19:26:09.693193 *0001* SCLP input: Length=0005 Command=sthyi
19:26:09.693542 *0001* R0=0003 STFLE=F3F6FFFB FCFDFD24 207CC000 00000000 00004000 00000000 40000000 00000000
19:26:09.693869 *PGM Interrupt* CODE= 0001 PSW= 00000000 80000000 00000000 000047F4 ILC= 0004
19:26:09.693915 *0001* Command completed, return code= 00000000, Elapsed time= 00:00:00.000843
herc =====>

[Fish-Git]

I run my own OS natively and it is always in supervisor state. There is no zVM involved. It always issues a STFLE and checks for bit 74 before issuing STHYI. It works fine under zVM. And I just disabled the bit74 and everything works fine. Just wanted to let you know.

<separated for emphasis>

The bottom line is, no real hardware should turn bit 74 on, because STHYI is not supported on a real hardware.

Fair enough. I shall make the change to have the default for this facility to be off, and remove the code for the instruction as well. Thank you again for reporting it, and my apologies for the incorrect handling.

QUESTION: Should the ESSA (Extract and Set Storage Attributes) instruction be handled the same way? I presume yes?

(Issue being re-opened (and correctly labeled as "Bug") to correct the addressed concerns)

[Fish-Git]

Here is the log:

19:26:09.693193 *0001* SCLP input: Length=0005 Command=sthyi
19:26:09.693542 *0001* R0=0003 STFLE=F3F6FFFB FCFDFD24 207CC000 00000000 00004000 00000000 40000000 00000000
19:26:09.693869 *PGM Interrupt* CODE= 0001 PSW= 00000000 80000000 00000000 000047F4 ILC= 0004
19:26:09.693915 *0001* Command completed, return code= 00000000, Elapsed time= 00:00:00.000843
herc =====>

That's not a Hercules log. That's a copy of the text that is displayed on the Hercules HMC panel, which is something entirely different. The HMC only displays as much of a given message that will actually fit on the width of the screen too, whereas the logfile is never truncated and always contains the complete text of all messages that are issued.

Besides that, what you posted are not even Hercules messages. They look like they're messages that some test program wrote to its terminal or something. I need to see the Program Interrupt messages that Hercules itself wrote to its HMC/logfile. All Operation Exception Program Interrupts should always be logged to both the Hercules console (HMC) as well as its logfile too.

That is, as long as you're not doing something stupid like using OSTAILOR QUIET of course.

[Fish-Git]

QUESTION: Should the ESSA (Extract and Set Storage Attributes) instruction be handled the same way? I presume yes?

I'm now thinking possibly "No".

According to page 917 of manual SC24-6179-04 "zVM 6.3 CP Programming Services":

This chapter describes the EXTRACT AND SET STORAGE ATTRIBUTES
instruction, the interface used by a guest to collaborate with z/VM, as well as
associated changes to the virtual-machine interface. The material is an extension to
the material in z/Architecture Principles of Operation.

Which is something manual SC24-6272-03 "zVM 7.1 CP Programming Services" specifically doesn't say about the STHYI CP Store Hypervisor Information instruction.(*)

It seems confusing to me that one manual would say the instruction is an extension to z/Architecture while the other manual would purposely not say that for the other instruction.

Who's right and who's wrong? Which manual is right and which manual is wrong? Or are they both right? Is one an extension to the architecture whereas the other is not? Or vice-versa or neither?

(sigh!)

  :(

---

(*) It also seems rather odd to me that, while the STHYI instruction itself is not documented anywhere in the z/Architecture Principle of Operation manual, the Facility bit that controls it (bit 74) is specifically mentioned in the manual, on page 4-102! This is what lead me to originally code things the way I did. I mean, why have a specific facility bit defined for it and have it mentioned in the manual if it wasn't actually part of the architecture?! Very weird and very confusing!

[arfineman]

Hi Fish,
I think ESSA falls in to the same category "zVM specific instruction" and need not be supported. Supporting them is strictly up to you. Just as at some point it was decided some Diagnose instructions be supported. IBM has always made exceptions for VM as there are VM specific bits in many DASD channel commands to accommodate minidisks and the way CP formats its dasd for its own use by numbering records sequentially from the start of the cylinders to end.
Best regards,

[Fish-Git]

Closed by commit 9dfd46c.