On 11/11/21 08:47, Thomas Huth wrote:
> On 22/10/2021 15.10, Janis Schoetterl-Glausch wrote:
>> Check that specification exceptions cause intercepts when
>> specification exception interpretation is off.
>> Check that specification exceptions caused by program new PSWs
>> cause interceptions.
>> We cannot assert that non program new PSW specification exceptions
>> are interpreted because whether interpretation occurs or not is
>> configuration dependent.
>>
>> Signed-off-by: Janis Schoetterl-Glausch <scgl@xxxxxxxxxxxxx>
>> Reviewed-by: Janosch Frank <frankja@xxxxxxxxxx>
>> Reviewed-by: Thomas Huth <thuth@xxxxxxxxxx>
>> ---
> ...
>> + report_prefix_push("on");
>> + vm.sblk->ecb |= ECB_SPECI;
>> + reset_guest();
>> + sie(&vm);
>> + /* interpretation on -> configuration dependent if initial exception causes
>> + * interception, but invalid new program PSW must
>> + */
>> + report(vm.sblk->icptcode == ICPT_PROGI
>> + && vm.sblk->iprcc == PGM_INT_CODE_SPECIFICATION,
>> + "Received specification exception intercept");
>> + if (vm.sblk->gpsw.addr == 0xdeadbeee)
>> + report_info("Interpreted initial exception, intercepted invalid program new PSW exception");
>> + else
>> + report_info("Did not interpret initial exception");
>
> Hi Janis!
>
> While using this test in our downstream verification of the backport of the related kernel patch, it occurred that the way of only reporting the interpreted exception via report_info() is rather unfortunate for using this test in automatic regression runs. For such regression runs, it would be good if the test would be marked with FAIL if the exception was not interpreted. I know, the interpretation facility is not always there, but still would it be somehow possible to add such a mode? E.g. by checking the machine generation (is this always available with z15 and newer?) and maybe adding a CLI option to force the hard check (so that e.g. "-f" triggers the failure if the exception has not been interpreted, while running the test without "-f" would still do the old behavior instead)?
>
> Thomas
>
Sounds good, I'll look into it.
