Re: [PATCH 02/34] drm/i915/gvt: remove enum hypervisor_type

Re: [PATCH 02/34] drm/i915/gvt: remove enum hypervisor_type

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:31PM +0200, Christoph Hellwig wrote:
> The only supported hypervisor is KVM, so don't bother with dead code
> enumerating hypervisors.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/gvt.c       |  17 +--
>  drivers/gpu/drm/i915/gvt/gvt.h       |   1 -
>  drivers/gpu/drm/i915/gvt/hypercall.h |   6 --
>  drivers/gpu/drm/i915/gvt/kvmgt.c     |   1 -
>  drivers/gpu/drm/i915/gvt/opregion.c  | 150 ++++++---------------------
>  5 files changed, 34 insertions(+), 141 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 03/34] drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:32PM +0200, Christoph Hellwig wrote:
> Free the intel_vgpu_ops symbol name for something that fits better.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 04/34] drm/i915/gvt: don't override the include path

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:33PM +0200, Christoph Hellwig wrote:
> drivers/gpu/drm/i915/gvt/Makefile is included
> from drivers/gpu/drm/i915/Makefile and thus inherits the normal include
> path relative to drivers/gpu/drm/i915/.  Fix up the gvt-specific trace
> header and just do away with the include path manipulation.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/Makefile | 1 -
>  drivers/gpu/drm/i915/gvt/trace.h  | 2 +-
>  2 files changed, 1 insertion(+), 2 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 04/34] drm/i915/gvt: don't override the include path

[Jani Nikula]

On Mon, 11 Apr 2022, Christoph Hellwig <hch@lst.de> wrote:
> drivers/gpu/drm/i915/gvt/Makefile is included
> from drivers/gpu/drm/i915/Makefile and thus inherits the normal include
> path relative to drivers/gpu/drm/i915/.  Fix up the gvt-specific trace
> header and just do away with the include path manipulation.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/Makefile | 1 -
>  drivers/gpu/drm/i915/gvt/trace.h  | 2 +-
>  2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile b/drivers/gpu/drm/i915/gvt/Makefile
> index ea8324abc784a..4d70f4689479c 100644
> --- a/drivers/gpu/drm/i915/gvt/Makefile
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -5,5 +5,4 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
>  	execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o debugfs.o \
>  	fb_decoder.o dmabuf.o page_track.o
>  
> -ccflags-y				+= -I $(srctree)/$(src) -I $(srctree)/$(src)/$(GVT_DIR)/
>  i915-y					+= $(addprefix $(GVT_DIR)/, $(GVT_SOURCE))
> diff --git a/drivers/gpu/drm/i915/gvt/trace.h b/drivers/gpu/drm/i915/gvt/trace.h
> index 6d787750d279f..348f57f8301db 100644
> --- a/drivers/gpu/drm/i915/gvt/trace.h
> +++ b/drivers/gpu/drm/i915/gvt/trace.h
> @@ -379,5 +379,5 @@ TRACE_EVENT(render_mmio,
>  #undef TRACE_INCLUDE_PATH
>  #define TRACE_INCLUDE_PATH .
>  #undef TRACE_INCLUDE_FILE
> -#define TRACE_INCLUDE_FILE trace
> +#define TRACE_INCLUDE_FILE gvt/trace

This is not actually correct. Please see my gvt Makefile cleanup [1][2].

BR,
Jani.

[1] https://lore.kernel.org/all/20220331082127.432171-1-jani.nikula@intel.com/
[2] https://lore.kernel.org/all/20220331082127.432171-2-jani.nikula@intel.com/

>  #include <trace/define_trace.h>

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:34PM +0200, Christoph Hellwig wrote:
> Match the style of the main i915 Makefile in the gvt-specfic one and
> remove the GVT_DIR and GVT_SOURCE variables.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
>  drivers/gpu/drm/i915/gvt/Makefile | 29 +++++++++++++++++++++++------
>  1 file changed, 23 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile b/drivers/gpu/drm/i915/gvt/Makefile
> index 4d70f4689479c..f2f6ea02714ec 100644
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -1,8 +1,25 @@
>  # SPDX-License-Identifier: GPL-2.0
> -GVT_DIR := gvt
> -GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
> -	interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
> -	execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o debugfs.o \
> -	fb_decoder.o dmabuf.o page_track.o
>  
> -i915-y					+= $(addprefix $(GVT_DIR)/, $(GVT_SOURCE))
> +i915-y += \
> +	gvt/gvt.o \
> +	gvt/aperture_gm.o \
> +	gvt/handlers.o \
> +	gvt/vgpu.o \
> +	gvt/trace_points.o \
> +	gvt/firmware.o \
> +	gvt/interrupt.o \
> +	gvt/gtt.o \
> +	gvt/cfg_space.o \
> +	gvt/opregion.o \
> +	gvt/mmio.o \
> +	gvt/display.o \
> +	gvt/edid.o \
> +	gvt/execlist.o \
> +	gvt/scheduler.o \
> +	gvt/sched_policy.o \
> +	gvt/mmio_context.o \
> +	gvt/cmd_parser.o \
> +	gvt/debugfs.o \
> +	gvt/fb_decoder.o \
> +	gvt/dmabuf.o \
> +	gvt/page_track.o

Up to you but I usually sort these lists

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile

[Jani Nikula]

On Mon, 11 Apr 2022, Jason Gunthorpe <jgg@nvidia.com> wrote:
> On Mon, Apr 11, 2022 at 04:13:34PM +0200, Christoph Hellwig wrote:
>> Match the style of the main i915 Makefile in the gvt-specfic one and
>> remove the GVT_DIR and GVT_SOURCE variables.
>> 
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>>  drivers/gpu/drm/i915/gvt/Makefile | 29 +++++++++++++++++++++++------
>>  1 file changed, 23 insertions(+), 6 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/gvt/Makefile b/drivers/gpu/drm/i915/gvt/Makefile
>> index 4d70f4689479c..f2f6ea02714ec 100644
>> +++ b/drivers/gpu/drm/i915/gvt/Makefile
>> @@ -1,8 +1,25 @@
>>  # SPDX-License-Identifier: GPL-2.0
>> -GVT_DIR := gvt
>> -GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
>> -	interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
>> -	execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o debugfs.o \
>> -	fb_decoder.o dmabuf.o page_track.o
>>  
>> -i915-y					+= $(addprefix $(GVT_DIR)/, $(GVT_SOURCE))
>> +i915-y += \
>> +	gvt/gvt.o \
>> +	gvt/aperture_gm.o \
>> +	gvt/handlers.o \
>> +	gvt/vgpu.o \
>> +	gvt/trace_points.o \
>> +	gvt/firmware.o \
>> +	gvt/interrupt.o \
>> +	gvt/gtt.o \
>> +	gvt/cfg_space.o \
>> +	gvt/opregion.o \
>> +	gvt/mmio.o \
>> +	gvt/display.o \
>> +	gvt/edid.o \
>> +	gvt/execlist.o \
>> +	gvt/scheduler.o \
>> +	gvt/sched_policy.o \
>> +	gvt/mmio_context.o \
>> +	gvt/cmd_parser.o \
>> +	gvt/debugfs.o \
>> +	gvt/fb_decoder.o \
>> +	gvt/dmabuf.o \
>> +	gvt/page_track.o
>
> Up to you but I usually sort these lists

Yeah, please do. Otherwise matches what I sent, so ack.

BR,
Jani.

>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
>
> Jason

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile

[Jani Nikula]

On Mon, 11 Apr 2022, Christoph Hellwig <hch@lst.de> wrote:
> On Mon, Apr 11, 2022 at 07:11:03PM +0300, Jani Nikula wrote:
>> > Up to you but I usually sort these lists
>> 
>> Yeah, please do. Otherwise matches what I sent, so ack.
>
> Let's just merge your 2 patch series ASAP and I'll rebase on top of
> that.

I rebased them on top of current gvt-next and resent [1]. Zhenyu, Zhi,
please pick them up if you approve.

> What branch in drm-intel should I use as the base for the next version
> btw?  Or does gvt go through yet another tree?

It's yet another tree... Basically gvt is developed on top of gvt-next
(see MAINTAINERS) and Zhenyu and Zhi send pull requests for
drm-intel-next.


BR,
Jani.


[1] https://lore.kernel.org/all/cover.1649852517.git.jani.nikula@intel.com

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile

[Wang, Zhi A]

On 4/13/22 12:33 PM, Jani Nikula wrote:
> On Mon, 11 Apr 2022, Christoph Hellwig <hch@lst.de> wrote:
>> On Mon, Apr 11, 2022 at 07:11:03PM +0300, Jani Nikula wrote:
>>>> Up to you but I usually sort these lists
>>>
>>> Yeah, please do. Otherwise matches what I sent, so ack.
>>
>> Let's just merge your 2 patch series ASAP and I'll rebase on top of
>> that.
> 
> I rebased them on top of current gvt-next and resent [1]. Zhenyu, Zhi,
> please pick them up if you approve.
> 
>> What branch in drm-intel should I use as the base for the next version
>> btw?  Or does gvt go through yet another tree?
> 
> It's yet another tree... Basically gvt is developed on top of gvt-next
> (see MAINTAINERS) and Zhenyu and Zhi send pull requests for
> drm-intel-next.
> 
Hi Jani and Christoph:

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.

Again, thanks so much for making this happen. 

Thanks,
Zhi.
> > BR,
> Jani.
> 
> 
> [1] https://lore.kernel.org/all/cover.1649852517.git.jani.nikula@intel.com
> 

Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile

[Jason Gunthorpe]

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

Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile

[Wang, Zhi A]

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?

Thanks,
Zhi.

Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile

[Jason Gunthorpe]

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

Re: [PATCH 05/34] drm/i915/gvt: cleanup the Makefile

[Joonas Lahtinen]

+ 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

Re: [PATCH 07/34] drm/i915/gvt: remove intel_gvt_ops

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:36PM +0200, Christoph Hellwig wrote:
> Remove these pointless indirect alls by just calling the only instance

'alls' -> 'calls'

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 08/34] drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:37PM +0200, Christoph Hellwig wrote:
> The map_gfn_to_mfn and set_trap_area ops are never defined, so remove
> them and clean up code that depends on them in the callers.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/cfg_space.c | 89 ++++++----------------------
>  drivers/gpu/drm/i915/gvt/hypercall.h |  4 --
>  drivers/gpu/drm/i915/gvt/mpt.h       | 44 --------------
>  3 files changed, 17 insertions(+), 120 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 09/34] drm/i915/gvt: remove the unused from_virt_to_mfn op

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:38PM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/hypercall.h |  1 -
>  drivers/gpu/drm/i915/gvt/kvmgt.c     |  6 ------
>  drivers/gpu/drm/i915/gvt/mpt.h       | 12 ------------
>  3 files changed, 19 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 10/34] drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:39PM +0200, Christoph Hellwig wrote:
> Move towards having only a single structure for the per-VGPU state.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/gvt.h       |  31 ++-
>  drivers/gpu/drm/i915/gvt/hypercall.h |   1 -
>  drivers/gpu/drm/i915/gvt/kvmgt.c     | 288 ++++++++++-----------------
>  drivers/gpu/drm/i915/gvt/mpt.h       |  16 --
>  drivers/gpu/drm/i915/gvt/vgpu.c      |   8 +-
>  5 files changed, 128 insertions(+), 216 deletions(-)

