| Message ID | 18c3c1b1-6f78-6140-4ec8-e18bc7916352@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [PULL] gvt-next | expand |
On Wed, Apr 20, 2022 at 08:04:31AM +0000, Wang, Zhi A wrote: > Hi folks: > > Here is the PR of gvt-next. > > 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 b39d2c6202426b560641e5800c5523851b5db586: > > drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush (2022-04-13 17:20:49 +0300) ?? Why did you rebase this again? It needs to be on a rc release tag as you had in your github, not whatever this is. Jason
On 4/20/22 12:13 PM, Jason Gunthorpe wrote: > On Wed, Apr 20, 2022 at 08:04:31AM +0000, Wang, Zhi A wrote: >> Hi folks: >> >> Here is the PR of gvt-next. >> >> 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 b39d2c6202426b560641e5800c5523851b5db586: >> >> drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush (2022-04-13 17:20:49 +0300) > > ?? > > Why did you rebase this again? It needs to be on a rc release tag as > you had in your github, not whatever this is. > Hi Jason: Here is what I understand, the pull going to the drm-intel-next needs to be based on drm-intel-next from the branch gvt-next. The pull going to the VFIO needs to be based on -rc, the topic/for-christoph brnach. So I did a merge from topic/for-christoph to my gvt-next branch and sent this pull, so that our QA can test these bundle on the gvt-staging branch. Sorry this is way too complicated to me. Let me prepare the new pull as what you ask. Shall I send the exact same pull to i915 and VFIO ? Thanks, Zhi. > Jason >
On Wed, Apr 20, 2022 at 02:41:04PM +0000, Wang, Zhi A wrote: > On 4/20/22 12:13 PM, Jason Gunthorpe wrote: > > On Wed, Apr 20, 2022 at 08:04:31AM +0000, Wang, Zhi A wrote: > >> Hi folks: > >> > >> Here is the PR of gvt-next. > >> > >> 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 b39d2c6202426b560641e5800c5523851b5db586: > >> > >> drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush (2022-04-13 17:20:49 +0300) > > > > ?? > > > > Why did you rebase this again? It needs to be on a rc release tag as > > you had in your github, not whatever this is. > > > Hi Jason: > > Here is what I understand, the pull going to the drm-intel-next > needs to be based on drm-intel-next from the branch gvt-next. No, there cannot be two pulls, as I explained when using topic branches you must never rebase. > The pull going to the VFIO needs to be based on -rc, the > topic/for-christoph brnach. Yes, so what you need to do is: # Get a clean tree on drm-intel-next $ git worktree add /tmp/gvt-next Preparing worktree (new branch 'gvt-next') $ cd /tmp/gvt-next $ git reset --hard b39d2c6202426b560641e5800c5523851b5db586 # drm-intel-next commit you tested # Merge Christoph's topic: $ git fetch https://github.com/intel/gvt-linux.git topic/for-christoph $ git merge FETCH_HEAD Auto-merging drivers/gpu/drm/i915/Makefile Auto-merging drivers/gpu/drm/i915/gvt/handlers.c Auto-merging drivers/gpu/drm/i915/i915_driver.c Auto-merging drivers/gpu/drm/i915/i915_drv.h Merge made by the 'ort' strategy. [.. Merge branch 'topic/for-christoph' of https://github.com/intel/gvt-linux into gvt-next # By Christoph Hellwig (27) and others # Via Zhi Wang * 'topic/for-christoph' of https://github.com/intel/gvt-linux: (37 commits) ] And then check it against what you prepared in this PR here: $ git diff HEAD 888471711a80b22c53547f3a625f20f487714f28 [empty] *do not rebase a topic branch* this is very important. Now - given that we can see there is no merge conflict you don't need to do anything! Just send topic/for-christoph, exactly as-it-is to drm-intel-next as a PR and that is all. > Sorry this is way too complicated to me. Let me prepare the new pull > as what you ask. Shall I send the exact same pull to i915 and VFIO ? Yes, exact same, this is important. You were very close before, the only issue was rebasing topic/for-christoph instead of merging. Jason
On 4/20/22 3:02 PM, Jason Gunthorpe wrote: > On Wed, Apr 20, 2022 at 02:41:04PM +0000, Wang, Zhi A wrote: >> On 4/20/22 12:13 PM, Jason Gunthorpe wrote: >>> On Wed, Apr 20, 2022 at 08:04:31AM +0000, Wang, Zhi A wrote: >>>> Hi folks: >>>> >>>> Here is the PR of gvt-next. >>>> >>>> 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 b39d2c6202426b560641e5800c5523851b5db586: >>>> >>>> drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush (2022-04-13 17:20:49 +0300) >>> >>> ?? >>> >>> Why did you rebase this again? It needs to be on a rc release tag as >>> you had in your github, not whatever this is. >>> >> Hi Jason: >> >> Here is what I understand, the pull going to the drm-intel-next >> needs to be based on drm-intel-next from the branch gvt-next. > > No, there cannot be two pulls, as I explained when using topic > branches you must never rebase. > >> The pull going to the VFIO needs to be based on -rc, the >> topic/for-christoph brnach. > > Yes, so what you need to do is: > > # Get a clean tree on drm-intel-next > $ git worktree add /tmp/gvt-next > Preparing worktree (new branch 'gvt-next') > $ cd /tmp/gvt-next > $ git reset --hard b39d2c6202426b560641e5800c5523851b5db586 # drm-intel-next commit you tested > > # Merge Christoph's topic: > $ git fetch https://github.com/intel/gvt-linux.git topic/for-christoph > $ git merge FETCH_HEAD > Auto-merging drivers/gpu/drm/i915/Makefile > Auto-merging drivers/gpu/drm/i915/gvt/handlers.c > Auto-merging drivers/gpu/drm/i915/i915_driver.c > Auto-merging drivers/gpu/drm/i915/i915_drv.h > Merge made by the 'ort' strategy. > Exactly what I did on my branch except that I sent the pull request based on my gvt-next. :( > [.. > Merge branch 'topic/for-christoph' of https://github.com/intel/gvt-linux into gvt-next > > # By Christoph Hellwig (27) and others > # Via Zhi Wang > * 'topic/for-christoph' of https://github.com/intel/gvt-linux: (37 commits) > ] > > And then check it against what you prepared in this PR here: > > $ git diff HEAD 888471711a80b22c53547f3a625f20f487714f28 > [empty] > > *do not rebase a topic branch* this is very important. > > Now - given that we can see there is no merge conflict you don't need > to do anything! Just send topic/for-christoph, exactly as-it-is to > drm-intel-next as a PR and that is all. > >> Sorry this is way too complicated to me. Let me prepare the new pull >> as what you ask. Shall I send the exact same pull to i915 and VFIO ? > > Yes, exact same, this is important. > > You were very close before, the only issue was rebasing > topic/for-christoph instead of merging. > I will send it by the end of the day. Thanks so much for your patience. > Jason >
Hi folks: Here is the PR of gvt-next. 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 b39d2c6202426b560641e5800c5523851b5db586: drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush (2022-04-13 17:20:49 +0300) are available in the Git repository at: https://github.com/intel/gvt-linux tags/gvt-next-2022-04-20 for you to fetch changes up to 888471711a80b22c53547f3a625f20f487714f28: vfio/mdev: Remove mdev drvdata (2022-04-20 03:20:16 -0400) ---------------------------------------------------------------- gvt-next-2022-04-20 - 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