On Thu, 15 Apr 2021 09:48:37 -0400 Eric Farman <farman@xxxxxxxxxxxxx> wrote: > On Thu, 2021-04-15 at 12:51 +0200, Cornelia Huck wrote: > > I'm wondering what we should do for hsch. We probably want to return > > -EBUSY for a pending condition as well, if I read the PoP > > correctly... > > Ah, yes... I agree that to maintain parity with ssch and pops, the > same cc1/-EBUSY would be applicable here. Will make that change in next > version. Yes, just to handle things in the same fashion consistently. > > > the only problem is that QEMU seems to match everything to 0; but > > that > > is arguably not the kernel's problem. > > > > For clear, we obviously don't have busy conditions. Should we clean > > up > > any pending conditions? > > By doing anything other than issuing the csch to the subchannel? I > don't think so, that should be more than enough to get the css and > vfio-ccw in sync with each other. Hm, doesn't a successful csch clear any status pending? That would mean that invoking our csch backend implies that we won't deliver the status pending that is already pending via the workqueue, which therefore needs to be flushed out in some way? I remember we did some special csch handling, but I don't immediately see where; might have been only in QEMU.
