On 14.02.2018 16:33, Collin L. Walling wrote:
> On 02/14/2018 05:57 AM, David Hildenbrand wrote:
>> 1. CKC interrupts can be cleared by resetting the CKC
>> 2. SCLP interrupts can be cleared only via delivery (apart from CPU
>> So if you have CKC and SCLP pending at the same time, you get the CKC
>> delivered first and the SCLP remains pending.
>> Now, the easiest way to clear that (if you don't know if any is
>> pending!) is to simply print a string. Then you know that you have
>> exactly one SCLP interrupt pending.
>> So simply printing a string after potentially reading should be
>> sufficient to clear the SCLP interrupt deterministically :)
> Perhaps it is due to my lack of understanding of how irqs are queued,
> but is it
> possible that we could still end up with service interrupts pending in
> the SCLP?
> Specifically if we're still accepting external interrupts from
> keystrokes but we
> aren't reading anything from the SCLP.
> Let's say we have 1 service signal pending and we go to print something.
> executes the sclp service call instruction and generates a new service
> The SCLP would consume one of the service interrupts and write to the
> We still have 1 interrupt pending that we need to deal with.
> That 1 pending interrupt could have been generated at any time we're still
> listening to activity from the keyboard.
There is no "queue" or something like this for service interrupts.
Either one service interrupt is pending, or it is not. Have a look at
arch/s390/kvm/interrupt.c in the Linux kernel sources and search for the
functions __deliver_service() and __inject_service() for example.
> In my next update to this patch, I setup the control program receive
> mask in
> the SCLP only when we need to get input from the user and then clear the
> when we're done. Doing so will make it so we generate an interrupt from
> keystrokes ONLY when the mask is set. No external interrupts from
> will be generated when the cp_receive mask is NOT set.
> After I clear the cp_receive mask, we consume any leftover interrupts by
> calling consume_sclp_int (I also fixup the patch to make sure we only end
> irq-clearing on a ckc interrupt -- oops).
Not sure whether you really have to deal with the ckc here again to get
rid of pending service interrupts... David's idea to simply print out
something to clear the pending service interrupt sounds easier to me.