On Thu, Jun 02, 2022 at 07:19:30PM +0200, Eric Farman wrote: > Last autumn, Jason Gunthorpe proposed some rework of vfio-ccw [1], > to better fit with the new mdev API (thank you!). Part of that > series was pulled for kernel 5.16 [2], but the complexities of > the remaining patches got them hung up behind other work. > > This series attempts to dust off and complete that, with the > goal of untangling the lifecycle of a s390 subchannel when > bound to vfio-ccw instead of the usual io_subchannel driver. > > Patches 1-8 are inspired by and/or split out from that series, > in order to be consumable on their own (backports, etc.). > > Patches 9-12 handle the goal of making the FSM complete, > and synchronizing the subchannel's life with that of the mdev. > (This was the goal of patch 5 of the larger series [3].) > > Patches 13-14 are pulled directly from the earlier series. > As these patches hit some other of the consumers of vfio, > those on CC who are unfamiliar with vfio-ccw probably only > care about these. :) > > Patches 15-18 links the lifecycle of the vfio_ccw_private struct > with the mdev via a vfio reference. (Patch 17 was also pulled > directly from the earlier series.) > > In the end, the subchannel probe/remove callbacks from the css > driver simply register/unregister with vfio-mdev. The communication > with the subchannel is delayed until the mdev routines, which > handles all the vfio-related memory and subchannel enablement. > There's no longer a configuration where the mdev is closed while > the subchannel remains enabled, since that's weird. This all looks great thanks! I would like this to go through the VFIO tree once you repost it on v5.19-rc1 > @Jason: I carried the S-o-b/r-b tags on patches 13, 14, and 17, > as they were cherry-picked straight from your v3. > If you'd prefer your S-o-b on others, please let me know. It is OK, you did a lot of work splitting things up Thanks, Jason