Quoting Janosch Frank (2023-03-28 15:42:26)
> 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().
Yes, makes perfect sense, I just didn't see this possiblity. Thanks, will change.
