Re: [RFC PATCH v2 2/2] s390x: Implement the USER_SIGP_BUSY capability

[David Hildenbrand]

>>
>> Can't we call s390_cpu_reset_sigp_busy() directly from
>> handle_sigp_single_dst(),
>> after the handle_sigp_single_dst() call?
> 
> Can I? Most of the orders in that routine are invoked via
> "run_on_cpu(CPU(dst_cpu), ..." dispatching them to other vcpus, so I
> presumed that was a stacked task. But of course, that doesn't make a
> lot of sense, since it's holding that sigp lock across the duration, so
> it must be a vcpu switch instead. Not sure what I was thinking at the
> time, so I'll give this a try.

These functions are all synchronous. See below.

> 
>>
>> IIRC we could clear it in case cpu->env.sigp_order wasn't set.
>> Otherwise,
>> we'll have to clear it once we clear cpu->env.sigp_order -- e.g., in
>> do_stop_interrupt(), but
>> also during s390_cpu_reset().
>>
>> We could have a helper function that sets cpu->env.sigp_order = 0 and
>> clears the busy indication.
>>
> 
> Agreed, this was some of the refactoring that I had in mind looking at
> this mindboggling patch.
> 
> I would love it if sigp_order weren't limited to the STOP and STOP AND
> STORE STATUS orders, but I hesitate to mess with that too much, for
> fear of ripples across the system.

The only reason for that is that these are the only two (asynchronous)
SIGP orders that can take forever to stop. You could have an endless
stream of program interrupts on such a CPU and the CPU will actually
never process the STOP interrupt. That's why only these are sticky --
because run_on_cpu() itself is synchronous.

Only for SIGP STOP*, run_on_cpu() can return and the order has not been
fully processed.

All other ones are processed completely "synchronously" in QEMU. (using
run_on_cpu(), but they are fully synchronous).

-- 
Thanks,

David / dhildenb