Re: [RFC v1 1/1] vfio-ccw: Don't call cp_free if we are processing a channel program

[Halil Pasic <pasic@linux.ibm.com>]

On Mon, 24 Jun 2019 11:42:31 +0200
Cornelia Huck <cohuck@redhat.com> wrote:

> > > It can issue whatever it wants, but shouldn't the SSCH get a CC2 until
> > > the halt/clear pending state is cleared?  Hrm, fsm_io_request() doesn't
> > > look.  Rather, it (fsm_io_helper()) relies on the CC2 to be signalled
> > > from the SSCH issued to the device.  There's a lot of stuff that happens
> > > before we get to that point.

Yes CC2 would be the correct thing to do in this situation. Doesn't QEMU
do some sort of logic of this kind already. AFAIR QEMU should reject the
SSCH because it knows that the halt/clear function is in progress or
pending. Or am I worng?

Even if QEMU does it, the kernel must not rely on QEMU or
whatever userspace doing it correctly. What I'm trying to say, if QEMU
can do it vfio_ccw should do it as well.

I'm almost always in favor of sticking close to what PoP says.

    
> > 
> > Yes, and stuff that happens is memory allocation, pinning and other 
> > things which can take time.
> >   
> > > 
> > > I'm wondering if there's a way we could/should return the SSCH here
> > > before we do any processing.  After all, until the interrupt on the
> > > workqueue is processed, we are busy.
> > >     
> > 
> > you mean return the csch/hsch before processing the ssch? Maybe we could 
> > extend CP_PENDING state, to just PENDING and use that to reject any ssch 
> > if we have a pending csch/hsch?  
> 
> I'd probably not rely on the state for this. Maybe we could look at the
> work queue? But it might be that the check for the intparm I suggested
> above is already enough.

PoP says function control bits are what matter here:
"""
Condition code 2 is set, and no other action is
taken, when a start, halt, or clear function is currently
in progress at the subchannel (see “Function Control
(FC)” on page 13).
"""

Regards,
Halil