vfio-ccw: process ssch with interrupts disabled

Quoted 4 lines · Cornelia Huck

When we call ssch, an interrupt might already be pending once we return from the START SUBCHANNEL instruction. Therefore we need to make sure interrupts are disabled until after we're done with our processing.

Sounds right.

Quoted 3 lines

Note that the subchannel lock is the same as the ccwdevice lock that is mentioned in the documentation for ccw_device_start() and friends.

I think this is helpful hint for me to understand the correct way of using sch->lock in our context, but not sure if the word "same" brings confusion to the others. There are many difference between them, considering the fact that sch->lock exists in the CSS driver for a long time already, and it is not external interface like ccw_dev->lock, and its usage is different with ccw_dev->lock in the existing code. It's because vfio-ccw are offering interface to the external world based directly on the css driver level, it makes the purpose of protecting what should be protected with it becomes the same.

Not a problem for me, but better with a better rewording?

Quoted 6 lines

Signed-off-by Cornelia Huck <[email protected]>

---
 drivers/s390/cio/vfio_ccw_fsm.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

LGTM:

Reviewed-by Dong Jia Shi <[email protected]>

* Cornelia Huck <[email protected]> [2018-04-13 16:05:09 +0200]:

Nitpick for the title:
vfio-ccw: process ssch with interrupts disabled

Should be "vfio: ccw:"?

When we call ssch, an interrupt might already be pending once we return from the START SUBCHANNEL instruction. Therefore we need to make sure interrupts are disabled until after we're done with our processing.

Note that the subchannel lock is the same as the ccwdevice lock that is mentioned in the documentation for ccw_device_start() and friends.

Signed-off-by Cornelia Huck<[email protected]>

When we call ssch, an interrupt might already be pending once we return from the START SUBCHANNEL instruction. Therefore we need to make sure interrupts are disabled until after we're done with our processing.

Note that the subchannel lock is the same as the ccwdevice lock that is mentioned in the documentation for ccw_device_start() and friends.

Signed-off-by Cornelia Huck <[email protected]>

---
  drivers/s390/cio/vfio_ccw_fsm.c | 19 ++++++++++++-------
  1 file changed, 12 insertions(+), 7 deletions(-)

drivers/s390/cio/vfio_ccw_fsm.c +9 -6

index ff6963ad6e39..3c800642134e 100644
@@ -20,12 +20,12 @@ static int fsm_io_helper(struct vfio_ccw_private *private)
  	int ccode;
  	__u8 lpm;
  	unsigned long flags;
+	int ret;
 
  	sch = private->sch;
 
  	spin_lock_irqsave(sch->lock, flags);
  	private->state = VFIO_CCW_STATE_BUSY;
-	spin_unlock_irqrestore(sch->lock, flags);
 
  	orb = cp_get_orb(&private->cp, (u32)(addr_t)sch, sch->lpm);
 

@@ -38,10 +38,12 @@ static int fsm_io_helper(struct vfio_ccw_private *private)
  		 * Initialize device status information
  		 */
  		sch->schib.scsw.cmd.actl |= SCSW_ACTL_START_PEND;
-		return 0;
+		ret = 0;
+		break;
  	case 1:		/* Status pending */
  	case 2:		/* Busy */
-		return -EBUSY;
+		ret = -EBUSY;
+		break;
  	case 3:		/* Device/path not operational */
  	{
  		lpm = orb->cmd.lpm;

@@ -51,13 +53,16 @@ static int fsm_io_helper(struct vfio_ccw_private *private)
  			sch->lpm = 0;
 
  		if (cio_update_schib(sch))
-			return -ENODEV;
-
-		return sch->lpm ? -EACCES : -ENODEV;
+			ret = -ENODEV;
+		else
+			ret = sch->lpm ? -EACCES : -ENODEV;
+		break;

Quoted 66 lines · Cornelia Huck

When we call ssch, an interrupt might already be pending once we return from the START SUBCHANNEL instruction. Therefore we need to make sure interrupts are disabled until after we're done with our processing.

Note that the subchannel lock is the same as the ccwdevice lock that is mentioned in the documentation for ccw_device_start() and friends.

Signed-off-by Cornelia Huck <[email protected]>

---
  drivers/s390/cio/vfio_ccw_fsm.c | 19 ++++++++++++-------
  1 file changed, 12 insertions(+), 7 deletions(-)

drivers/s390/cio/vfio_ccw_fsm.c +12 -7

index ff6963ad6e39..3c800642134e 100644
@@ -20,12 +20,12 @@ static int fsm_io_helper(struct vfio_ccw_private *private)
  	int ccode;
  	__u8 lpm;
  	unsigned long flags;
+	int ret;
 
  	sch = private->sch;
 
  	spin_lock_irqsave(sch->lock, flags);
  	private->state = VFIO_CCW_STATE_BUSY;
-	spin_unlock_irqrestore(sch->lock, flags);
 
  	orb = cp_get_orb(&private->cp, (u32)(addr_t)sch, sch->lpm);
 

@@ -38,10 +38,12 @@ static int fsm_io_helper(struct vfio_ccw_private *private)
  		 * Initialize device status information
  		 */
  		sch->schib.scsw.cmd.actl |= SCSW_ACTL_START_PEND;
-		return 0;
+		ret = 0;
+		break;
  	case 1:		/* Status pending */
  	case 2:		/* Busy */
-		return -EBUSY;
+		ret = -EBUSY;
+		break;
  	case 3:		/* Device/path not operational */
  	{
  		lpm = orb->cmd.lpm;

@@ -51,13 +53,16 @@ static int fsm_io_helper(struct vfio_ccw_private *private)
  			sch->lpm = 0;
 
  		if (cio_update_schib(sch))
-			return -ENODEV;
-
-		return sch->lpm ? -EACCES : -ENODEV;
+			ret = -ENODEV;
+		else
+			ret = sch->lpm ? -EACCES : -ENODEV;
+		break;
  	}
  	default:
-		return ccode;
+		ret = ccode;
  	}
+	spin_unlock_irqrestore(sch->lock, flags);
+	return ret;
  }
 

drivers/s390/cio/vfio_ccw_fsm.c static int fsm_io_helper(struct vfio_ccw_private *private) · line 68

Quoted 1 line

drivers/s390/cio/vfio_ccw_fsm.c +0 -0

  static void fsm_notoper(struct vfio_ccw_private *private,  

I have been working on a patch to solve this problem between others, I provide it soon.
It is much more intrusive, reworking interrupts and state machine. So may be you do not like it.

If we stay on this patch, even this is quite a long spinlock around ssch and stsch,
and we need it in the current implementation.

Acked-by Pierre Morel<[email protected]>