On 30/04/2018 17:30, Cornelia Huck wrote:
On Wed, 25 Apr 2018 15:52:19 +0200
Pierre Morel <pmorel@xxxxxxxxxxxxxxxxxx> wrote:
On 25/04/2018 10:41, Cornelia Huck wrote:
On Thu, 19 Apr 2018 16:48:07 +0200
Pierre Morel<pmorel@xxxxxxxxxxxxxxxxxx> wrote:
diff --git a/drivers/s390/cio/vfio_ccw_private.h b/drivers/s390/cio/vfio_ccw_private.h
index 3284e64..93aab87 100644
--- a/drivers/s390/cio/vfio_ccw_private.h
+++ b/drivers/s390/cio/vfio_ccw_private.h
@@ -76,7 +76,7 @@ enum vfio_ccw_state {
*/
enum vfio_ccw_event {
VFIO_CCW_EVENT_NOT_OPER,
- VFIO_CCW_EVENT_IO_REQ,
+ VFIO_CCW_EVENT_SSCH_REQ,
VFIO_CCW_EVENT_INTERRUPT,
VFIO_CCW_EVENT_SCH_EVENT,
/* last element! */
I don't think we should separate the ssch handling. The major
difference to halt/clear is that it needs channel program translation.
Everything else (issuing the instruction and processing the interrupt)
are basically the same. If we just throw everything at the hardware
and let the host's channel subsystem figure it out, we already should
be fine with regard to most of the races.
We must test at a moment or another the kind of request we do,
cancel, halt and clear only need the subchannel id in register 1 and as
you said are much more direct to implement.
If we do not separate them here, we need a switch in the "do_io_request"
function.
Is it what you mean?
Yes. Most of the handling should be the same for any function.
I really don't know, the 4 functions are quite different.
- SSCH uses an ORB, and has a quite long kernel execution time for VFIO
- there is a race between SSCH and the others instructions
- XSCH makes subchannel no longer start pending, also reset the busy
indications
- CSCH cancels both SSCH and HSCH instruction, and perform path management
- HSCH has different busy (entry) conditions
But since they are not implemented today, I can keep the old name.
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-s390" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
