On Thu, 2021-04-15 at 18:19 +0200, Cornelia Huck wrote: > 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? Yep. > 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? Ah, so I misunderstood the direction you were going... I'm not aware of a way to "purge" items from a workqueue, as the flush_workqueue() routine is documented as picking them off and running them. Perhaps an atomic flag in (private? cp?) that causes vfio_ccw_sch_io_todo() to just exit rather than doing all its stuff? > I remember we did some special > csch handling, but I don't immediately see where; might have been > only > in QEMU. > Maybe. I don't see anything jumping out at me though. :(
