All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: "Wang, Zhi A" <zhi.a.wang@intel.com>, Jason Gunthorpe <jgg@nvidia.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
	Christoph Hellwig <hch@lst.de>,
	"Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Zhenyu Wang <zhenyuw@linux.intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"intel-gvt-dev@lists.freedesktop.org" 
	<intel-gvt-dev@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile
Date: Thu, 21 Apr 2022 09:40:28 +0300	[thread overview]
Message-ID: <165052322868.6597.3051928698772494571@jlahtine-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <20220413144548.GR2120790@nvidia.com>

+ Tvrtko

Quoting Jason Gunthorpe (2022-04-13 17:45:48)
> On Wed, Apr 13, 2022 at 02:26:23PM +0000, Wang, Zhi A wrote:
> > On 4/13/22 1:43 PM, Jason Gunthorpe wrote:
> > > On Wed, Apr 13, 2022 at 01:39:35PM +0000, Wang, Zhi A wrote:
> > > 
> > >> It seems Jani's makefile clean patch has already included this one, I can
> > >> just simply drop this one so that Christoph won't need to re-send everything.
> > >>
> > >> For the branch to move on, I am merging the patches and will re-generate the
> > >> gvt-staging branch, which combines the newest drm-tip vfio-upstream and other
> > >> gvt branches.
> > >>
> > >> If you are in a rush of re-basing the patches of non-GVT-g stuff, you can use
> > >> gvt-staging branch until my pull request landed in drm-intel-next.
> > >>
> > >> Also our QA will test gvt-staging-branch before the pull request. I suppose
> > >> it will take one or two days.
> > > 
> > > When you are wrangling the branches it would be great if Christoph's
> > > series and it's minimal dependencies could be on a single branch that
> > > could reasonably be pulled to the VFIO tree too, thanks
> > > 
> > > Jason
> > > 
> > 
> > Hi Jason:
> > 
> > I am thinking about the process of merging process. Here are the dependence:
> > 
> > 1) My patches depend on one patch in drm-intel/drm-intel-next. So it has to
> > go through drm.
> > My patches of GVT-g will go through drm-intel-next -> drm -> upstream. 
> > 
> > 2) Christoph's patches depends on my patches, but part of them are for VFIO.
> > 
> > a. If they are fully going through VFIO repo, they might have to wait my
> > patches to get landed first.
> > 
> > b. If only the GVT-g parts goes through GVT repo, and rest of them goes
> > through VFIO, the rest part still needs to wait.
> > 
> > What would be a better process?
> 
> You should organize everything onto one simple branch based on a rc to
> make this all work.
> 
> Make your #1 patch as a single patch PR based on rc to drm-intel so it
> gets to the right tree
> 
> Make your MMIO series as PR on the branch above that first PR and merge to
> the gvt tree
> 
> Make Christoph's series as a PR on the branch above the second PR's
> MMIO series and merge to the gvt tree
> 
> Merge the gvt toward DRM in the normal way - ie the main merge path for
> this should be through DRM.
> 
> Then ask Alex to merge the 3rd PR as well.
> 
> I don't see any intel-next stuff in linux-next yet so hopefully it is
> early enough to get #1 OK.
> 
> Jason

WARNING: multiple messages have this Message-ID (diff)
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: "Wang, Zhi A" <zhi.a.wang@intel.com>, Jason Gunthorpe <jgg@nvidia.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
	"intel-gvt-dev@lists.freedesktop.org"
	<intel-gvt-dev@lists.freedesktop.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile
Date: Thu, 21 Apr 2022 09:40:28 +0300	[thread overview]
Message-ID: <165052322868.6597.3051928698772494571@jlahtine-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <20220413144548.GR2120790@nvidia.com>

+ Tvrtko

