MISSING: "runtest" regression test for STFL/STFLE instructions

[Fish-Git]

Issue title says it all: we need a "runtest" test for the STFL and STFLE instructions to ensure our Facility List bits are getting set correctly depending on initial ARCHLVL setting as well as run-time architectural mode.

I'd do it myself except I'm absolutely swamped right now.

Is there anyone else out there who could take care of this for us?

Thanks!

[jphartmann]

Sure. I'll do it. Anything else in that area needs looking at?

[jphartmann]

Ok, this is the difference between hyperion and a z12 (that is, the test passes on Hyperion):

>>> Mismatch offset 0 in Basic STFL.. Have FB. Want F1. <<<
... Have FB6BFFFB at 000180C8
... Want F1F4FFFB
>>> Mismatch offset 0 in First two doublewords of extended facilities list. Have FB. Want F1. <<<
... Have FB6BFFFB FCFFF840 000C0000 00000000 at 00018200
... Want F1F4FFFB F8F50800 201C0000 00000000
>>> GPR 00000003 mismatch. Have 00000000 00000002. Want 00000000 00000001.
>>> GPR 00000005 mismatch. Have 00000000 00000002. Want 00000000 00000001.
Test stfl and stfle: 6 OK compares. 4 errors.

Bits 3 through 5 are related to DAT enhancement. 6 is asn reuse. Shouldn't it be on for installed? 8 is enhanced dat 1. 11 is configuration topology. 12 is for IBM use; presumably this should be turned on. 13 is IPTE-range; should be off (superseded by what?) 14 nonquiescing key setting. 15 another IBM one. 37 is floating point extension. 44 is PFPO. 46 IBM. 48 DFP. 49 Exec hint. 50 constrained xaction. 51 local TLB clearing.

Interesting that the z12 stores three doublewords even though the last one is all zeros. GPR 3 is R0 on cc0; 5 is the one on cc3.

Clearly there will be a difference for any other real z hardware. How can that be consolidated?

On CMS I can do

q cpuid
CPUID = FF01898728288000
Ready; T=0.01/0.01 08:56:00

and then set a variable CPUTYPE to 2828 and do conditional testing of the lists. So which model is Hercules emulating?

And even machines with the same type number could have different millicode loads and thus different facilities lists.

This is rather ugly. Thoughts anyone?

[mcisho]

STFLE on a zPDT with the latest(?) code to emulate an EC12 returns 3 doublewords

FF20FFF3 FC7CE000 00000000 00000000 00000000 00000000

[Fish-Git]

This is rather ugly. Thoughts anyone?

We don't mention it anywhere in Hercules documentation (but we probably should!) but in my HercGUI Help file I have the following Note in the section describing the CPU Model system configuration value:

Note: Neither HercGUI nor the Hercules emulator itself makes any attempt to try and emulate all aspects and/or features of a given CPU model. The CPU model number is currently purely cosmetic only. It defines only what value the STIDP (Store CPU ID) instruction will store, and nothing more.

I can't recall whether we've (as a group) have ever officially discussed it, but I rather suspect we do not want to travel down the path of trying to actually accurately emulate each and every particular model's behavior. Attempting to do so would be pure madness IMHO.

However, maybe we should, at the minimum, choose an official "Hercules reference model"? <shrug> Dunno.

As it stands I believe our code attempts to behave identically to whatever IBM's latest and greatest most powerful z model happens to be (i.e. attempts as much as possible to have all the latest features (bells and whistles)).

Bottom line: I'm not quite sure how best to handle our Facility List bits. I'm still sort of scratching my head over it, just like you John.

[Fish-Git]

Another thought:

Perhaps a possible solution might be to only enable a pre-defined minimum basic set of Facility Bits by default and then require users to have to manually enable those facilities their guest actually needs? (with a warning message if they try enabling one that we don't yet provide support for)

Of course such a change would introduce completely new and incompatible behavior with our current implementation and require users to modify their existing configuration files in order to get the same behavior they enjoy today so it's not exactly the best of solutions but hey, it is a solution.

[Fish-Git]

(Sorry for the sudden flurry of comments!)

Continuing with my previous idea, we could introduce a new config file statement called e.g. FACBITS (I'm not good with names) whose argument would be either a string of hex digits (defining the exact bits they want) or a pre-defined "set" name whose value we could have hard coded. Then they could choose either one of our predefined sets or the exact bits they want.

[jphartmann]

Interesting about the z/PDT. A real 2828 stores FB6BFFFB FCFFF840 000C0000 00000000.

Fish, I think that advertising a capability that does not exist leads to a confused operating system, but if the code provides all the function of a facility its bit should always be on.

[Fish-Git]

but if the code provides all the function of a facility its bit should always be on.

Generally speaking, yes, but this is Hercules we're talking about. :)

IIRC we were originally doing it that way (i.e. we originally did, implement it that way), but the ASN and LX Reuse Facility was screwing people up, which was why we decided to default to it being OFF instead (even though the facility did exist within, and could be provided by, Hercules), requiring users requiring it to specifically request it via the ARCHLVL ENABLE ASN_LX_REUSE (or ALRF ENABLE) statement:

static FACTAB factab[] =
{
/*       Facility          Default       Mandatory  Supported      Group        */
[...]
#if defined(_FEATURE_DAT_ENHANCEMENT)
FACILITY(IDTE_INSTALLED,   Z390,         NONE,      Z390,          ALS2|ALS3)
FACILITY(IDTE_SC_SEGTAB,   0, /*ZARCH*/  NONE,      0, /*ZARCH*/   ALS2|ALS3)
FACILITY(IDTE_SC_REGTAB,   0, /*ZARCH*/  NONE,      0, /*ZARCH*/   ALS2|ALS3)
#endif
#if defined(_FEATURE_ASN_AND_LX_REUSE)
FACILITY(ASN_LX_REUSE,     0, /*Z390*/   NONE,      Z390,          ALS2|ALS3)
#endif
[..]

Notice we default to '0' for ALRF, not Z390 as we technically should be. We're doing the same thing for Enhanced DAT too.

Thus we are technically already breaking the rules!

That's why I made the suggestion I did: since we're already breaking the rules, why don't we go all the way and lie about the availability of most all of our other facilities too?

In other words, what my suggestion is basically implementing is a type of "installed microcode level" of sorts, where the user can choose to "install" the microcode level that provides the facilities they need.

Hercules would, by default, provide a "default microcode level" that was the lowest common denominator (i.e. only the most basic of facilities would be provided/enabled).

But if the user wished to run a given version/flavor of a guest operating system that happened to require that certain facilities be present, they could simple "upgrade their microcode to a newer level" that provided those facilities, by simply inserting a FACBITS statement into their config file.

Does that make any sense?

[ivan-w]

As requested by Fish redirecting this question : Ok,

I checked the code (I was afraid ARCHLVL was only setting the STFL bit and not disabling the actual facility - I checked and the code correctly enables/disables the ASN_LX_REUSE path of control instructions depending on the STFL bit).

But now I am wondering : Why is it disabled by default ? The only point of disabling it was especially to circumvent a bug in a specific version of an AD/CD version of OS/390 (basically a workaround to allow things to move forward). ASN and LX Reuse is now pretty much a standard so I think it should be ENABLED by default, and DISABLED when attempting to run a buggy version of some specific version of some specific OS.

Just asking...

--Ivan

[mcisho]

STFLE on a 2827 (EC12) returns 3 doublewords

FB6BFFFB FCFFF840 003C0000 00000000 00000000 00000000

[jphartmann]

Thanks. Did you store the 2827 stfle in a virtual machine?

[mcisho]

Yes, in a z/OS 2.1 virtual machine running under z/VM 6.3

[jphartmann]

Ah, splendid. And 6.3 juggled my memory; the 2828 information I have is from z/VM 5.4, which explains why you get two more bits than I do.

[jphartmann]

To see what CP stored on the real iron (you need class E for this):

locate hcprccfl
HCPRCCFL = 002B6530                              RESIDENT
Ready; T=0.01/0.01 08:52:02
d h002B6530.40
HL002B6530  F1F4FFFB F8F50800 201C0000 00000000 06 R002B6530
HL002B6540  00000000 00000000 00000000 00000000

You can also with "plastic pipes" get at an undocumented:

pipe stfle | spec 1-* c2x 1 | cons
C140FFFBF8F50800

So CP 5.2 stores only the first doubleword of the real facilities list in both architecture modes. Wonder why it hides the rest. (Under z/CMS I see F140FFFB F8F50800.)

Clearly your 6.3 does not limit the virtual machine in this way (or is there some directory statement to enable it all?)

[mcisho]

To expand on the info I posted several days ago, STFLE issued in a z/OS 2.1 virtual machine under z/VM 6.1 on a zPDT with the latest(?) code to emulate an EC12 returns 3 doublewords:-

FF20FFF3 FC7CE000 00000000 00000000 00000000 00000000

From an ESA/390 mode CMS virtual machine on the same system:-

locate hcprccfl
HCPRCCFL = 002F4108                              RESIDENT
Ready; T=0.01/0.01 17:25:54
d h2f4108.40
HL002F4108  FFB3FFF3 FC7CE000 A05E0000 00000000 06 R002F4108
HL002F4118  18000000 00000000 00000000 00000000
HL002F4128  00000000 00000000 00000000 00000000
HL002F4138 to 002F4147 suppressed line(s) same as above ....
Ready; T=0.01/0.01 17:26:13

Presumably only the first two doublewords of the displayed area are relevant(?). See below. I don't have access to zCMS, so I can't provide any information on what it might or might not see. There appears to exist somewhere an HCPSTFLE macro which, though NOT intended to be used as Programming Interfaces of z/VM, maps the first 12-bytes of the STFLE response.

At present I'm only a simple user of the z/VM 6.3 machine, with access to the z/OS 2.1 system, but nothing else. I'm looking into getting a CMS machine, hopefully reasonably authorize, but everyone seems to be ill or on holiday at the moment. Various searches haven't highlighted any relationship between STFLE and directory statements, so maybe z/VM simply allows for more doublewords as machines appear.

Appended half an hour later.

locate hcprccfl
HCPRCCFL = 002F4108                              RESIDENT
Ready; T=0.01/0.01 18:50:15
d h2f4108.48
HL002F4108  FFB3FFF3 FC7CE000 A05E0000 00000000 06 R002F4108
HL002F4118  18000000 00000000 00000000 00000000
HL002F4128  00000000 00000000 00000000 00000000
HL002F4138 to 002F4147 suppressed line(s) same as above ....
HL002F4148  02070000 00000000
Ready; T=0.01/0.01 18:50:31

z/VM 6.1 provides 8 doublewords for the STFLE response. The byte at 2F4149 contains the number of doublewords available to the STFLE instruction, and the byte at 2F4148 contains the number of doublewords used by the STFLE instruction. So my comment "Presumably only the first two doublewords of the displayed area are relevant(?)" was wrong, the third doubleword is also relevant. So what is the x'18' in the byte at 2F4118?

[jphartmann]

5.2 shows

d h02B6530.48
HL002B6530  F1F4FFFB F8F50800 201C0000 00000000 06 R002B6530
HL002B6540  00000000 00000000 00000000 00000000
HL002B6550 to 002B656F suppressed line(s) same as above ....
HL002B6570  01070000 00000000

So it looks like 5.2 sets R0 incorrectly, but 5.4 gets me three doublewords:

 DB6BFFFB FCFFF840 000C0000 00000000
 00000000 00000000

Bits 131 and 132 are not assigned as of the latest PoO. Presumably they will be assigned to IBM in the next edition.

[mcisho]

From an ESA/390 mode CMS virtual machine on the z/VM 6.3 system (a 2827 (EC12))

locate hcprccfl
HCPRCCFL = 004B50E0                              RESIDENT
Ready; T=0.01/0.01 07:19:50
d h004b50e0.4f
HL004B50E0  FBFFFFFB FCFFF840 FFDE0000 00000000 06 R004B50E0
HL004B50F0  18000000 00000000 00000000 00000000
HL004B5100  00000000 00000000 00000000 00000000
HL004B5110 to 004B511F suppressed line(s) same as above ....
HL004B5120  02070000 00000000 00000000 00000000
Ready; T=0.01/0.01 07:20:11

[mcisho]

From an ESA/390 mode CMS virtual machine under z/VM 6.3 on a 2964 (z13)

locate hcprccfl
HCPRCCFL = 004B50E0                              RESIDENT
Ready; T=0.01/0.01 04:36:49
d h4b50e0.4f
HL004B50E0  FBFFFFFB FCFFFD40 FFDE8000 00000000 06 R004B50E0
HL004B50F0  D8030000 00000000 00000000 00000000
HL004B5100  00000000 00000000 00000000 00000000
HL004B5110 to 004B511F suppressed line(s) same as above ....
HL004B5120  02070000 00000000 00000000 00000000
Ready; T=0.01/0.01 04:37:10