Happy to see it

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 11/34] drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpu

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:40PM +0200, Christoph Hellwig wrote:
> Consolidate the per-VGPU structures into a single one.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/gvt.h   |   8 +++
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 117 ++++++++++++-------------------
>  2 files changed, 52 insertions(+), 73 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
 
> @@ -236,6 +239,11 @@ struct intel_vgpu {
>  	atomic_t released;
>  	struct vfio_device *vfio_device;
>  	struct vfio_group *vfio_group;
> +
> +	struct kvm_page_track_notifier_node track_node;
> +#define NR_BKT (1 << 18)
> +	struct hlist_head ptable[NR_BKT];
> +#undef NR_BKT

It is what was there before, but it sure read oddly..

Jason

Re: [PATCH 12/34] drm/i915/gvt: remove vgpu->handle

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:41PM +0200, Christoph Hellwig wrote:
> Always pass the actual vgpu structure instead of encoding it as a
> "handle" and add a bool flag to denote if a VGPU is attached.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/gvt.h       |   3 +-
>  drivers/gpu/drm/i915/gvt/hypercall.h |  32 +++----
>  drivers/gpu/drm/i915/gvt/kvmgt.c     | 126 +++++++++------------------
>  drivers/gpu/drm/i915/gvt/mpt.h       |  20 ++---
>  drivers/gpu/drm/i915/gvt/vgpu.c      |   6 +-
>  5 files changed, 71 insertions(+), 116 deletions(-)

Yay typesafety!

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 13/34] drm/i915/gvt: devirtualize ->{read,write}_gpa

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:42PM +0200, Christoph Hellwig wrote:
> Just call the VFIO functions directly instead of through the method
> table.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/cmd_parser.c |  4 +--
>  drivers/gpu/drm/i915/gvt/execlist.c   | 12 ++++-----
>  drivers/gpu/drm/i915/gvt/gtt.c        |  6 ++---
>  drivers/gpu/drm/i915/gvt/gvt.h        | 37 +++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/gvt/hypercall.h  |  4 ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c      | 23 -----------------
>  drivers/gpu/drm/i915/gvt/mmio.c       |  4 +--
>  drivers/gpu/drm/i915/gvt/mpt.h        | 32 -----------------------
>  drivers/gpu/drm/i915/gvt/opregion.c   | 10 +++-----
>  drivers/gpu/drm/i915/gvt/scheduler.c  | 37 +++++++++++++--------------
>  10 files changed, 72 insertions(+), 97 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 14/34] drm/i915/gvt: devirtualize ->{get,put}_vfio_device

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:43PM +0200, Christoph Hellwig wrote:
> Just open code the calls to the VFIO APIs.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/dmabuf.c    | 12 ++++++-----
>  drivers/gpu/drm/i915/gvt/hypercall.h |  2 --
>  drivers/gpu/drm/i915/gvt/kvmgt.c     | 22 --------------------
>  drivers/gpu/drm/i915/gvt/mpt.h       | 30 ----------------------------
>  4 files changed, 7 insertions(+), 59 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Had to look ahead in the series to see that the
vfio_device_get_from_dev() was removed too :)

