On 3/27/23 10:21, Nico Boehr wrote:
At the moment, when a PGM int occurs while in SIE, we will just reenter
SIE after the interrupt handler was called.
This is because sie() has a loop which checks icptcode and re-enters SIE
if it is zero.
However, this behaviour is quite undesirable for SIE tests, since it
doesn't give the host the chance to assert on the PGM int. Instead, we
will just re-enter SIE, on nullifing conditions even causing the
exception again.
Add a flag PROG_PGM_IN_SIE set by the pgm int fixup which indicates a
program interrupt has occured in SIE. Check for the flag in sie() and if
it's set return from sie() to give the host the ability to react on the
exception. The host may check if a PGM int has occured in the guest
using the new function sie_had_pgm_int().
We could simply check "!lowcore.pgm_int_code" by introducing:
uint16_t read_pgm_int(void)
{
mb();
return lowcore.pgm_int_code;
}
into interrupt.c.
Or to be a bit more verbose:
I don't see a reason why we'd want to store a per sblk PGM in SIE bit
when all we want to know is either: was there a PGM at all (to stop the
SIE loop) or was there a PGM between the expect and the
check_pgm_int_code().
