| Message ID | 5a8b9f48-2c32-8177-1c18-e3bd7bfde558@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [PULL,v2] gvt-next | expand |
On Wed, Apr 20, 2022 at 04:34:47PM +0000, Wang, Zhi A wrote: > Hi folks: > > Here is the PR of gvt-next. Thanks so much for the patience. > > Mostly it includes the patch bundle of GVT-g re-factor patches for adapting the GVT-g with the > new MDEV interfaces: > > - Separating the MMIO table from GVT-g. (Zhi) > - GVT-g re-factor. (Christoph) > - GVT-g mdev API cleanup. (Jason) > - GVT-g trace/makefile cleanup. (Jani) > > Thanks so much for making this happen. > > This PR has been tested as following and no problem shows up: > > $dim update-branches > $dim apply-pull drm-intel-next < this_email.eml > > The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17: > > Linux 5.18-rc1 (2022-04-03 14:08:21 -0700) > > are available in the Git repository at: > > https://github.com/intel/gvt-linux tags/gvt-next-2022-04-20-for-christoph > > for you to fetch changes up to ae7875879b7c838bffb42ed6db4658e5c504032e: > > vfio/mdev: Remove mdev drvdata (2022-04-20 03:15:58 -0400) This looks well constructed now! thanks Alex you can pull this for VFIO after Jani&co grab it I'll respin my vfio_group series on top of this branch Jason
On Wed, 20 Apr 2022 13:43:51 -0300 Jason Gunthorpe <jgg@nvidia.com> wrote: > On Wed, Apr 20, 2022 at 04:34:47PM +0000, Wang, Zhi A wrote: > > Hi folks: > > > > Here is the PR of gvt-next. Thanks so much for the patience. > > > > Mostly it includes the patch bundle of GVT-g re-factor patches for adapting the GVT-g with the > > new MDEV interfaces: > > > > - Separating the MMIO table from GVT-g. (Zhi) > > - GVT-g re-factor. (Christoph) > > - GVT-g mdev API cleanup. (Jason) > > - GVT-g trace/makefile cleanup. (Jani) > > > > Thanks so much for making this happen. > > > > This PR has been tested as following and no problem shows up: > > > > $dim update-branches > > $dim apply-pull drm-intel-next < this_email.eml > > > > The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17: > > > > Linux 5.18-rc1 (2022-04-03 14:08:21 -0700) > > > > are available in the Git repository at: > > > > https://github.com/intel/gvt-linux tags/gvt-next-2022-04-20-for-christoph > > > > for you to fetch changes up to ae7875879b7c838bffb42ed6db4658e5c504032e: > > > > vfio/mdev: Remove mdev drvdata (2022-04-20 03:15:58 -0400) > > This looks well constructed now! thanks > > Alex you can pull this for VFIO after Jani&co grab it > > I'll respin my vfio_group series on top of this branch Sure, so just to confirm tags/gvt-next-2022-04-20-for-christoph is pruned down to exactly the commits we're looking for now? Thanks, Alex
On Wed, Apr 20, 2022 at 11:40:33AM -0600, Alex Williamson wrote: > On Wed, 20 Apr 2022 13:43:51 -0300 > Jason Gunthorpe <jgg@nvidia.com> wrote: > > > On Wed, Apr 20, 2022 at 04:34:47PM +0000, Wang, Zhi A wrote: > > > Hi folks: > > > > > > Here is the PR of gvt-next. Thanks so much for the patience. > > > > > > Mostly it includes the patch bundle of GVT-g re-factor patches for adapting the GVT-g with the > > > new MDEV interfaces: > > > > > > - Separating the MMIO table from GVT-g. (Zhi) > > > - GVT-g re-factor. (Christoph) > > > - GVT-g mdev API cleanup. (Jason) > > > - GVT-g trace/makefile cleanup. (Jani) > > > > > > Thanks so much for making this happen. > > > > > > This PR has been tested as following and no problem shows up: > > > > > > $dim update-branches > > > $dim apply-pull drm-intel-next < this_email.eml > > > > > > The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17: > > > > > > Linux 5.18-rc1 (2022-04-03 14:08:21 -0700) > > > > > > are available in the Git repository at: > > > > > > https://github.com/intel/gvt-linux tags/gvt-next-2022-04-20-for-christoph > > > > > > for you to fetch changes up to ae7875879b7c838bffb42ed6db4658e5c504032e: > > > > > > vfio/mdev: Remove mdev drvdata (2022-04-20 03:15:58 -0400) > > > > This looks well constructed now! thanks > > > > Alex you can pull this for VFIO after Jani&co grab it > > > > I'll respin my vfio_group series on top of this branch > > Sure, so just to confirm tags/gvt-next-2022-04-20-for-christoph is > pruned down to exactly the commits we're looking for now? Thanks, Yes, the above is correct and the tag points to commit ae7875879b7c838bffb42ed6db4658e5c504032e It is the bare minimum series Thanks, Jason
On Wed, Apr 20, 2022 at 02:46:00PM -0300, Jason Gunthorpe wrote: > On Wed, Apr 20, 2022 at 11:40:33AM -0600, Alex Williamson wrote: > > On Wed, 20 Apr 2022 13:43:51 -0300 > > Jason Gunthorpe <jgg@nvidia.com> wrote: > > > > > On Wed, Apr 20, 2022 at 04:34:47PM +0000, Wang, Zhi A wrote: > > > > Hi folks: > > > > > > > > Here is the PR of gvt-next. Thanks so much for the patience. > > > > > > > > Mostly it includes the patch bundle of GVT-g re-factor patches for adapting the GVT-g with the > > > > new MDEV interfaces: > > > > > > > > - Separating the MMIO table from GVT-g. (Zhi) > > > > - GVT-g re-factor. (Christoph) > > > > - GVT-g mdev API cleanup. (Jason) > > > > - GVT-g trace/makefile cleanup. (Jani) > > > > > > > > Thanks so much for making this happen. > > > > > > > > This PR has been tested as following and no problem shows up: > > > > > > > > $dim update-branches > > > > $dim apply-pull drm-intel-next < this_email.eml > > > > > > > > The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17: > > > > > > > > Linux 5.18-rc1 (2022-04-03 14:08:21 -0700) > > > > > > > > are available in the Git repository at: > > > > > > > > https://github.com/intel/gvt-linux tags/gvt-next-2022-04-20-for-christoph > > > > > > > > for you to fetch changes up to ae7875879b7c838bffb42ed6db4658e5c504032e: > > > > > > > > vfio/mdev: Remove mdev drvdata (2022-04-20 03:15:58 -0400) > > > > > > This looks well constructed now! thanks > > > > > > Alex you can pull this for VFIO after Jani&co grab it > > > > > > I'll respin my vfio_group series on top of this branch > > > > Sure, so just to confirm tags/gvt-next-2022-04-20-for-christoph is > > pruned down to exactly the commits we're looking for now? Thanks, > > Yes, the above is correct and the tag points to commit > ae7875879b7c838bffb42ed6db4658e5c504032e > > It is the bare minimum series Actually this topic branch doesn't compile: ../drivers/gpu/drm/i915/intel_gvt_mmio_table.c:7:10: fatal error: 'display/intel_dmc_regs.h' file not found #include "display/intel_dmc_regs.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. :( :( This is the merge conflict that was mentioned. This topic branch needs to delete the above intel_dmc_regs.h include file When drm-intel-next merges this PR then need to add it back as part of the merge resolution - so explain this in the PR text above and include a diff that does it when you send it again. (or do the merge yourself as I showed before, it depends on what drm-intel-next wants) Jason
On 4/20/22 8:00 PM, Jason Gunthorpe wrote: > On Wed, Apr 20, 2022 at 02:46:00PM -0300, Jason Gunthorpe wrote: >> On Wed, Apr 20, 2022 at 11:40:33AM -0600, Alex Williamson wrote: >>> On Wed, 20 Apr 2022 13:43:51 -0300 >>> Jason Gunthorpe <jgg@nvidia.com> wrote: >>> >>>> On Wed, Apr 20, 2022 at 04:34:47PM +0000, Wang, Zhi A wrote: >>>>> Hi folks: >>>>> >>>>> Here is the PR of gvt-next. Thanks so much for the patience. >>>>> >>>>> Mostly it includes the patch bundle of GVT-g re-factor patches for adapting the GVT-g with the >>>>> new MDEV interfaces: >>>>> >>>>> - Separating the MMIO table from GVT-g. (Zhi) >>>>> - GVT-g re-factor. (Christoph) >>>>> - GVT-g mdev API cleanup. (Jason) >>>>> - GVT-g trace/makefile cleanup. (Jani) >>>>> >>>>> Thanks so much for making this happen. >>>>> >>>>> This PR has been tested as following and no problem shows up: >>>>> >>>>> $dim update-branches >>>>> $dim apply-pull drm-intel-next < this_email.eml >>>>> >>>>> The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17: >>>>> >>>>> Linux 5.18-rc1 (2022-04-03 14:08:21 -0700) >>>>> >>>>> are available in the Git repository at: >>>>> >>>>> https://github.com/intel/gvt-linux tags/gvt-next-2022-04-20-for-christoph >>>>> >>>>> for you to fetch changes up to ae7875879b7c838bffb42ed6db4658e5c504032e: >>>>> >>>>> vfio/mdev: Remove mdev drvdata (2022-04-20 03:15:58 -0400) >>>> >>>> This looks well constructed now! thanks >>>> >>>> Alex you can pull this for VFIO after Jani&co grab it >>>> >>>> I'll respin my vfio_group series on top of this branch >>> >>> Sure, so just to confirm tags/gvt-next-2022-04-20-for-christoph is >>> pruned down to exactly the commits we're looking for now? Thanks, >> >> Yes, the above is correct and the tag points to commit >> ae7875879b7c838bffb42ed6db4658e5c504032e >> >> It is the bare minimum series > > Actually this topic branch doesn't compile: > > ../drivers/gpu/drm/i915/intel_gvt_mmio_table.c:7:10: fatal error: 'display/intel_dmc_regs.h' file not found > #include "display/intel_dmc_regs.h" > ^~~~~~~~~~~~~~~~~~~~~~~~~~ > 1 error generated. > > :( :( > > This is the merge conflict that was mentioned. This topic branch needs > to delete the above intel_dmc_regs.h include file > > When drm-intel-next merges this PR then need to add it back as part of > the merge resolution - so explain this in the PR text above and > include a diff that does it when you send it again. (or do the merge > yourself as I showed before, it depends on what drm-intel-next wants) > Hi Jason: Is it possible that I can send two different pull based on the same branch? I was thinking I can remove this line in the original patch and then add a small patch to add this line back on the top. Then make two different tags before and after that small patch, send one pull with tag that includes that small patch to i915 and the other pull with tag that doesn't includes it to VFIO? Thanks, Zhi. > Jason >
+ Tvrtko Quoting Christoph Hellwig (2022-04-21 08:47:38) > On Thu, Apr 21, 2022 at 04:57:34AM +0000, Wang, Zhi A wrote: > > Is it possible that I can send two different pull based on the same branch? > > I was thinking I can remove this line in the original patch and then add a > > small patch to add this line back on the top. Then make two different tags > > before and after that small patch, send one pull with tag that includes that > > small patch to i915 and the other pull with tag that doesn't includes it to > > VFIO? > > Yes, you can do that as long as the small fixup commit is the very last > one.
On Thu, Apr 21, 2022 at 09:41:30AM +0300, Joonas Lahtinen wrote: > + Tvrtko > > Quoting Christoph Hellwig (2022-04-21 08:47:38) > > On Thu, Apr 21, 2022 at 04:57:34AM +0000, Wang, Zhi A wrote: > > > Is it possible that I can send two different pull based on the same branch? > > > I was thinking I can remove this line in the original patch and then add a > > > small patch to add this line back on the top. Then make two different tags > > > before and after that small patch, send one pull with tag that includes that > > > small patch to i915 and the other pull with tag that doesn't includes it to > > > VFIO? > > > > Yes, you can do that as long as the small fixup commit is the very last > > one. Keep in mind when doing this that best practice is for every commit to compile. So if you add a commit with a new #include to this topic branch that commit will not compile. Best practice is to fix the compilation breakage in a merge commit, either created by you or created by your upstream. Jason
On 4/21/22 1:14 PM, Jason Gunthorpe wrote: > On Thu, Apr 21, 2022 at 09:41:30AM +0300, Joonas Lahtinen wrote: >> + Tvrtko >> >> Quoting Christoph Hellwig (2022-04-21 08:47:38) >>> On Thu, Apr 21, 2022 at 04:57:34AM +0000, Wang, Zhi A wrote: >>>> Is it possible that I can send two different pull based on the same branch? >>>> I was thinking I can remove this line in the original patch and then add a >>>> small patch to add this line back on the top. Then make two different tags >>>> before and after that small patch, send one pull with tag that includes that >>>> small patch to i915 and the other pull with tag that doesn't includes it to >>>> VFIO? >>> >>> Yes, you can do that as long as the small fixup commit is the very last >>> one. > > Keep in mind when doing this that best practice is for every commit to > compile. > > So if you add a commit with a new #include to this topic branch that > commit will not compile. > > Best practice is to fix the compilation breakage in a merge commit, > either created by you or created by your upstream. > I see. Let me update it. > Jason >
Hi folks: Here is the PR of gvt-next. Thanks so much for the patience. Mostly it includes the patch bundle of GVT-g re-factor patches for adapting the GVT-g with the new MDEV interfaces: - Separating the MMIO table from GVT-g. (Zhi) - GVT-g re-factor. (Christoph) - GVT-g mdev API cleanup. (Jason) - GVT-g trace/makefile cleanup. (Jani) Thanks so much for making this happen. This PR has been tested as following and no problem shows up: $dim update-branches $dim apply-pull drm-intel-next < this_email.eml The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17: Linux 5.18-rc1 (2022-04-03 14:08:21 -0700) are available in the Git repository at: https://github.com/intel/gvt-linux tags/gvt-next-2022-04-20-for-christoph for you to fetch changes up to ae7875879b7c838bffb42ed6db4658e5c504032e: vfio/mdev: Remove mdev drvdata (2022-04-20 03:15:58 -0400) ---------------------------------------------------------------- gvt-next-2022-04-22-for-christoph - Separating the MMIO table from GVT-g. (Zhi) - GVT-g re-factor. (Christoph) - GVT-g mdev API cleanup. (Jason) - GVT-g trace/makefile cleanup. (Jani) ---------------------------------------------------------------- Christoph Hellwig (27): drm/i915/gvt: remove module refcounting in intel_gvt_{,un}register_hypervisor drm/i915/gvt: remove enum hypervisor_type drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops drm/i915/gvt: move the gvt code into kvmgt.ko drm/i915/gvt: remove intel_gvt_ops drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops drm/i915/gvt: remove the unused from_virt_to_mfn op drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpu drm/i915/gvt: remove vgpu->handle drm/i915/gvt: devirtualize ->{read,write}_gpa drm/i915/gvt: devirtualize ->{get,put}_vfio_device drm/i915/gvt: devirtualize ->set_edid and ->set_opregion drm/i915/gvt: devirtualize ->detach_vgpu drm/i915/gvt: devirtualize ->inject_msi drm/i915/gvt: devirtualize ->is_valid_gfn drm/i915/gvt: devirtualize ->gfn_to_mfn drm/i915/gvt: devirtualize ->{enable,disable}_page_track drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page drm/i915/gvt: devirtualize dma_pin_guest_page drm/i915/gvt: remove struct intel_gvt_mpt drm/i915/gvt: remove the extra vfio_device refcounting for dmabufs drm/i915/gvt: streamline intel_vgpu_create drm/i915/gvt: pass a struct intel_vgpu to the vfio read/write helpers drm/i915/gvt: remove kvmgt_guest_{init,exit} drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev drm/i915/gvt: merge gvt.c into kvmgvt.c Jani Nikula (2): drm/i915/gvt: fix trace TRACE_INCLUDE_PATH drm/i915/gvt: better align the Makefile with i915 Makefile Jason Gunthorpe (5): vfio/mdev: Remove vfio_mdev.c vfio/mdev: Remove mdev_parent_ops dev_attr_groups vfio/mdev: Remove mdev_parent_ops vfio/mdev: Use the driver core to create the 'remove' file vfio/mdev: Remove mdev drvdata Zhi Wang (3): i915/gvt: Separate the MMIO tracking table from GVT-g i915/gvt: Save the initial HW state snapshot in i915 i915/gvt: Use the initial HW state snapshot saved in i915 Documentation/driver-api/vfio-mediated-device.rst | 27 +- drivers/gpu/drm/i915/Kconfig | 36 +- drivers/gpu/drm/i915/Makefile | 8 +- drivers/gpu/drm/i915/gvt/Makefile | 30 +- drivers/gpu/drm/i915/gvt/cfg_space.c | 89 +- drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 +- drivers/gpu/drm/i915/gvt/dmabuf.c | 36 +- drivers/gpu/drm/i915/gvt/execlist.c | 12 +- drivers/gpu/drm/i915/gvt/firmware.c | 25 +- drivers/gpu/drm/i915/gvt/gtt.c | 55 +- drivers/gpu/drm/i915/gvt/gvt.c | 340 ------ drivers/gpu/drm/i915/gvt/gvt.h | 128 +- drivers/gpu/drm/i915/gvt/handlers.c | 1033 +++------------- drivers/gpu/drm/i915/gvt/hypercall.h | 82 -- drivers/gpu/drm/i915/gvt/interrupt.c | 40 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 1097 +++++++++-------- drivers/gpu/drm/i915/gvt/mmio.c | 4 +- drivers/gpu/drm/i915/gvt/mmio.h | 1 - drivers/gpu/drm/i915/gvt/mpt.h | 400 ------- drivers/gpu/drm/i915/gvt/opregion.c | 148 +-- drivers/gpu/drm/i915/gvt/page_track.c | 8 +- drivers/gpu/drm/i915/gvt/reg.h | 9 +- drivers/gpu/drm/i915/gvt/scheduler.c | 37 +- drivers/gpu/drm/i915/gvt/trace.h | 2 +- drivers/gpu/drm/i915/gvt/vgpu.c | 22 +- drivers/gpu/drm/i915/i915_driver.c | 7 - drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/intel_gvt.c | 248 +++- drivers/gpu/drm/i915/intel_gvt.h | 32 +- drivers/gpu/drm/i915/intel_gvt_mmio_table.c | 1292 +++++++++++++++++++++ drivers/s390/cio/vfio_ccw_ops.c | 7 +- drivers/s390/crypto/vfio_ap_ops.c | 9 +- drivers/vfio/mdev/Makefile | 2 +- drivers/vfio/mdev/mdev_core.c | 52 +- drivers/vfio/mdev/mdev_driver.c | 10 - drivers/vfio/mdev/mdev_private.h | 6 +- drivers/vfio/mdev/mdev_sysfs.c | 37 +- drivers/vfio/mdev/vfio_mdev.c | 152 --- include/linux/mdev.h | 82 +- samples/vfio-mdev/mbochs.c | 9 +- samples/vfio-mdev/mdpy.c | 9 +- samples/vfio-mdev/mtty.c | 39 +- 42 files changed, 2531 insertions(+), 3138 deletions(-) delete mode 100644 drivers/gpu/drm/i915/gvt/gvt.c delete mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h delete mode 100644 drivers/gpu/drm/i915/gvt/mpt.h create mode 100644 drivers/gpu/drm/i915/intel_gvt_mmio_table.c delete mode 100644 drivers/vfio/mdev/vfio_mdev.c