Jason

Re: [PATCH 15/34] drm/i915/gvt: devirtualize ->set_edid and ->set_opregion

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:44PM +0200, Christoph Hellwig wrote:
> Just call the code to setup the opregions and EDID data directly.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/gvt.h       |  3 +++
>  drivers/gpu/drm/i915/gvt/hypercall.h |  3 ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c     |  6 ++----
>  drivers/gpu/drm/i915/gvt/mpt.h       | 32 ----------------------------
>  drivers/gpu/drm/i915/gvt/vgpu.c      |  6 +++---
>  5 files changed, 8 insertions(+), 42 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 16/34] drm/i915/gvt: devirtualize ->detach_vgpu

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:45PM +0200, Christoph Hellwig wrote:
> Just call the function directly.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/gvt.h       |  1 +
>  drivers/gpu/drm/i915/gvt/hypercall.h |  1 -
>  drivers/gpu/drm/i915/gvt/kvmgt.c     |  3 +--
>  drivers/gpu/drm/i915/gvt/mpt.h       | 16 ----------------
>  drivers/gpu/drm/i915/gvt/vgpu.c      |  2 +-
>  5 files changed, 3 insertions(+), 20 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 17/34] drm/i915/gvt: devirtualize ->inject_msi

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:46PM +0200, Christoph Hellwig wrote:
> Just open code the MSI injection in a single place instead of going
> through the method table.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/hypercall.h |  1 -
>  drivers/gpu/drm/i915/gvt/interrupt.c | 38 +++++++++++++++++++++++++++-
>  drivers/gpu/drm/i915/gvt/kvmgt.c     | 24 ------------------
>  drivers/gpu/drm/i915/gvt/mpt.h       | 37 ---------------------------
>  4 files changed, 37 insertions(+), 63 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 18/34] drm/i915/gvt: devirtualize ->is_valid_gfn

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:47PM +0200, Christoph Hellwig wrote:
> Just call the code directly and move towards the callers.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/gtt.c       | 20 ++++++++++++++++++--
>  drivers/gpu/drm/i915/gvt/hypercall.h |  1 -
>  drivers/gpu/drm/i915/gvt/kvmgt.c     | 17 -----------------
>  drivers/gpu/drm/i915/gvt/mpt.h       | 17 -----------------
>  4 files changed, 18 insertions(+), 37 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 19/34] drm/i915/gvt: devirtualize ->gfn_to_mfn

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:48PM +0200, Christoph Hellwig wrote:
> Just open code it in the only caller.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/gtt.c       |  9 +++++----
>  drivers/gpu/drm/i915/gvt/hypercall.h |  1 -
>  drivers/gpu/drm/i915/gvt/kvmgt.c     | 16 ----------------
>  drivers/gpu/drm/i915/gvt/mpt.h       | 14 --------------
>  4 files changed, 5 insertions(+), 35 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 20/34] drm/i915/gvt: devirtualize ->{enable,disable}_page_track

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:49PM +0200, Christoph Hellwig wrote:
> Just call the kvmgt functions directly.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/gvt.h        |  3 +++
>  drivers/gpu/drm/i915/gvt/hypercall.h  |  2 --
>  drivers/gpu/drm/i915/gvt/kvmgt.c      |  6 ++----
>  drivers/gpu/drm/i915/gvt/mpt.h        | 28 ---------------------------
>  drivers/gpu/drm/i915/gvt/page_track.c |  8 ++++----
>  5 files changed, 9 insertions(+), 38 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 21/34] drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:50PM +0200, Christoph Hellwig wrote:
> Just call the functions directly.  Also remove a pointless wrapper.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/dmabuf.c    | 10 ++--------
>  drivers/gpu/drm/i915/gvt/gtt.c       | 20 +++++++++----------
>  drivers/gpu/drm/i915/gvt/gvt.h       |  4 ++++
>  drivers/gpu/drm/i915/gvt/hypercall.h |  5 -----
>  drivers/gpu/drm/i915/gvt/kvmgt.c     |  6 ++----
>  drivers/gpu/drm/i915/gvt/mpt.h       | 29 ----------------------------
>  6 files changed, 17 insertions(+), 57 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 22/34] drm/i915/gvt: devirtualize dma_pin_guest_page

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:51PM +0200, Christoph Hellwig wrote:
> Just call the function directly and remove a pointless wrapper.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/dmabuf.c    | 14 +-------------
>  drivers/gpu/drm/i915/gvt/gvt.h       |  1 +
>  drivers/gpu/drm/i915/gvt/hypercall.h |  2 --
>  drivers/gpu/drm/i915/gvt/kvmgt.c     |  4 +---
>  drivers/gpu/drm/i915/gvt/mpt.h       | 15 ---------------
>  5 files changed, 3 insertions(+), 33 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 23/34] drm/i915/gvt: remove struct intel_gvt_mpt

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:52PM +0200, Christoph Hellwig wrote:
> Just call the initializion and exit functions directly and remove
> this abstraction entirely.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/gvt.c       | 11 ++++-
>  drivers/gpu/drm/i915/gvt/gvt.h       | 12 ++---
>  drivers/gpu/drm/i915/gvt/hypercall.h | 50 -------------------
>  drivers/gpu/drm/i915/gvt/kvmgt.c     | 39 ++-------------
>  drivers/gpu/drm/i915/gvt/mpt.h       | 74 ----------------------------
>  5 files changed, 17 insertions(+), 169 deletions(-)
>  delete mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
>  delete mode 100644 drivers/gpu/drm/i915/gvt/mpt.h

That gvt_vgpu_type_groups stuff is pretty wonky, but it can be left

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 24/34] drm/i915/gvt: remove the extra vfio_device refcounting for dmabufs

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:53PM +0200, Christoph Hellwig wrote:
> All the dmabufs are torn down when th VGPU is released, so there is
> no need for extra refcounting here.