Quoting Jason Gunthorpe (2022-04-13 17:45:48)
> On Wed, Apr 13, 2022 at 02:26:23PM +0000, Wang, Zhi A wrote:
> > On 4/13/22 1:43 PM, Jason Gunthorpe wrote:
> > > On Wed, Apr 13, 2022 at 01:39:35PM +0000, Wang, Zhi A wrote:
> > > 
> > >> It seems Jani's makefile clean patch has already included this one, I can
> > >> just simply drop this one so that Christoph won't need to re-send everything.
> > >>
> > >> For the branch to move on, I am merging the patches and will re-generate the
> > >> gvt-staging branch, which combines the newest drm-tip vfio-upstream and other
> > >> gvt branches.
> > >>
> > >> If you are in a rush of re-basing the patches of non-GVT-g stuff, you can use
> > >> gvt-staging branch until my pull request landed in drm-intel-next.
> > >>
> > >> Also our QA will test gvt-staging-branch before the pull request. I suppose
> > >> it will take one or two days.
> > > 
> > > When you are wrangling the branches it would be great if Christoph's
> > > series and it's minimal dependencies could be on a single branch that
> > > could reasonably be pulled to the VFIO tree too, thanks
> > > 
> > > Jason
> > > 
> > 
> > Hi Jason:
> > 
> > I am thinking about the process of merging process. Here are the dependence:
> > 
> > 1) My patches depend on one patch in drm-intel/drm-intel-next. So it has to
> > go through drm.
> > My patches of GVT-g will go through drm-intel-next -> drm -> upstream. 
> > 
> > 2) Christoph's patches depends on my patches, but part of them are for VFIO.
> > 
> > a. If they are fully going through VFIO repo, they might have to wait my
> > patches to get landed first.
> > 
> > b. If only the GVT-g parts goes through GVT repo, and rest of them goes
> > through VFIO, the rest part still needs to wait.
> > 
> > What would be a better process?
> 
> You should organize everything onto one simple branch based on a rc to
> make this all work.
> 
> Make your #1 patch as a single patch PR based on rc to drm-intel so it
> gets to the right tree
> 
> Make your MMIO series as PR on the branch above that first PR and merge to
> the gvt tree
> 
> Make Christoph's series as a PR on the branch above the second PR's
> MMIO series and merge to the gvt tree
> 
> Merge the gvt toward DRM in the normal way - ie the main merge path for
> this should be through DRM.
> 
> Then ask Alex to merge the 3rd PR as well.
> 
> I don't see any intel-next stuff in linux-next yet so hopefully it is
> early enough to get #1 OK.
> 
> Jason

WARNING: multiple messages have this Message-ID (diff)
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: "Wang, Zhi A" <zhi.a.wang@intel.com>, Jason Gunthorpe <jgg@nvidia.com>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
	"intel-gvt-dev@lists.freedesktop.org"
	<intel-gvt-dev@lists.freedesktop.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [Intel-gfx] [PATCH 05/34] drm/i915/gvt: cleanup the Makefile
Date: Thu, 21 Apr 2022 09:40:28 +0300	[thread overview]
Message-ID: <165052322868.6597.3051928698772494571@jlahtine-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <20220413144548.GR2120790@nvidia.com>

+ Tvrtko

Quoting Jason Gunthorpe (2022-04-13 17:45:48)
> On Wed, Apr 13, 2022 at 02:26:23PM +0000, Wang, Zhi A wrote:
> > On 4/13/22 1:43 PM, Jason Gunthorpe wrote:
> > > On Wed, Apr 13, 2022 at 01:39:35PM +0000, Wang, Zhi A wrote:
> > > 
> > >> It seems Jani's makefile clean patch has already included this one, I can
> > >> just simply drop this one so that Christoph won't need to re-send everything.
> > >>
> > >> For the branch to move on, I am merging the patches and will re-generate the
> > >> gvt-staging branch, which combines the newest drm-tip vfio-upstream and other
> > >> gvt branches.
> > >>
> > >> If you are in a rush of re-basing the patches of non-GVT-g stuff, you can use
> > >> gvt-staging branch until my pull request landed in drm-intel-next.
> > >>
> > >> Also our QA will test gvt-staging-branch before the pull request. I suppose
> > >> it will take one or two days.
> > > 
> > > When you are wrangling the branches it would be great if Christoph's
> > > series and it's minimal dependencies could be on a single branch that
> > > could reasonably be pulled to the VFIO tree too, thanks
> > > 
> > > Jason
> > > 
> > 
> > Hi Jason:
> > 
> > I am thinking about the process of merging process. Here are the dependence:
> > 
> > 1) My patches depend on one patch in drm-intel/drm-intel-next. So it has to
> > go through drm.
> > My patches of GVT-g will go through drm-intel-next -> drm -> upstream. 
> > 
> > 2) Christoph's patches depends on my patches, but part of them are for VFIO.
> > 
> > a. If they are fully going through VFIO repo, they might have to wait my
> > patches to get landed first.
> > 
> > b. If only the GVT-g parts goes through GVT repo, and rest of them goes
> > through VFIO, the rest part still needs to wait.
> > 
> > What would be a better process?
> 
> You should organize everything onto one simple branch based on a rc to
> make this all work.
> 
> Make your #1 patch as a single patch PR based on rc to drm-intel so it
> gets to the right tree
> 
> Make your MMIO series as PR on the branch above that first PR and merge to
> the gvt tree
> 
> Make Christoph's series as a PR on the branch above the second PR's
> MMIO series and merge to the gvt tree
> 
> Merge the gvt toward DRM in the normal way - ie the main merge path for
> this should be through DRM.
> 
> Then ask Alex to merge the 3rd PR as well.
> 
> I don't see any intel-next stuff in linux-next yet so hopefully it is
> early enough to get #1 OK.
> 
> Jason

  reply	other threads:[~2022-04-21  6:40 UTC|newest]

