On Mon, 2022-03-07 at 15:42 +0100, Nico Boehr wrote: > On Fri, 2022-03-04 at 11:56 +0100, Janosch Frank wrote: > > On 3/3/22 22:04, Eric Farman wrote: > > > A SIGP SENSE is used to determine if a CPU is stopped or > > > operating, > > > and thus has a vested interest in ensuring it received a CC0 or > > > CC1, > > > instead of a CC2 (BUSY). But, any order could receive a CC2 > > > response, > > > and is probably ill-equipped to respond to it. > > > > sigp sense running status doesn't return a cc2, only sigp sense > > does > > afaik. > > Looking at the KVM implementation tells me that it's not doing more > > than > > looking at the R bit in the sblk. > > From the POP I read _all_ orders may indeed return CC=2: case 1 under > "Conditions precluding Interpretation of the Order Code". > > That being said, there are a few more users of smp_sigp (no retry) in > smp.c (the test, not the lib). > > Does it make sense to fix them aswell? I thought it made sense to do the lib, since other places expect those things to "just work." But for the tests themselves, I struggle to convince myself with one path over another. The only way KVM returns a CC2 is because of a concurrent STOP/RESTART, which isn't a possibility because of the waiting the lib itself does when invoking the STOP/RESTART. So should the tests be looking for an unexpected CC2? Or just loop when they occur? If the latter, shouldn't the lib itself do that? I'm happy to make changes, I just can't decide which it should be. Any opinions? Eric
