On Thu, 15 Apr 2021 14:42:21 -0400 Eric Farman <farman@xxxxxxxxxxxxx> wrote: > 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? Yes, maybe something like that. Maybe we should do that on top once we have a good idea, if the current series already fixes the problems that are actually happening now and then. > > > 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. :( I might have misremembered; it only really applies to passthrough, as emulated subchannels are handled synchronously anyway.
