Hi Christoph:
Thanks so much for the patches and the testing.
The abstraction between i915 and KVMGT module is for our customers who can easily port GVT-g into their own hypervisors. As you can see, all the hypervisor related functions were put in "hypervisor" module. The GVT-g module talks with the "hypervisor" module through the MPT layer. The customers just need to focus on their "hypervisor" module, implement and attach their own "hypervisor" modules to the MPT layer without touching the GVT-g core logic, which reduce great efforts during the porting as the core logic of GVT-g in i915 is pretty vendor-specific and customers aren't motivated to touch it unless they have to.
The boundary between GVT-g core logic and "hypervisor" module also helps a lot on narrowing down the problems when supporting our customers. According to our experience during the support, the less a customer touches the core logic, the less problem will be introduced.
We get many customers who are using commercial hypervisors like QNX or their private hypervisors in many areas in the industry. An reference implementation of "Xen hypervisor" module to demonstrate our customer how to port GVT-g to a type-1 hypervisor instead of KVM can be found here: https://github.com/intel/gvt-linux/blob/topic/gvt-xengt/drivers/gpu/drm/i915...
But it's hard for some customers to contribute their own "hypervisor" module to the upstream Linux kernel. I am thinking what would be a better solution here? The MPT layer in the kernel helps a lot for customers, but only one open-source "hypervisor" module is there in the kernel. That can confuse people which don't know the story. One thing I was thinking is to put a document about the background and more description in the MPT headers. So it won't confuse more people.
Feel free to drop more comments. 😊
Thanks, Zhi.
-----Original Message----- From: Christoph Hellwig hch@lst.de Sent: Wednesday, July 21, 2021 6:54 PM To: Jani Nikula jani.nikula@linux.intel.com; Joonas Lahtinen joonas.lahtinen@linux.intel.com; Vivi, Rodrigo rodrigo.vivi@intel.com; Zhenyu Wang zhenyuw@linux.intel.com; Wang, Zhi A zhi.a.wang@intel.com Cc: intel-gfx@lists.freedesktop.org; intel-gvt-dev@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-kernel@vger.kernel.org Subject: refactor the i915 GVT support
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.
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
Diffstat: b/drivers/gpu/drm/i915/Kconfig | 31 b/drivers/gpu/drm/i915/Makefile | 30 b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 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.c | 100 -- b/drivers/gpu/drm/i915/gvt/gvt.h | 132 ++- b/drivers/gpu/drm/i915/gvt/interrupt.c | 38 - b/drivers/gpu/drm/i915/gvt/kvmgt.c | 634 ++++------------- 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.h | 7 b/drivers/gpu/drm/i915/i915_params.c | 2 b/drivers/gpu/drm/i915/intel_gvt.c | 64 + b/drivers/gpu/drm/i915/intel_gvt.h | 4 drivers/gpu/drm/i915/gvt/Makefile | 9 drivers/gpu/drm/i915/gvt/hypercall.h | 82 -- drivers/gpu/drm/i915/gvt/mpt.h | 400 ---------- 25 files changed, 541 insertions(+), 1413 deletions(-)