'th' -> 'the'

I think the specific argument is that intel_vgpu_query_plane() is only
called from intel_vgpu_ioctl() which has to happen while the device is
open so intel_vgpu_query_plane() has no issue.

dmabuf_gem_object_free() is OK because:
 intel_vgpu_close_device
  __intel_vgpu_release
   intel_gvt_release_vgpu
    intel_vgpu_dmabuf_cleanup

Menaing dmabuf->vgpu was already NULL once close_device is passed, and
the vfio_device reference is held automatically from open_device->close_device

And similarly intel_vgpu_dmabuf_cleanup() is OK because it is called
by the above.

The other places that call intel_vgpu_dmabuf_cleanup() are redundant
with the close_device path.

Though the 'release_work' callpath is buggy, for many reasons, but not
for this series.

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c b/drivers/gpu/drm/i915/gvt/dmabuf.c
> index 90443306a9ad4..01e54b45c5c1b 100644
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -139,7 +139,6 @@ static void dmabuf_gem_object_free(struct kref *kref)
>  			dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj, list);
>  			if (dmabuf_obj == obj) {

Not for this series but it seems like there is something off about
the locking here:

	if (vgpu && vgpu->active && !list_empty(&vgpu->dmabuf_obj_list_head)) {

This is called under the dmabuf lock but active is protected by the
vgpu_lock.. It seems strange that vgpu->active could be false but the
device is still open, so maybe it is not possible.

Jason

Re: [PATCH 28/34] drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:57PM +0200, Christoph Hellwig wrote:

> -static int intel_vgpu_create(struct mdev_device *mdev)
> -{
> -	struct device *pdev = mdev_parent_dev(mdev);
> -	struct intel_gvt *gvt = kdev_to_i915(pdev)->gvt;
> -	struct intel_vgpu_type *type;
> -	struct intel_vgpu *vgpu;
> -
> -	type = &gvt->types[mdev_get_type_group_id(mdev)];
> -	if (!type)
> -		return -EINVAL;
> -
> -	vgpu = intel_gvt_create_vgpu(gvt, type);
> -	if (IS_ERR(vgpu)) {
> -		gvt_err("failed to create intel vgpu: %ld\n", PTR_ERR(vgpu));
> -		return PTR_ERR(vgpu);
> -	}
> -
> -	INIT_WORK(&vgpu->release_work, intel_vgpu_release_work);
> -
> -	vgpu->mdev = mdev;
> -	mdev_set_drvdata(mdev, vgpu);
> -
> -	gvt_dbg_core("intel_vgpu_create succeeded for mdev: %s\n",
> -		     dev_name(mdev_dev(mdev)));

nit: the debug print has the wrong function name now

Rest looks OK

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 25/34] drm/i915/gvt: streamline intel_vgpu_create

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:54PM +0200, Christoph Hellwig wrote:
> Initialize variables at declaration time, avoid pointless gotos and
> cater for the fact that intel_gvt_create_vgpu can't return NULL.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 28 +++++++++-------------------
>  1 file changed, 9 insertions(+), 19 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 26/34] drm/i915/gvt: pass a struct intel_vgpu to the vfio read/write helpers

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:55PM +0200, Christoph Hellwig wrote:
> Pass the structure we actually care about instead of deriving it from
> the mdev_device in the lower level code.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 28 ++++++++++++++--------------
>  1 file changed, 14 insertions(+), 14 deletions(-)

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 27/34] drm/i915/gvt: remove kvmgt_guest_{init,exit}

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:56PM +0200, Christoph Hellwig wrote:
> Merge these into their only callers.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 129 ++++++++++++++-----------------
>  1 file changed, 60 insertions(+), 69 deletions(-)

It is nice

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

> @@ -847,14 +873,37 @@ static int intel_vgpu_open_device(struct mdev_device *mdev)
>  		goto undo_group;
>  	}
>  
> -	ret = kvmgt_guest_init(mdev);
> -	if (ret)
> +	ret = -EEXIST;
> +	if (vgpu->attached)
> +		goto undo_group;
> +
> +	ret = -ESRCH;
> +	if (!vgpu->kvm || vgpu->kvm->mm != current->mm) {

For instance once all the obfuscation is stripped away it is easy to
see how the vgpu->kvm access here is unlocked against the notifier and
racy.

Jason

Re: [PATCH 29/34] drm/i915/gvt: merge gvt.c into kvmgvt.c

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:58PM +0200, Christoph Hellwig wrote:
> The code in both files is deeply interconnected, so merge it and
> keep a bunch of structures and functions static.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/gvt/Makefile |   1 -
>  drivers/gpu/drm/i915/gvt/gvt.c    | 291 ------------------------------
>  drivers/gpu/drm/i915/gvt/gvt.h    |   6 -
>  drivers/gpu/drm/i915/gvt/kvmgt.c  | 264 ++++++++++++++++++++++++++-
>  4 files changed, 260 insertions(+), 302 deletions(-)
>  delete mode 100644 drivers/gpu/drm/i915/gvt/gvt.c

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 06/34] drm/i915/gvt: move the gvt code into kvmgt.ko

[Jason Gunthorpe]

On Mon, Apr 11, 2022 at 04:13:35PM +0200, Christoph Hellwig wrote:
> Instead of having an option to build the gvt code into the main i915
> module, just move it into the kvmgt.ko module.  This only requires
> a new struct with three entries that the KVMGT modules needs to register
> with the main i915 module, and a proper list of GVT-enabled devices
> instead of global device pointer.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  drivers/gpu/drm/i915/Kconfig                |  36 ++--
>  drivers/gpu/drm/i915/Makefile               |   2 +-
>  drivers/gpu/drm/i915/gvt/Makefile           |   5 +-
>  drivers/gpu/drm/i915/gvt/gvt.c              |  55 ++----
>  drivers/gpu/drm/i915/gvt/gvt.h              |   6 +-
>  drivers/gpu/drm/i915/gvt/kvmgt.c            |  14 +-
>  drivers/gpu/drm/i915/gvt/mpt.h              |   3 -
>  drivers/gpu/drm/i915/i915_driver.c          |   7 -
>  drivers/gpu/drm/i915/i915_drv.h             |   1 +
>  drivers/gpu/drm/i915/intel_gvt.c            | 200 +++++++++++++-------
>  drivers/gpu/drm/i915/intel_gvt.h            |  17 +-
>  drivers/gpu/drm/i915/intel_gvt_mmio_table.c |   1 +
>  12 files changed, 193 insertions(+), 154 deletions(-)

There is a few things going on in here, I looked a few times and
didn't spot anything..

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>

Jason

Re: [PATCH 30/34] vfio/mdev: Remove vfio_mdev.c

[Kirti Wankhede]

