Message ID | 20221102150152.2521475-1-farman@linux.ibm.com (mailing list archive) |
---|---|
Headers | show |
Series | vfio-ccw parent rework | expand |
On Wed, 2 Nov 2022 16:01:45 +0100 Eric Farman <farman@linux.ibm.com> wrote: > Hi all, > > Here is an update to the vfio-ccw lifecycle changes that have been discussed > in various forms over the past year [1][2] or so, and which I dusted off > recently. > > Patches 1-5 rework the behavior of the vfio-ccw driver's private struct. > In summary, the mdev pieces are split out of vfio_ccw_private and into a > new vfio_ccw_parent struct that will continue to follow today's lifecycle. > The remainder (bulk) of the private struct moves to follow the mdev > probe/remove pair. There's opportunity for further separation of the > things in the private struct, which would simplify some of the vfio-ccw > code, but it got too hairy as I started that. Once vfio-ccw is no longer > considered unique, those cleanups can happen at our leisure. > > Patch 6 removes the trickery where vfio-ccw uses vfio_init_device instead of > vfio_alloc_device, and thus removes vfio_init_device from the outside world. > > Patch 7 removes vfio_free_device from vfio-ccw and the other drivers (hello, > CC list!), letting it be handled by vfio_device_release directly. Looks like another spin is pending, but the vfio core and collateral changes in 6 and 7 look good to me. Would this go in through the vfio or s390 tree? I'd be happy to merge or provide a branch, depending on the route. For 6 & 7: Acked-by: Alex Williamson <alex.williamson@redhat.com> Thanks, Alex > Looking forward to the feedback. > > Thanks, > Eric > > [1] https://lore.kernel.org/kvm/0-v3-57c1502c62fd+2190-ccw_mdev_jgg@nvidia.com/ > [2] https://lore.kernel.org/kvm/20220602171948.2790690-1-farman@linux.ibm.com/ > > v1->v2: > - Rebase to 6.1-rc3 > - Patch 1: > [EF] s/device_initialize/device_register/ and associated adjustments > [MR] Add WARN_ON(!private) in vfio_ccw_sch_quiesce() > [MR] Move struct vfio_ccw_parent to _private.h, instead of standalone file > - Patch 2: > [MR] Added r-b (Thank you!) > - Patch 3: > [MR] Update commit message to point to introduction of private->release_comp > [MR] Replace the remnants of vfio_ccw_alloc_private with a straight kzalloc > [MR] Added r-b (Thank you!) > - Patch 5: > [KT] Added r-b (Thank you!) > - Patch 6: > [JG] Make vfio_init_device static > [KT] Added r-b (Thank you!) > - Patch 7: > [JG, KT] Added r-b (Thank you!) > v1: https://lore.kernel.org/kvm/20221019162135.798901-1-farman@linux.ibm.com/ > > Eric Farman (7): > vfio/ccw: create a parent struct > vfio/ccw: remove private->sch > vfio/ccw: move private initialization to callback > vfio/ccw: move private to mdev lifecycle > vfio/ccw: remove release completion > vfio/ccw: replace vfio_init_device with _alloc_ > vfio: Remove vfio_free_device > > drivers/gpu/drm/i915/gvt/kvmgt.c | 1 - > drivers/s390/cio/vfio_ccw_chp.c | 5 +- > drivers/s390/cio/vfio_ccw_drv.c | 174 +++++++++++--------------- > drivers/s390/cio/vfio_ccw_fsm.c | 27 ++-- > drivers/s390/cio/vfio_ccw_ops.c | 107 +++++++++++----- > drivers/s390/cio/vfio_ccw_private.h | 37 ++++-- > drivers/s390/crypto/vfio_ap_ops.c | 6 - > drivers/vfio/fsl-mc/vfio_fsl_mc.c | 1 - > drivers/vfio/pci/vfio_pci_core.c | 1 - > drivers/vfio/platform/vfio_amba.c | 1 - > drivers/vfio/platform/vfio_platform.c | 1 - > drivers/vfio/vfio_main.c | 32 ++--- > include/linux/vfio.h | 3 - > samples/vfio-mdev/mbochs.c | 1 - > samples/vfio-mdev/mdpy.c | 1 - > samples/vfio-mdev/mtty.c | 1 - > 16 files changed, 197 insertions(+), 202 deletions(-) >
On 11/3/22 5:56 PM, Alex Williamson wrote: > On Wed, 2 Nov 2022 16:01:45 +0100 > Eric Farman <farman@linux.ibm.com> wrote: > >> Hi all, >> >> Here is an update to the vfio-ccw lifecycle changes that have been discussed >> in various forms over the past year [1][2] or so, and which I dusted off >> recently. >> >> Patches 1-5 rework the behavior of the vfio-ccw driver's private struct. >> In summary, the mdev pieces are split out of vfio_ccw_private and into a >> new vfio_ccw_parent struct that will continue to follow today's lifecycle. >> The remainder (bulk) of the private struct moves to follow the mdev >> probe/remove pair. There's opportunity for further separation of the >> things in the private struct, which would simplify some of the vfio-ccw >> code, but it got too hairy as I started that. Once vfio-ccw is no longer >> considered unique, those cleanups can happen at our leisure. >> >> Patch 6 removes the trickery where vfio-ccw uses vfio_init_device instead of >> vfio_alloc_device, and thus removes vfio_init_device from the outside world. >> >> Patch 7 removes vfio_free_device from vfio-ccw and the other drivers (hello, >> CC list!), letting it be handled by vfio_device_release directly. > > Looks like another spin is pending, but the vfio core and collateral > changes in 6 and 7 look good to me. Would this go in through the vfio > or s390 tree? I'd be happy to merge or provide a branch, depending on > the route. > > For 6 & 7: > Acked-by: Alex Williamson <alex.williamson@redhat.com> > > Thanks, > Alex LGTM with those few comments addressed -- @Eric please send a v3 and I think it's ready. I would suggest vfio tree to reduce the chance of conflicts; this touches various vfio drivers (and main) with the last patches while the s390 hits are at least all contained to the vfio-ccw driver code.
On Thu, 2022-11-03 at 19:43 -0400, Matthew Rosato wrote: > On 11/3/22 5:56 PM, Alex Williamson wrote: > > On Wed, 2 Nov 2022 16:01:45 +0100 > > Eric Farman <farman@linux.ibm.com> wrote: > > > > > Hi all, > > > > > > Here is an update to the vfio-ccw lifecycle changes that have > > > been discussed > > > in various forms over the past year [1][2] or so, and which I > > > dusted off > > > recently. > > > > > > Patches 1-5 rework the behavior of the vfio-ccw driver's private > > > struct. > > > In summary, the mdev pieces are split out of vfio_ccw_private and > > > into a > > > new vfio_ccw_parent struct that will continue to follow today's > > > lifecycle. > > > The remainder (bulk) of the private struct moves to follow the > > > mdev > > > probe/remove pair. There's opportunity for further separation of > > > the > > > things in the private struct, which would simplify some of the > > > vfio-ccw > > > code, but it got too hairy as I started that. Once vfio-ccw is no > > > longer > > > considered unique, those cleanups can happen at our leisure. > > > > > > Patch 6 removes the trickery where vfio-ccw uses vfio_init_device > > > instead of > > > vfio_alloc_device, and thus removes vfio_init_device from the > > > outside world. > > > > > > Patch 7 removes vfio_free_device from vfio-ccw and the other > > > drivers (hello, > > > CC list!), letting it be handled by vfio_device_release directly. > > > > Looks like another spin is pending, but the vfio core and > > collateral > > changes in 6 and 7 look good to me. Would this go in through the > > vfio > > or s390 tree? I'd be happy to merge or provide a branch, depending > > on > > the route. > > > > For 6 & 7: > > Acked-by: Alex Williamson <alex.williamson@redhat.com> > > > > Thanks, > > Alex > > LGTM with those few comments addressed -- @Eric please send a v3 and > I think it's ready. Will do that now; thanks Matt. > > I would suggest vfio tree to reduce the chance of conflicts; this > touches various vfio drivers (and main) with the last patches while > the s390 hits are at least all contained to the vfio-ccw driver code. > Agreed. Thanks to you both.