Quoting Claudio Imbrenda (2022-08-10 12:08:22)
[...]
> > diff --git a/s390x/panic-loop-extint.c b/s390x/panic-loop-extint.c
> > new file mode 100644
> > index 000000000000..d3a3f06d9a34
> > --- /dev/null
> > +++ b/s390x/panic-loop-extint.c
[...]
> > +static void ext_int_handler(void)
> > +{
> > + /*
> > + * return to ext_old_psw. This gives us the chance to print the return_fail
> > + * in case something goes wrong.
> > + */
> > + asm volatile (
> > + "lpswe %[ext_old_psw]\n"
> > + :
> > + : [ext_old_psw] "Q"(lowcore.ext_old_psw)
> > + : "memory"
> > + );
> > +}
>
> why should ext_old_psw contain a good PSW? wouldn't it contain the
> PSW at the time of the interrupt? (which in this case is the new PSW)
>
> but this should never happen anyway, right?
Well, after your remark, I thought about this a little more and found several issues with my implementation:
- I enabled the clock comparator subclass mask, but set the CPU timer. The test also works with the clock comparator since it also stays pending. Doesn't really matter which one to use as long as you stay consistent. :-)
- returning to ext_old_psw is not enough, since the CPU timer subclass mask is still enabled and the CPU timer is negative. This means the CPU timer will fire once we enable external interruptions and hence impede printing the report_fail()
- the whole lpswe is redundant, since the default kvm-unit-test handler already does that. I will refactor this to leave the default kut handler in place, which is much nicer and safer.
So upcoming version will refactor this test a bit and rely on the default kvm-unit-test int handler and the nice new register_ext_cleanup_func().
