On 3/7/22 21:15, Eric Farman wrote:
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?
Before we continue bikeshedding, let's add the cc2 retry. If it never
returns cc2 we'll never loop on it but the dead code won't kill us either.
