On Wed, 2021-12-15 at 15:02 +0100, David Hildenbrand wrote: > On 15.12.21 14:57, Christian Borntraeger wrote: > > > > Am 15.12.21 um 14:24 schrieb David Hildenbrand: > > > On 13.12.21 22:05, Eric Farman wrote: > > > > With KVM_CAP_S390_USER_SIGP, there are only five Signal > > > > Processor > > > > orders (CONDITIONAL EMERGENCY SIGNAL, EMERGENCY SIGNAL, > > > > EXTERNAL CALL, > > > > SENSE, and SENSE RUNNING STATUS) which are intended for > > > > frequent use > > > > and thus are processed in-kernel. The remainder are sent to > > > > userspace > > > > with the KVM_CAP_S390_USER_SIGP capability. Of those, three > > > > orders > > > > (RESTART, STOP, and STOP AND STORE STATUS) have the potential > > > > to > > > > inject work back into the kernel, and thus are asynchronous. > > > > > > > > Let's look for those pending IRQs when processing one of the > > > > in-kernel > > > > SIGP orders, and return BUSY (CC2) if one is in process. This > > > > is in > > > > agreement with the Principles of Operation, which states that > > > > only one > > > > order can be "active" on a CPU at a time. > > > > > > > > Suggested-by: David Hildenbrand <david@xxxxxxxxxx> > > > > Signed-off-by: Eric Farman <farman@xxxxxxxxxxxxx> > > > > --- > > > > > > In general, LGTM. As raised, with SIGP RESTART there are other > > > cases we > > > could fix in the kernel, but they are of very low priority IMHO. > > > > Does that qualify as an RB, assuming that we can fix the other > > cases later on? > > > > Certainly an Acked-by: David Hildenbrand <david@xxxxxxxxxx> , to > fully > review I need some more time (maybe tomorrow) > I have the list you'd provided for the other orders on my todo list; wasn't having a lot of success building a testcase that would prove/disprove the situation we were in, besides the orders described here. (I had previously mentioned the CPU RESET orders, but I'm worried that that was an error in my setup based on debugging I have been doing lately.)