On 4/11/2022 7:43 PM, Christoph Hellwig wrote:
> From: Jason Gunthorpe <jgg@nvidia.com>
> 
> Now that all mdev drivers directly create their own mdev_device driver and
> directly register with the vfio core's vfio_device_ops this is all dead
> code.
> 
> Delete vfio_mdev.c and the mdev_parent_ops members that are connected to
> it.
> 
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Reviewed-by: Kirti Wankhede <kwankhede@nvidia.com>

Re: [PATCH 31/34] vfio/mdev: Remove mdev_parent_ops dev_attr_groups

[Kirti Wankhede]

On 4/11/2022 7:44 PM, Christoph Hellwig wrote:
> From: Jason Gunthorpe <jgg@nvidia.com>
> 
> This is only used by one sample to print a fixed string that is pointless.
> 
> In general, having a device driver attach sysfs attributes to the parent
> is horrific. This should never happen, and always leads to some kind of
> liftime bug as it become very difficult for the sysfs attribute to go back
> to any data owned by the device driver.
> 
> Remove the general mechanism to create this abuse.
> 
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   drivers/vfio/mdev/mdev_sysfs.c | 12 ++----------
>   include/linux/mdev.h           |  2 --
>   samples/vfio-mdev/mtty.c       | 30 +-----------------------------
>   3 files changed, 3 insertions(+), 41 deletions(-)
> 

