[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Hildenbrand
Subject: Re: [RFC PATCH v2 2/2] s390x: Implement the USER_SIGP_BUSY capability
Date: Thu, 4 Nov 2021 16:08:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0

>> 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).


David / dhildenb

reply via email to

[Prev in Thread] Current Thread [Next in Thread]