Thread overview: 243+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-11 14:13 refactor the i915 GVT support and move to the modern mdev API v3 Christoph Hellwig
2022-04-11 14:13 ` [Intel-gfx] " Christoph Hellwig
2022-04-11 14:13 ` [PATCH 01/34] drm/i915/gvt: remove module refcounting in intel_gvt_{,un}register_hypervisor Christoph Hellwig
2022-04-11 14:13   ` [Intel-gfx] [PATCH 01/34] drm/i915/gvt: remove module refcounting in intel_gvt_{, un}register_hypervisor Christoph Hellwig
2022-04-11 14:13 ` [PATCH 02/34] drm/i915/gvt: remove enum hypervisor_type Christoph Hellwig
2022-04-11 14:13   ` [Intel-gfx] " Christoph Hellwig
2022-04-11 15:23   ` Jason Gunthorpe
2022-04-11 15:23     ` Jason Gunthorpe
2022-04-11 15:23     ` Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 03/34] drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops Christoph Hellwig
2022-04-11 14:13   ` [Intel-gfx] " Christoph Hellwig
2022-04-11 15:23   ` Jason Gunthorpe
2022-04-11 15:23     ` Jason Gunthorpe
2022-04-11 15:23     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 14:13 ` [PATCH 04/34] drm/i915/gvt: don't override the include path Christoph Hellwig
2022-04-11 14:13   ` [Intel-gfx] " Christoph Hellwig
2022-04-11 15:24   ` Jason Gunthorpe
2022-04-11 15:24     ` Jason Gunthorpe
2022-04-11 15:24     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 16:09   ` Jani Nikula
2022-04-11 16:09     ` Jani Nikula
2022-04-11 16:09     ` [Intel-gfx] " Jani Nikula
2022-04-11 14:13 ` [PATCH 05/34] drm/i915/gvt: cleanup the Makefile Christoph Hellwig
2022-04-11 14:13   ` [Intel-gfx] " Christoph Hellwig
2022-04-11 15:25   ` Jason Gunthorpe
2022-04-11 15:25     ` Jason Gunthorpe
2022-04-11 15:25     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 16:11     ` Jani Nikula
2022-04-11 16:11       ` Jani Nikula
2022-04-11 16:11       ` [Intel-gfx] " Jani Nikula
2022-04-11 16:51       ` Christoph Hellwig
2022-04-11 16:51         ` [Intel-gfx] " Christoph Hellwig
2022-04-13 12:33         ` Jani Nikula
2022-04-13 12:33           ` [Intel-gfx] " Jani Nikula
2022-04-13 12:33           ` Jani Nikula
2022-04-13 13:39           ` Wang, Zhi A
2022-04-13 13:39             ` [Intel-gfx] " Wang, Zhi A
2022-04-13 13:39             ` Wang, Zhi A
2022-04-13 13:43             ` Jason Gunthorpe
2022-04-13 13:43               ` [Intel-gfx] " Jason Gunthorpe
2022-04-13 13:43               ` Jason Gunthorpe
2022-04-13 14:26               ` Wang, Zhi A
2022-04-13 14:26                 ` [Intel-gfx] " Wang, Zhi A
2022-04-13 14:26                 ` Wang, Zhi A
2022-04-13 14:45                 ` Jason Gunthorpe
2022-04-13 14:45                   ` [Intel-gfx] " Jason Gunthorpe
2022-04-13 14:45                   ` Jason Gunthorpe
2022-04-21  6:40                   ` Joonas Lahtinen [this message]
2022-04-21  6:40                     ` [Intel-gfx] " Joonas Lahtinen
2022-04-21  6:40                     ` Joonas Lahtinen
2022-04-11 14:13 ` [Intel-gfx] [PATCH 06/34] drm/i915/gvt: move the gvt code into kvmgt.ko Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 18:43   ` Jason Gunthorpe
2022-04-11 18:43     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 18:43     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 07/34] drm/i915/gvt: remove intel_gvt_ops Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 15:32   ` Jason Gunthorpe
2022-04-11 15:32     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 15:32     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 08/34] drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 16:00   ` Jason Gunthorpe
2022-04-11 16:00     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 16:00     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 09/34] drm/i915/gvt: remove the unused from_virt_to_mfn op Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 16:00   ` Jason Gunthorpe
2022-04-11 16:00     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 16:00     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 10/34] drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 16:12   ` Jason Gunthorpe
2022-04-11 16:12     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 16:12     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 11/34] drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpu Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 16:13   ` Jason Gunthorpe
2022-04-11 16:13     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 16:13     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 12/34] drm/i915/gvt: remove vgpu->handle Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 16:14   ` Jason Gunthorpe
2022-04-11 16:14     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 16:14     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 13/34] drm/i915/gvt: devirtualize ->{read, write}_gpa Christoph Hellwig
2022-04-11 14:13   ` [PATCH 13/34] drm/i915/gvt: devirtualize ->{read,write}_gpa Christoph Hellwig
2022-04-11 16:15   ` Jason Gunthorpe
2022-04-11 16:15     ` [Intel-gfx] [PATCH 13/34] drm/i915/gvt: devirtualize ->{read, write}_gpa Jason Gunthorpe
2022-04-11 16:15     ` [PATCH 13/34] drm/i915/gvt: devirtualize ->{read,write}_gpa Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 14/34] drm/i915/gvt: devirtualize ->{get, put}_vfio_device Christoph Hellwig
2022-04-11 14:13   ` [PATCH 14/34] drm/i915/gvt: devirtualize ->{get,put}_vfio_device Christoph Hellwig
2022-04-11 16:26   ` Jason Gunthorpe
2022-04-11 16:26     ` Jason Gunthorpe
2022-04-11 16:26     ` [Intel-gfx] [PATCH 14/34] drm/i915/gvt: devirtualize ->{get, put}_vfio_device Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 15/34] drm/i915/gvt: devirtualize ->set_edid and ->set_opregion Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 16:27   ` Jason Gunthorpe
2022-04-11 16:27     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 16:27     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 16/34] drm/i915/gvt: devirtualize ->detach_vgpu Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 16:27   ` Jason Gunthorpe
2022-04-11 16:27     ` Jason Gunthorpe
2022-04-11 16:27     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 17/34] drm/i915/gvt: devirtualize ->inject_msi Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 16:28   ` Jason Gunthorpe
2022-04-11 16:28     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 16:28     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 18/34] drm/i915/gvt: devirtualize ->is_valid_gfn Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 16:29   ` Jason Gunthorpe
2022-04-11 16:29     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 16:29     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 19/34] drm/i915/gvt: devirtualize ->gfn_to_mfn Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 16:29   ` Jason Gunthorpe
2022-04-11 16:29     ` Jason Gunthorpe
2022-04-11 16:29     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 20/34] drm/i915/gvt: devirtualize ->{enable, disable}_page_track Christoph Hellwig
2022-04-11 14:13   ` [PATCH 20/34] drm/i915/gvt: devirtualize ->{enable,disable}_page_track Christoph Hellwig
2022-04-11 16:31   ` Jason Gunthorpe
2022-04-11 16:31     ` [Intel-gfx] [PATCH 20/34] drm/i915/gvt: devirtualize ->{enable, disable}_page_track Jason Gunthorpe
2022-04-11 16:31     ` [PATCH 20/34] drm/i915/gvt: devirtualize ->{enable,disable}_page_track Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 21/34] drm/i915/gvt: devirtualize ->dma_{, un}map_guest_page Christoph Hellwig
2022-04-11 14:13   ` [PATCH 21/34] drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page Christoph Hellwig
2022-04-11 18:08   ` Jason Gunthorpe
2022-04-11 18:08     ` [Intel-gfx] [PATCH 21/34] drm/i915/gvt: devirtualize ->dma_{, un}map_guest_page Jason Gunthorpe
2022-04-11 18:08     ` [PATCH 21/34] drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 22/34] drm/i915/gvt: devirtualize dma_pin_guest_page Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 18:09   ` Jason Gunthorpe
2022-04-11 18:09     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 18:09     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 23/34] drm/i915/gvt: remove struct intel_gvt_mpt Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 18:13   ` Jason Gunthorpe
2022-04-11 18:13     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 18:13     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 24/34] drm/i915/gvt: remove the extra vfio_device refcounting for dmabufs Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 18:33   ` Jason Gunthorpe
2022-04-11 18:33     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 18:33     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 25/34] drm/i915/gvt: streamline intel_vgpu_create Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 18:37   ` Jason Gunthorpe
2022-04-11 18:37     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 18:37     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 26/34] drm/i915/gvt: pass a struct intel_vgpu to the vfio read/write helpers Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 18:38   ` Jason Gunthorpe
2022-04-11 18:38     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 18:38     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 27/34] drm/i915/gvt: remove kvmgt_guest_{init, exit} Christoph Hellwig
2022-04-11 14:13   ` [PATCH 27/34] drm/i915/gvt: remove kvmgt_guest_{init,exit} Christoph Hellwig
2022-04-11 18:41   ` Jason Gunthorpe
2022-04-11 18:41     ` [Intel-gfx] [PATCH 27/34] drm/i915/gvt: remove kvmgt_guest_{init, exit} Jason Gunthorpe
2022-04-11 18:41     ` [PATCH 27/34] drm/i915/gvt: remove kvmgt_guest_{init,exit} Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 28/34] drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 18:36   ` Jason Gunthorpe
2022-04-11 18:36     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 18:36     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 29/34] drm/i915/gvt: merge gvt.c into kvmgvt.c Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-11 18:42   ` Jason Gunthorpe
2022-04-11 18:42     ` [Intel-gfx] " Jason Gunthorpe
2022-04-11 18:42     ` Jason Gunthorpe
2022-04-11 14:13 ` [Intel-gfx] [PATCH 30/34] vfio/mdev: Remove vfio_mdev.c Christoph Hellwig
2022-04-11 14:13   ` Christoph Hellwig
2022-04-12 20:51   ` Kirti Wankhede
2022-04-12 20:51     ` Kirti Wankhede
2022-04-12 20:51     ` [Intel-gfx] " Kirti Wankhede
2022-04-11 14:14 ` [Intel-gfx] [PATCH 31/34] vfio/mdev: Remove mdev_parent_ops dev_attr_groups Christoph Hellwig
2022-04-11 14:14   ` Christoph Hellwig
2022-04-12 20:51   ` Kirti Wankhede
2022-04-12 20:51     ` Kirti Wankhede
2022-04-12 20:51     ` [Intel-gfx] " Kirti Wankhede
2022-04-11 14:14 ` [Intel-gfx] [PATCH 32/34] vfio/mdev: Remove mdev_parent_ops Christoph Hellwig
2022-04-11 14:14   ` Christoph Hellwig
2022-04-12 20:51   ` Kirti Wankhede
2022-04-12 20:51     ` Kirti Wankhede
2022-04-12 20:51     ` [Intel-gfx] " Kirti Wankhede
2022-04-11 14:14 ` [Intel-gfx] [PATCH 33/34] vfio/mdev: Use the driver core to create the 'remove' file Christoph Hellwig
2022-04-11 14:14   ` Christoph Hellwig
2022-04-12 20:52   ` Kirti Wankhede
2022-04-12 20:52     ` Kirti Wankhede
2022-04-12 20:52     ` [Intel-gfx] " Kirti Wankhede
2022-04-11 14:14 ` [Intel-gfx] [PATCH 34/34] vfio/mdev: Remove mdev drvdata Christoph Hellwig
2022-04-11 14:14   ` Christoph Hellwig
2022-04-12 20:52   ` Kirti Wankhede
2022-04-12 20:52     ` Kirti Wankhede
2022-04-12 20:52     ` [Intel-gfx] " Kirti Wankhede
2022-04-13 13:47 ` refactor the i915 GVT support and move to the modern mdev API v3 Wang, Zhi A
2022-04-13 13:47   ` [Intel-gfx] " Wang, Zhi A
2022-04-13 13:47   ` Wang, Zhi A
2022-04-13 15:46   ` Christoph Hellwig
2022-04-13 15:46     ` [Intel-gfx] " Christoph Hellwig
2022-04-13 15:58     ` Jani Nikula
2022-04-13 15:58       ` [Intel-gfx] " Jani Nikula
2022-04-13 15:58       ` Jani Nikula
2022-04-13 16:27       ` Christoph Hellwig
2022-04-13 16:27         ` [Intel-gfx] " Christoph Hellwig
2022-04-13 23:13       ` Wang, Zhi A
2022-04-13 23:13         ` [Intel-gfx] " Wang, Zhi A
2022-04-13 23:13         ` Wang, Zhi A
2022-04-13 23:20         ` Jason Gunthorpe
2022-04-13 23:20           ` [Intel-gfx] " Jason Gunthorpe
2022-04-13 23:20           ` Jason Gunthorpe
2022-04-14 12:20           ` Wang, Zhi A
2022-04-14 12:20             ` Wang, Zhi A
2022-04-14 12:20             ` [Intel-gfx] " Wang, Zhi A
2022-04-14 13:34             ` Jason Gunthorpe
2022-04-14 13:34               ` Jason Gunthorpe
2022-04-14 13:34               ` [Intel-gfx] " Jason Gunthorpe
2022-04-14 13:39               ` Wang, Zhi A
2022-04-14 13:39                 ` Wang, Zhi A
2022-04-14 13:39                 ` [Intel-gfx] " Wang, Zhi A
2022-04-14 13:41                 ` Jason Gunthorpe
2022-04-14 13:41                   ` Jason Gunthorpe
2022-04-14 13:41                   ` [Intel-gfx] " Jason Gunthorpe
2022-04-14 13:44                   ` Jani Nikula
2022-04-14 13:44                     ` Jani Nikula
2022-04-14 13:44                     ` [Intel-gfx] " Jani Nikula
2022-04-14 13:40               ` Jani Nikula
2022-04-14 13:40                 ` Jani Nikula
2022-04-14 13:40                 ` [Intel-gfx] " Jani Nikula
2022-04-14 13:43                 ` Jason Gunthorpe
2022-04-14 13:43                   ` Jason Gunthorpe
2022-04-14 13:43                   ` [Intel-gfx] " Jason Gunthorpe
2022-04-14 14:25                   ` Wang, Zhi A
2022-04-14 14:25                     ` Wang, Zhi A
2022-04-14 14:25                     ` [Intel-gfx] " Wang, Zhi A
2022-04-14 14:38                     ` Jason Gunthorpe
2022-04-14 14:38                       ` Jason Gunthorpe
2022-04-14 14:38                       ` [Intel-gfx] " Jason Gunthorpe
2022-04-20  7:08                       ` Christoph Hellwig
2022-04-20  7:08                         ` [Intel-gfx] " Christoph Hellwig
2022-04-20  7:12                         ` Wang, Zhi A
2022-04-20  7:12                           ` [Intel-gfx] " Wang, Zhi A
2022-04-20  7:12                           ` Wang, Zhi A

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=165052322868.6597.3051928698772494571@jlahtine-mobl.ger.corp.intel.com \
    --to=joonas.lahtinen@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@lst.de \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jgg@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=zhenyuw@linux.intel.com \
    --cc=zhi.a.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.