Update Documentation/driver-api/vfio-mediated-device.rst where mtty 
sample code explained. Tree command output should be updated, i.e remove 
below 2 lines.
         |-- mtty_dev
         |   `-- sample_mtty_dev

Rest looks good to me.

Thanks,
Kirti

Re: [PATCH 32/34] vfio/mdev: Remove mdev_parent_ops

[Kirti Wankhede]

On 4/11/2022 7:44 PM, Christoph Hellwig wrote:
> From: Jason Gunthorpe <jgg@nvidia.com>
> 
> The last useful member in this struct is the supported_type_groups, move
> it to the mdev_driver and delete mdev_parent_ops.
> 
> Replace it with mdev_driver as an argument to mdev_register_device()
> 
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   .../driver-api/vfio-mediated-device.rst       | 24 ++++--------------
>   drivers/gpu/drm/i915/gvt/kvmgt.c              |  7 +-----
>   drivers/s390/cio/vfio_ccw_ops.c               |  7 +-----
>   drivers/s390/crypto/vfio_ap_ops.c             |  9 ++-----
>   drivers/vfio/mdev/mdev_core.c                 | 13 ++++------
>   drivers/vfio/mdev/mdev_private.h              |  2 +-
>   drivers/vfio/mdev/mdev_sysfs.c                |  6 ++---
>   include/linux/mdev.h                          | 25 +++----------------
>   samples/vfio-mdev/mbochs.c                    |  9 ++-----
>   samples/vfio-mdev/mdpy.c                      |  9 ++-----
>   samples/vfio-mdev/mtty.c                      |  9 ++-----
>   11 files changed, 28 insertions(+), 92 deletions(-)
> 

Reviewed-by: Kirti Wankhede <kwankhede@nvidia.com>

Re: [PATCH 33/34] vfio/mdev: Use the driver core to create the 'remove' file

[Kirti Wankhede]

On 4/11/2022 7:44 PM, Christoph Hellwig wrote:
> From: Jason Gunthorpe <jgg@nvidia.com>
> 
> The device creator is supposed to use the dev.groups value to add sysfs
> files before device_add is called, not call sysfs_create_files() after
> device_add() returns. This creates a race with uevent delivery where the
> extra attribute will not be visible.
> 
> This was being done because the groups had been co-opted by the mdev
> driver, now that prior patches have moved the driver's groups to the
> struct device_driver the dev.group is properly free for use here.
> 
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   drivers/vfio/mdev/mdev_core.c    |  1 +
>   drivers/vfio/mdev/mdev_private.h |  2 ++
>   drivers/vfio/mdev/mdev_sysfs.c   | 19 ++++++++++---------
>   3 files changed, 13 insertions(+), 9 deletions(-)
> 

Reviewed-by: Kirti Wankhede <kwankhede@nvidia.com>

Re: [PATCH 34/34] vfio/mdev: Remove mdev drvdata

[Kirti Wankhede]

On 4/11/2022 7:44 PM, Christoph Hellwig wrote:
> From: Jason Gunthorpe <jgg@nvidia.com>
> 
> This is no longer used, remove it.
> 
> All usages were moved over to either use container_of() from a vfio_device
> or to use dev_drvdata() directly on the mdev.
> 
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   include/linux/mdev.h | 9 ---------
>   1 file changed, 9 deletions(-)
> 

Reviewed-by: Kirti Wankhede <kwankhede@nvidia.com>

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Wang, Zhi A]

On 4/11/22 2:13 PM, Christoph Hellwig wrote:
> Hi all,
> 
> the GVT code in the i915 is a bit of a mess right now due to strange
> abstractions and lots of indirect calls.  This series refactors various
> bits to clean that up.  The main user visible change is that almost all
> of the GVT code moves out of the main i915 driver and into the kvmgt
> module.

Hi Christoph:

Do you want me to merge the GVT-g patches in this series? Or you want them to get merged from your side?

Thanks,
Zhi.

> 
> Tested on my Thinkpad with a Kaby Lake CPU and integrated graphics.
> 
> Git tree:
> 
>     git://git.infradead.org/users/hch/misc.git i915-gvt
> 
> Gitweb:
> 
>     http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/i915-gvt
> 
> Changes since v2:
>  - rebased on top of Linx 5.18-rc +
>    "Refactor GVT-g MMIO tracking table and handlers"
>  - don't fold the gvt Makefile into the main Makefile
>  - add the mdev patches to remove the legacy interface that is now
>    unused to the end of the series
> 
> Changes since v1:
>  - rebased on Linux 5.15
>  - allow the kvmgvt module to be loaded at any time and thus solve
>    the deadlock when both i915 amd kvmgvt are modular
>  - include the conversion to the modern mdev API
> 
> Note that I do expect to rebased this again against 5.16-rc1 once
> released, but I'd like to get this out for review ASAP.
> 
> Diffstat:
>  b/drivers/gpu/drm/i915/Kconfig          |   33 
>  b/drivers/gpu/drm/i915/Makefile         |   31 
>  b/drivers/gpu/drm/i915/gvt/cfg_space.c  |   89 --
>  b/drivers/gpu/drm/i915/gvt/cmd_parser.c |    4 
>  b/drivers/gpu/drm/i915/gvt/dmabuf.c     |   36 -
>  b/drivers/gpu/drm/i915/gvt/execlist.c   |   12 
>  b/drivers/gpu/drm/i915/gvt/gtt.c        |   55 +
>  b/drivers/gpu/drm/i915/gvt/gvt.h        |  125 ++-
>  b/drivers/gpu/drm/i915/gvt/interrupt.c  |   38 +
>  b/drivers/gpu/drm/i915/gvt/kvmgt.c      | 1099 +++++++++++++++-----------------
>  b/drivers/gpu/drm/i915/gvt/mmio.c       |    4 
>  b/drivers/gpu/drm/i915/gvt/opregion.c   |  148 ----
>  b/drivers/gpu/drm/i915/gvt/page_track.c |    8 
>  b/drivers/gpu/drm/i915/gvt/scheduler.c  |   37 -
>  b/drivers/gpu/drm/i915/gvt/trace.h      |    2 
>  b/drivers/gpu/drm/i915/gvt/vgpu.c       |   22 
>  b/drivers/gpu/drm/i915/i915_drv.c       |    7 
>  b/drivers/gpu/drm/i915/i915_drv.h       |    1 
>  b/drivers/gpu/drm/i915/i915_trace.h     |    1 
>  b/drivers/gpu/drm/i915/intel_gvt.c      |  162 +++-
>  b/drivers/gpu/drm/i915/intel_gvt.h      |   17 
>  drivers/gpu/drm/i915/gvt/Makefile       |    9 
>  drivers/gpu/drm/i915/gvt/gvt.c          |  340 ---------
>  drivers/gpu/drm/i915/gvt/hypercall.h    |   82 --
>  drivers/gpu/drm/i915/gvt/mpt.h          |  400 -----------
>  25 files changed, 929 insertions(+), 1833 deletions(-)
> 

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Jani Nikula]

On Wed, 13 Apr 2022, Christoph Hellwig <hch@lst.de> wrote:
> On Wed, Apr 13, 2022 at 01:47:05PM +0000, Wang, Zhi A wrote:
>> > the GVT code in the i915 is a bit of a mess right now due to strange
>> > abstractions and lots of indirect calls.  This series refactors various
>> > bits to clean that up.  The main user visible change is that almost all
>> > of the GVT code moves out of the main i915 driver and into the kvmgt
>> > module.
>> 
>> Hi Christoph:
>> 
>> Do you want me to merge the GVT-g patches in this series? Or you want them to get merged from your side?
>
> The two option here are drm tree via gvt and i915 trees or the vfio
> tree, neither of which really is my tree.
>
> We already have a fair bit of vfio changes at the tail end of the series,
> and Jason has some more that should sit on top of it, and I have some
> more that I haven't sent yet.
>
> So if we could get the MMIO table and Makefile cleanups into a topic
> branch that we could pull into the vfio tree and merge it through that
> that would seem easiest to me, assuming that is ok with the i915, drm
> and vfio maintainers.

AFAICS the changes are mostly to gvt/, and at least I'm fine with the
minor changes to i915 (in this series and in my two patches) being
merged via whichever tree you all see fit.

Acked-by: Jani Nikula <jani.nikula@intel.com>

Joonas, Tvrtko, Rodrigo, chime in now if you have any issues with that.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Wang, Zhi A]

Hi folks:

Thanks so much for the efforts. I prepared a branch which contains all our patches.The aim of the branch is for the VFIO maintainers to pull the whole bunch easily after the drm-intel-next got merged through drm (as one of the MMIO patches depends on a patch in drm-intel-next).

I dropped patch 4 and patch 5 as they have been covered by Jani's patches. Some conflicts was solved.
QA is going to test it today. 

You can find it here:

git clone https://github.com/intel/gvt-linux -b for-christoph

Thanks,
Zhi.

On 4/13/22 3:58 PM, Jani Nikula wrote:
> On Wed, 13 Apr 2022, Christoph Hellwig <hch@lst.de> wrote:
>> On Wed, Apr 13, 2022 at 01:47:05PM +0000, Wang, Zhi A wrote:
>>>> the GVT code in the i915 is a bit of a mess right now due to strange
>>>> abstractions and lots of indirect calls.  This series refactors various
>>>> bits to clean that up.  The main user visible change is that almost all
>>>> of the GVT code moves out of the main i915 driver and into the kvmgt
>>>> module.
>>>
>>> Hi Christoph:
>>>
>>> Do you want me to merge the GVT-g patches in this series? Or you want them to get merged from your side?
>>
>> The two option here are drm tree via gvt and i915 trees or the vfio
>> tree, neither of which really is my tree.
>>
>> We already have a fair bit of vfio changes at the tail end of the series,
>> and Jason has some more that should sit on top of it, and I have some
>> more that I haven't sent yet.
>>
>> So if we could get the MMIO table and Makefile cleanups into a topic
>> branch that we could pull into the vfio tree and merge it through that
>> that would seem easiest to me, assuming that is ok with the i915, drm
>> and vfio maintainers.
> 
> AFAICS the changes are mostly to gvt/, and at least I'm fine with the
> minor changes to i915 (in this series and in my two patches) being
> merged via whichever tree you all see fit.
> 
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> 
> Joonas, Tvrtko, Rodrigo, chime in now if you have any issues with that.
> 
> 
> BR,
> Jani.
> 
> 

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Jason Gunthorpe]

On Wed, Apr 13, 2022 at 11:13:06PM +0000, Wang, Zhi A wrote:
> Hi folks:
> 
> Thanks so much for the efforts. I prepared a branch which contains all our patches.The aim of the branch is for the VFIO maintainers to pull the whole bunch easily after the drm-intel-next got merged through drm (as one of the MMIO patches depends on a patch in drm-intel-next).
> 
> I dropped patch 4 and patch 5 as they have been covered by Jani's patches. Some conflicts was solved.
> QA is going to test it today. 
> 
> You can find it here:
> 
> git clone https://github.com/intel/gvt-linux -b for-christoph

There are alot of extra commits on there - is it possible to base this
straight on rc1 not on some kind of existing DRM tree?

Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly
from frontbuffer flush  as a base?

Jason

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Wang, Zhi A]

On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
> On Wed, Apr 13, 2022 at 11:13:06PM +0000, Wang, Zhi A wrote:
>> Hi folks:
>>
>> Thanks so much for the efforts. I prepared a branch which contains all our patches.The aim of the branch is for the VFIO maintainers to pull the whole bunch easily after the drm-intel-next got merged through drm (as one of the MMIO patches depends on a patch in drm-intel-next).
>>
>> I dropped patch 4 and patch 5 as they have been covered by Jani's patches. Some conflicts was solved.
>> QA is going to test it today. 
>>
>> You can find it here:
>>
>> git clone https://github.com/intel/gvt-linux -b for-christoph
> 
> There are alot of extra commits on there - is it possible to base this
> straight on rc1 not on some kind of existing DRM tree?
> 
> Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly
> from frontbuffer flush  as a base?
> 
> Jason
> 

Hi Jason:

I updated the branch. You can check if those are what you are expecting. :)

Thanks,
Zhi.

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Jason Gunthorpe]

On Thu, Apr 14, 2022 at 12:20:42PM +0000, Wang, Zhi A wrote:
> On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
> > On Wed, Apr 13, 2022 at 11:13:06PM +0000, Wang, Zhi A wrote:
> >> Hi folks:
> >>
> >> Thanks so much for the efforts. I prepared a branch which contains all our patches.The aim of the branch is for the VFIO maintainers to pull the whole bunch easily after the drm-intel-next got merged through drm (as one of the MMIO patches depends on a patch in drm-intel-next).
> >>
> >> I dropped patch 4 and patch 5 as they have been covered by Jani's patches. Some conflicts was solved.
> >> QA is going to test it today. 
> >>
> >> You can find it here:
> >>
> >> git clone https://github.com/intel/gvt-linux -b for-christoph
> > 
> > There are alot of extra commits on there - is it possible to base this
> > straight on rc1 not on some kind of existing DRM tree?
> > 
> > Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly
> > from frontbuffer flush  as a base?
> > 
> > Jason
> > 
> 
> Hi Jason:
> 
> I updated the branch. You can check if those are what you are expecting. :)

This is better, except for the first commit:

 [DON'T PULL] drm/i915/dmc: split out dmc registers to a separate file
 THIS PATCH WILL GO THROUGH DRM-INTEL-NEXT TO UPSTREAM

 Clean up the massive i915_reg.h a bit with this isolated set of
 registers.

 v2: Remove stale comment (Lucas)

Clean the commit message and send that as a proper PR to
drm-intel-next, then everything else is OK.

Jason

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Wang, Zhi A]

On 4/14/22 1:34 PM, Jason Gunthorpe wrote:
> On Thu, Apr 14, 2022 at 12:20:42PM +0000, Wang, Zhi A wrote:
>> On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
>>> On Wed, Apr 13, 2022 at 11:13:06PM +0000, Wang, Zhi A wrote:
>>>> Hi folks:
>>>>
>>>> Thanks so much for the efforts. I prepared a branch which contains all our patches.The aim of the branch is for the VFIO maintainers to pull the whole bunch easily after the drm-intel-next got merged through drm (as one of the MMIO patches depends on a patch in drm-intel-next).
>>>>
>>>> I dropped patch 4 and patch 5 as they have been covered by Jani's patches. Some conflicts was solved.
>>>> QA is going to test it today. 
>>>>
>>>> You can find it here:
>>>>
>>>> git clone https://github.com/intel/gvt-linux -b for-christoph
>>>
>>> There are alot of extra commits on there - is it possible to base this
>>> straight on rc1 not on some kind of existing DRM tree?
>>>
>>> Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly
>>> from frontbuffer flush  as a base?
>>>
>>> Jason
>>>
>>
>> Hi Jason:
>>
This one belongs to i915, which has already been queued in drm-intel-next, but
not yet reached to the top. When it is landed in -rc, I will rebase this branch
on it, then we can drop this patch in this branch.

>> I updated the branch. You can check if those are what you are expecting. :)
> 
> This is better, except for the first commit:
> 
>  [DON'T PULL] drm/i915/dmc: split out dmc registers to a separate file
>  THIS PATCH WILL GO THROUGH DRM-INTEL-NEXT TO UPSTREAM
> 
>  Clean up the massive i915_reg.h a bit with this isolated set of
>  registers.
> 
>  v2: Remove stale comment (Lucas)
> 
> Clean the commit message and send that as a proper PR to
> drm-intel-next, then everything else is OK.
> 
> Jason
> 

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Jason Gunthorpe]

On Thu, Apr 14, 2022 at 01:39:11PM +0000, Wang, Zhi A wrote:
> On 4/14/22 1:34 PM, Jason Gunthorpe wrote:
> > On Thu, Apr 14, 2022 at 12:20:42PM +0000, Wang, Zhi A wrote:
> >> On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
> >>> On Wed, Apr 13, 2022 at 11:13:06PM +0000, Wang, Zhi A wrote:
> >>>> Hi folks:
> >>>>
> >>>> Thanks so much for the efforts. I prepared a branch which contains all our patches.The aim of the branch is for the VFIO maintainers to pull the whole bunch easily after the drm-intel-next got merged through drm (as one of the MMIO patches depends on a patch in drm-intel-next).
> >>>>
> >>>> I dropped patch 4 and patch 5 as they have been covered by Jani's patches. Some conflicts was solved.
> >>>> QA is going to test it today. 
> >>>>
> >>>> You can find it here:
> >>>>
> >>>> git clone https://github.com/intel/gvt-linux -b for-christoph
> >>>
> >>> There are alot of extra commits on there - is it possible to base this
> >>> straight on rc1 not on some kind of existing DRM tree?
> >>>
> >>> Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly
> >>> from frontbuffer flush  as a base?
> >>>
> >>> Jason
> >>>
> >>
> >> Hi Jason:
> >>
> This one belongs to i915, which has already been queued in drm-intel-next, but
> not yet reached to the top. When it is landed in -rc, I will rebase this branch
> on it, then we can drop this patch in this branch.

A commit called 'split out dmc registers' with no Fixes: will be sent
to a rc?

Jason

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Jani Nikula]

On Thu, 14 Apr 2022, Jason Gunthorpe <jgg@nvidia.com> wrote:
> On Thu, Apr 14, 2022 at 01:39:11PM +0000, Wang, Zhi A wrote:
>> This one belongs to i915, which has already been queued in drm-intel-next, but
>> not yet reached to the top. When it is landed in -rc, I will rebase this branch
>> on it, then we can drop this patch in this branch.
>
> A commit called 'split out dmc registers' with no Fixes: will be sent
> to a rc?

Won't. It's in drm-intel-next (and drm-next), headed to v5.19.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Jani Nikula]

On Thu, 14 Apr 2022, Jason Gunthorpe <jgg@nvidia.com> wrote:
> On Thu, Apr 14, 2022 at 12:20:42PM +0000, Wang, Zhi A wrote:
>> On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
>> > On Wed, Apr 13, 2022 at 11:13:06PM +0000, Wang, Zhi A wrote:
>> >> Hi folks:
>> >>
>> >> Thanks so much for the efforts. I prepared a branch which contains all our patches.The aim of the branch is for the VFIO maintainers to pull the whole bunch easily after the drm-intel-next got merged through drm (as one of the MMIO patches depends on a patch in drm-intel-next).
>> >>
>> >> I dropped patch 4 and patch 5 as they have been covered by Jani's patches. Some conflicts was solved.
>> >> QA is going to test it today. 
>> >>
>> >> You can find it here:
>> >>
>> >> git clone https://github.com/intel/gvt-linux -b for-christoph
>> > 
>> > There are alot of extra commits on there - is it possible to base this
>> > straight on rc1 not on some kind of existing DRM tree?
>> > 
>> > Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly
>> > from frontbuffer flush  as a base?
>> > 
>> > Jason
>> > 
>> 
>> Hi Jason:
>> 
>> I updated the branch. You can check if those are what you are expecting. :)
>
> This is better, except for the first commit:
>
>  [DON'T PULL] drm/i915/dmc: split out dmc registers to a separate file
>  THIS PATCH WILL GO THROUGH DRM-INTEL-NEXT TO UPSTREAM
>
>  Clean up the massive i915_reg.h a bit with this isolated set of
>  registers.
>
>  v2: Remove stale comment (Lucas)
>
> Clean the commit message and send that as a proper PR to
> drm-intel-next, then everything else is OK.

It's already in drm-intel-next, I guess the problem is basing the branch
on something that doesn't have it. I'd probably just base everything
cleanly on -rc1, and whoever does the merge between the two will need to
account for the missing include in the result. It's just adding one line
in the right place.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Jason Gunthorpe]

On Thu, Apr 14, 2022 at 04:40:11PM +0300, Jani Nikula wrote:

> >> >> git clone https://github.com/intel/gvt-linux -b for-christoph
> >> > 
> >> > There are alot of extra commits on there - is it possible to base this
> >> > straight on rc1 not on some kind of existing DRM tree?
> >> > 
> >> > Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly
> >> > from frontbuffer flush  as a base?
> >> > 
> >> > Jason
> >> > 
> >> 
> >> Hi Jason:
> >> 
> >> I updated the branch. You can check if those are what you are expecting. :)
> >
> > This is better, except for the first commit:
> >
> >  [DON'T PULL] drm/i915/dmc: split out dmc registers to a separate file
> >  THIS PATCH WILL GO THROUGH DRM-INTEL-NEXT TO UPSTREAM
> >
> >  Clean up the massive i915_reg.h a bit with this isolated set of
> >  registers.
> >
> >  v2: Remove stale comment (Lucas)
> >
> > Clean the commit message and send that as a proper PR to
> > drm-intel-next, then everything else is OK.
> 
> It's already in drm-intel-next, I guess the problem is basing the branch
> on something that doesn't have it. I'd probably just base everything
> cleanly on -rc1, and whoever does the merge between the two will need to
> account for the missing include in the result. It's just adding one line
> in the right place.

That makes sense to me, especially if you can do the merge fixup
internally in DRM.

So drop the '[DONT PULL]' commit and send a PR to the next DRM tree -
when that is confirmed send the same PR to vfio,

Thanks,
Jason

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Wang, Zhi A]

On 4/14/22 1:43 PM, Jason Gunthorpe wrote:
> On Thu, Apr 14, 2022 at 04:40:11PM +0300, Jani Nikula wrote:
> 
>>>>>> git clone https://github.com/intel/gvt-linux -b for-christoph
>>>>>
>>>>> There are alot of extra commits on there - is it possible to base this
>>>>> straight on rc1 not on some kind of existing DRM tree?
>>>>>
>>>>> Why did you choose drm/i915/fbc: Call intel_fbc_activate() directly
>>>>> from frontbuffer flush  as a base?
>>>>>
>>>>> Jason
>>>>>
>>>>
>>>> Hi Jason:
>>>>
>>>> I updated the branch. You can check if those are what you are expecting. :)
>>>
>>> This is better, except for the first commit:
>>>
>>>  [DON'T PULL] drm/i915/dmc: split out dmc registers to a separate file
>>>  THIS PATCH WILL GO THROUGH DRM-INTEL-NEXT TO UPSTREAM
>>>
>>>  Clean up the massive i915_reg.h a bit with this isolated set of
>>>  registers.
>>>
>>>  v2: Remove stale comment (Lucas)
>>>
>>> Clean the commit message and send that as a proper PR to
>>> drm-intel-next, then everything else is OK.
>>
>> It's already in drm-intel-next, I guess the problem is basing the branch
>> on something that doesn't have it. I'd probably just base everything
>> cleanly on -rc1, and whoever does the merge between the two will need to
>> account for the missing include in the result. It's just adding one line
>> in the right place.
> 
> That makes sense to me, especially if you can do the merge fixup
> internally in DRM.
> 
> So drop the '[DONT PULL]' commit and send a PR to the next DRM tree -
> when that is confirmed send the same PR to vfio,

I updated the branch again, but I am confused. What is the purpose of sending
the PR to next DRM tree? I suppose all the patches will go through VFIO? If
I understand correctly?
> 
> Thanks,
> Jason
> 

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Jason Gunthorpe]

On Thu, Apr 14, 2022 at 02:25:36PM +0000, Wang, Zhi A wrote:

> > So drop the '[DONT PULL]' commit and send a PR to the next DRM tree -
> > when that is confirmed send the same PR to vfio,
> 
> I updated the branch again, but I am confused. What is the purpose of sending
> the PR to next DRM tree? I suppose all the patches will go through VFIO? If
> I understand correctly?

pull requests can flow through more than one tree concurrently. The
purpose of the topic branch is to allow all the commits to be in all
the trees they need to be in at once.

So you should send this branch as a PR to the next logical upstream
tree gvt patches normally go through, in the usual way that you send
PRs. Especially in this case where there is a small merge conflict
internal to DRM to resolve. I'm assuming this is the drm-intel-next
tree?

Once DRM is internally happy then VFIO can merge it as well. You can
view VFIO as the secondary path to Linus, DRM as primary. Alex will
mention in his pull request that VFIO has a 'shared branch with DRM
for gvt'.

Jason

Re: refactor the i915 GVT support and move to the modern mdev API v3

[Wang, Zhi A]

On 4/20/22 7:08 AM, Christoph Hellwig wrote:
> On Thu, Apr 14, 2022 at 11:38:59AM -0300, Jason Gunthorpe wrote:
>> pull requests can flow through more than one tree concurrently. The
>> purpose of the topic branch is to allow all the commits to be in all
>> the trees they need to be in at once.
>>
>> So you should send this branch as a PR to the next logical upstream
>> tree gvt patches normally go through, in the usual way that you send
>> PRs. Especially in this case where there is a small merge conflict
>> internal to DRM to resolve. I'm assuming this is the drm-intel-next
>> tree?
>>
>> Once DRM is internally happy then VFIO can merge it as well. You can
>> view VFIO as the secondary path to Linus, DRM as primary. Alex will
>> mention in his pull request that VFIO has a 'shared branch with DRM
>> for gvt'.
> 
> Where do we stand here?  The (somewhat misnamed) topic/for-christoph
> branch looks fine to me now except for the mіssing "static inline" on
> the intel_gvt_iterate_mmio_table stub.
> 
> When can we expect it in the i915 tree and linux-next?
> 
Qur QA finished the test yesterday and I just made a tag. The pull
request is going to be sent today. Yes, I will fix that.

Thanks,
Zhi.