| Message ID | 20220630203647.2529815-1-farman@linux.ibm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | s390/vfio-ccw rework | expand |
On Thu, Jun 30, 2022 at 10:36:36PM +0200, Eric Farman wrote: > Here's an updated pass through the first chunk of vfio-ccw rework. > > As with v2, this is all internal to vfio-ccw, with the exception of > the removal of mdev_uuid from include/linux/mdev.h in patch 1. > > There is one conflict with the vfio-next branch [2], on patch 6. What tree do you plan to take it through? > The remainder of the work that Jason Gunthorpe originally started [1] > in this space remains for a future day. Lets see.. These were already applied: vfio/ccw: Remove unneeded GFP_DMA vfio/ccw: Use functions for alloc/free of the vfio_ccw_private vfio/ccw: Pass vfio_ccw_private not mdev_device to various functions vfio/ccw: Convert to use vfio_register_emulated_iommu_dev() This series replaces this one: vfio/ccw: Make the FSM complete and synchronize it to the mdev Christoph recently re-posted this: https://lore.kernel.org/kvm/20220628051435.695540-10-hch@lst.de/ vfio/mdev: Consolidate all the device_api sysfs into the core code So this is still left ? vfio/ccw: Remove private->mdev vfio: Export vfio_device_try_get() vfio/ccw: Move the lifecycle of the struct vfio_ccw_private to the mdev IIRC Kevin's team needs those for their device FD patches? Thanks, Jason
On Thu, 2022-06-30 at 20:44 -0300, Jason Gunthorpe wrote: > On Thu, Jun 30, 2022 at 10:36:36PM +0200, Eric Farman wrote: > > Here's an updated pass through the first chunk of vfio-ccw rework. > > > > As with v2, this is all internal to vfio-ccw, with the exception of > > the removal of mdev_uuid from include/linux/mdev.h in patch 1. > > > > There is one conflict with the vfio-next branch [2], on patch 6. > > What tree do you plan to take it through? Don't know. I know Matt's PCI series has a conflict with this same patch also, but I haven't seen resolution to that. @Christian, thoughts? > > > The remainder of the work that Jason Gunthorpe originally started > > [1] > > in this space remains for a future day. > > Lets see.. These were already applied: > > vfio/ccw: Remove unneeded GFP_DMA > vfio/ccw: Use functions for alloc/free of the vfio_ccw_private > vfio/ccw: Pass vfio_ccw_private not mdev_device to various > functions > vfio/ccw: Convert to use vfio_register_emulated_iommu_dev() > > This series replaces this one: > vfio/ccw: Make the FSM complete and synchronize it to the mdev > > Christoph recently re-posted this: > https://lore.kernel.org/kvm/20220628051435.695540-10-hch@lst.de/ > vfio/mdev: Consolidate all the device_api sysfs into the core code Correct. Same for "vfio/mdev: Add mdev available instance checking to the core" which you originally had proposed. > > So this is still left ? > vfio/ccw: Remove private->mdev This is by this series (patch 1-4). > vfio: Export vfio_device_try_get() > vfio/ccw: Move the lifecycle of the struct vfio_ccw_private to the > mdev > > IIRC Kevin's team needs those for their device FD patches? That's my understanding too. > > Thanks, > Jason
Am 01.07.22 um 14:40 schrieb Eric Farman: > On Thu, 2022-06-30 at 20:44 -0300, Jason Gunthorpe wrote: >> On Thu, Jun 30, 2022 at 10:36:36PM +0200, Eric Farman wrote: >>> Here's an updated pass through the first chunk of vfio-ccw rework. >>> >>> As with v2, this is all internal to vfio-ccw, with the exception of >>> the removal of mdev_uuid from include/linux/mdev.h in patch 1. >>> >>> There is one conflict with the vfio-next branch [2], on patch 6. >> >> What tree do you plan to take it through? > > Don't know. I know Matt's PCI series has a conflict with this same > patch also, but I haven't seen resolution to that. @Christian, > thoughts? What about me making a topic branch that it being merged by Alex AND the KVM tree so that each of the conflicts can be solved in that way?
On 2022/7/1 20:40, Eric Farman wrote: > On Thu, 2022-06-30 at 20:44 -0300, Jason Gunthorpe wrote: >> On Thu, Jun 30, 2022 at 10:36:36PM +0200, Eric Farman wrote: >>> Here's an updated pass through the first chunk of vfio-ccw rework. >>> >>> As with v2, this is all internal to vfio-ccw, with the exception of >>> the removal of mdev_uuid from include/linux/mdev.h in patch 1. >>> >>> There is one conflict with the vfio-next branch [2], on patch 6. >> >> What tree do you plan to take it through? > > Don't know. I know Matt's PCI series has a conflict with this same > patch also, but I haven't seen resolution to that. @Christian, > thoughts? > >> >>> The remainder of the work that Jason Gunthorpe originally started >>> [1] >>> in this space remains for a future day. >> >> Lets see.. These were already applied: >> >> vfio/ccw: Remove unneeded GFP_DMA >> vfio/ccw: Use functions for alloc/free of the vfio_ccw_private >> vfio/ccw: Pass vfio_ccw_private not mdev_device to various >> functions >> vfio/ccw: Convert to use vfio_register_emulated_iommu_dev() >> >> This series replaces this one: >> vfio/ccw: Make the FSM complete and synchronize it to the mdev >> >> Christoph recently re-posted this: >> https://lore.kernel.org/kvm/20220628051435.695540-10-hch@lst.de/ >> vfio/mdev: Consolidate all the device_api sysfs into the core code > > Correct. Same for "vfio/mdev: Add mdev available instance checking to > the core" which you originally had proposed. > >> >> So this is still left ? >> vfio/ccw: Remove private->mdev > > This is by this series (patch 1-4). > >> vfio: Export vfio_device_try_get() >> vfio/ccw: Move the lifecycle of the struct vfio_ccw_private to the >> mdev >> >> IIRC Kevin's team needs those for their device FD patches? > > That's my understanding too. yes. You two have great memory. My vfio cdev patches relies on these two patches. So far, my branch doesn't cover ccw. Do you have plan to incorporate them? I would like to apply your ccw series to below branch. https://github.com/luxis1999/iommufd/commit/e6e52d0d2bba6510c0a9fec8184d5f169a50fda2 >> >> Thanks, >> Jason >
On Fri, Jul 01, 2022 at 02:48:25PM +0200, Christian Borntraeger wrote: > Am 01.07.22 um 14:40 schrieb Eric Farman: > > On Thu, 2022-06-30 at 20:44 -0300, Jason Gunthorpe wrote: > > > On Thu, Jun 30, 2022 at 10:36:36PM +0200, Eric Farman wrote: > > > > Here's an updated pass through the first chunk of vfio-ccw rework. > > > > > > > > As with v2, this is all internal to vfio-ccw, with the exception of > > > > the removal of mdev_uuid from include/linux/mdev.h in patch 1. > > > > > > > > There is one conflict with the vfio-next branch [2], on patch 6. > > > > > > What tree do you plan to take it through? > > > > Don't know. I know Matt's PCI series has a conflict with this same > > patch also, but I haven't seen resolution to that. @Christian, > > thoughts? > > > What about me making a topic branch that it being merged by Alex AND the KVM tree > so that each of the conflicts can be solved in that way? It make sense, I would base it on Alex's VFIO tree just to avoid some conflicts in the first place. Matt can rebase on this, so lets get things going? Jason
Am 04.07.22 um 13:25 schrieb Jason Gunthorpe: > On Fri, Jul 01, 2022 at 02:48:25PM +0200, Christian Borntraeger wrote: > >> Am 01.07.22 um 14:40 schrieb Eric Farman: >>> On Thu, 2022-06-30 at 20:44 -0300, Jason Gunthorpe wrote: >>>> On Thu, Jun 30, 2022 at 10:36:36PM +0200, Eric Farman wrote: >>>>> Here's an updated pass through the first chunk of vfio-ccw rework. >>>>> >>>>> As with v2, this is all internal to vfio-ccw, with the exception of >>>>> the removal of mdev_uuid from include/linux/mdev.h in patch 1. >>>>> >>>>> There is one conflict with the vfio-next branch [2], on patch 6. >>>> >>>> What tree do you plan to take it through? >>> >>> Don't know. I know Matt's PCI series has a conflict with this same >>> patch also, but I haven't seen resolution to that. @Christian, >>> thoughts? >> >> >> What about me making a topic branch that it being merged by Alex AND the KVM tree >> so that each of the conflicts can be solved in that way? > > It make sense, I would base it on Alex's VFIO tree just to avoid > some conflicts in the first place. Matt can rebase on this, so lets > get things going? So yes. Lets rebase on VFIO-next. Ideally Alex would then directly pick Eric patches.
On 7/7/22 5:06 AM, Christian Borntraeger wrote: > > > Am 04.07.22 um 13:25 schrieb Jason Gunthorpe: >> On Fri, Jul 01, 2022 at 02:48:25PM +0200, Christian Borntraeger wrote: >> >>> Am 01.07.22 um 14:40 schrieb Eric Farman: >>>> On Thu, 2022-06-30 at 20:44 -0300, Jason Gunthorpe wrote: >>>>> On Thu, Jun 30, 2022 at 10:36:36PM +0200, Eric Farman wrote: >>>>>> Here's an updated pass through the first chunk of vfio-ccw rework. >>>>>> >>>>>> As with v2, this is all internal to vfio-ccw, with the exception of >>>>>> the removal of mdev_uuid from include/linux/mdev.h in patch 1. >>>>>> >>>>>> There is one conflict with the vfio-next branch [2], on patch 6. >>>>> >>>>> What tree do you plan to take it through? >>>> >>>> Don't know. I know Matt's PCI series has a conflict with this same >>>> patch also, but I haven't seen resolution to that. @Christian, >>>> thoughts? >>> >>> >>> What about me making a topic branch that it being merged by Alex AND >>> the KVM tree >>> so that each of the conflicts can be solved in that way? >> >> It make sense, I would base it on Alex's VFIO tree just to avoid >> some conflicts in the first place. Matt can rebase on this, so lets >> get things going? > > So yes. Lets rebase on VFIO-next. Ideally Alex would then directly pick > Eric > patches. @Christian to be clear, do you want me to also rebase the zPCI series on vfio-next then?
Am 07.07.22 um 14:34 schrieb Matthew Rosato: > On 7/7/22 5:06 AM, Christian Borntraeger wrote: >> >> >> Am 04.07.22 um 13:25 schrieb Jason Gunthorpe: >>> On Fri, Jul 01, 2022 at 02:48:25PM +0200, Christian Borntraeger wrote: >>> >>>> Am 01.07.22 um 14:40 schrieb Eric Farman: >>>>> On Thu, 2022-06-30 at 20:44 -0300, Jason Gunthorpe wrote: >>>>>> On Thu, Jun 30, 2022 at 10:36:36PM +0200, Eric Farman wrote: >>>>>>> Here's an updated pass through the first chunk of vfio-ccw rework. >>>>>>> >>>>>>> As with v2, this is all internal to vfio-ccw, with the exception of >>>>>>> the removal of mdev_uuid from include/linux/mdev.h in patch 1. >>>>>>> >>>>>>> There is one conflict with the vfio-next branch [2], on patch 6. >>>>>> >>>>>> What tree do you plan to take it through? >>>>> >>>>> Don't know. I know Matt's PCI series has a conflict with this same >>>>> patch also, but I haven't seen resolution to that. @Christian, >>>>> thoughts? >>>> >>>> >>>> What about me making a topic branch that it being merged by Alex AND the KVM tree >>>> so that each of the conflicts can be solved in that way? >>> >>> It make sense, I would base it on Alex's VFIO tree just to avoid >>> some conflicts in the first place. Matt can rebase on this, so lets >>> get things going? >> >> So yes. Lets rebase on VFIO-next. Ideally Alex would then directly pick Eric >> patches. > > @Christian to be clear, do you want me to also rebase the zPCI series on vfio-next then? For that we are probably better of me having a topic branch that is then merged by Alex and Paolo. Alex, Paolo, would be make sense? As an alternative: will the vfio patches build without the KVM patches and vice versa, I assume not?
On 7/7/22 9:04 AM, Christian Borntraeger wrote: > Am 07.07.22 um 14:34 schrieb Matthew Rosato: >> On 7/7/22 5:06 AM, Christian Borntraeger wrote: >>> >>> >>> Am 04.07.22 um 13:25 schrieb Jason Gunthorpe: >>>> On Fri, Jul 01, 2022 at 02:48:25PM +0200, Christian Borntraeger wrote: >>>> >>>>> Am 01.07.22 um 14:40 schrieb Eric Farman: >>>>>> On Thu, 2022-06-30 at 20:44 -0300, Jason Gunthorpe wrote: >>>>>>> On Thu, Jun 30, 2022 at 10:36:36PM +0200, Eric Farman wrote: >>>>>>>> Here's an updated pass through the first chunk of vfio-ccw rework. >>>>>>>> >>>>>>>> As with v2, this is all internal to vfio-ccw, with the exception of >>>>>>>> the removal of mdev_uuid from include/linux/mdev.h in patch 1. >>>>>>>> >>>>>>>> There is one conflict with the vfio-next branch [2], on patch 6. >>>>>>> >>>>>>> What tree do you plan to take it through? >>>>>> >>>>>> Don't know. I know Matt's PCI series has a conflict with this same >>>>>> patch also, but I haven't seen resolution to that. @Christian, >>>>>> thoughts? >>>>> >>>>> >>>>> What about me making a topic branch that it being merged by Alex >>>>> AND the KVM tree >>>>> so that each of the conflicts can be solved in that way? >>>> >>>> It make sense, I would base it on Alex's VFIO tree just to avoid >>>> some conflicts in the first place. Matt can rebase on this, so lets >>>> get things going? >>> >>> So yes. Lets rebase on VFIO-next. Ideally Alex would then directly >>> pick Eric >>> patches. >> >> @Christian to be clear, do you want me to also rebase the zPCI series >> on vfio-next then? > > For that we are probably better of me having a topic branch that is then > merged by Alex > and Paolo. Alex, Paolo, would be make sense? For reference if needed, the zPCI series in question: https://lore.kernel.org/linux-s390/20220606203325.110625-1-mjrosato@linux.ibm.com/ > > As an alternative: will the vfio patches build without the KVM patches > and vice versa, > I assume not? No, there are dependencies in both directions. At this point if the topic branch is how we will proceed then I suggest just taking v9 as-is; the few minor nit comments from Pierre can be addressed as follow-ons if desired.
Here's an updated pass through the first chunk of vfio-ccw rework. As with v2, this is all internal to vfio-ccw, with the exception of the removal of mdev_uuid from include/linux/mdev.h in patch 1. There is one conflict with the vfio-next branch [2], on patch 6. The remainder of the work that Jason Gunthorpe originally started [1] in this space remains for a future day. v2-v3: - [KW, MR, JG] Added r-b's (Thank You!) - Patch 7 (new): - [MR] Add better debug to fsm_notoper - Patch 8: - [MR] Call fsm_notoper for the OPEN event from STANDBY state - [EF] Drop FSM state=STANDBY in vfio_ccw_sch_probe() (it is handled in FSM, and was dropped by patch 10) - Patch 9: - [MR] Call fsm_close for the CLOSE event from STANDBY state v2: https://lore.kernel.org/r/20220615203318.3830778-1-farman@linux.ibm.com/ v1: https://lore.kernel.org/r/20220602171948.2790690-1-farman@linux.ibm.com/ Footnotes: [1] https://lore.kernel.org/r/0-v3-57c1502c62fd+2190-ccw_mdev_jgg@nvidia.com/ Cc: Kirti Wankhede <kwankhede@nvidia.com> Eric Farman (10): vfio/ccw: Fix FSM state if mdev probe fails vfio/ccw: Do not change FSM state in subchannel event vfio/ccw: Remove private->mdev vfio/ccw: Pass enum to FSM event jumptable vfio/ccw: Flatten MDEV device (un)register vfio/ccw: Update trace data for not operational event vfio/ccw: Create an OPEN FSM Event vfio/ccw: Create a CLOSE FSM event vfio/ccw: Refactor vfio_ccw_mdev_reset vfio/ccw: Move FSM open/close to MDEV open/close Michael Kawano (1): vfio/ccw: Remove UUID from s390 debug log drivers/s390/cio/vfio_ccw_async.c | 1 - drivers/s390/cio/vfio_ccw_drv.c | 59 +++++------------- drivers/s390/cio/vfio_ccw_fsm.c | 97 ++++++++++++++++++++++++----- drivers/s390/cio/vfio_ccw_ops.c | 77 +++++++---------------- drivers/s390/cio/vfio_ccw_private.h | 9 +-- include/linux/mdev.h | 5 -- 6 files changed, 123 insertions(+), 125 deletions(-)