LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Wang, Zhi A" <zhi.a.wang@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Christoph Hellwig <hch@lst.de>,
	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>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"intel-gvt-dev@lists.freedesktop.org" 
	<intel-gvt-dev@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: refactor the i915 GVT support
Date: Thu, 29 Jul 2021 08:19:15 +0000	[thread overview]
Message-ID: <9cab9765-79ce-fca0-3599-474f7ffb2034@intel.com> (raw)
In-Reply-To: <20210728175925.GU1721383@nvidia.com>

On 7/28/2021 8:59 PM, Jason Gunthorpe wrote:
> On Wed, Jul 28, 2021 at 01:38:58PM +0000, Wang, Zhi A wrote:
>
>> I guess those APIs you were talking about are KVM-only. For other
>> hypervisors, e.g. Xen, ARCN cannot use the APIs you mentioned. Not
>> sure if you have already noticed that VFIO is KVM-only right now.
> There is very little hard connection between VFIO and KVM, so no, I
> don't think that is completely true.
>
> In an event, an in-tree version of other hypervisor support for GVT
> needs to go through enabling VFIO support so that the existing API
> multiplexers we have can be used properly, not adding a shim layer
> trying to recreate VFIO inside a GPU driver.

We were delivering the presentation of GVT-g in Xen summit 2018 and we 
were thinking and talking about supporting VFIO in Xen during the 
presentation (the video can be found from Youtube). But we didn't see 
any motiviation from the Xen community to adopt it.

If people take a look into the code in QEMU, in the PCI-passthrough 
part, Xen is actually not using VFIO even nowadays. We would be glad to 
see someone can influence on that part, especically making all the 
in-kernel hypervisor to use VFIO in PCI-passthrough and supporting mdev. 
That would be a huge benefit for all the users.

>> GVT-g is designed for many hypervisors not only KVM. In the design,
>> we implemented an abstraction layer for different hypervisors. You
>> can check the link in the previous email which has an example of how
>> the MPT module "xengt" supports GVT-g running under Xen.  For
>> example, injecting a msi in VFIO/KVM is via playing with
>> eventfd. But in Xen, we need to issue a hypercall from Dom0.
> This is obviously bad design, Xen should plug into the standardized
> eventfd scheme as well and trigger its hypercall this way. Then it can
> integrate with the existing VFIO interrupt abstraction infrastructure.
>
>> others, like querying mappings between GFN and HFN.
> This should be done through VFIO containers, there is nothing KVM
> specific there.
>
>> As you can see, to survive from this situation, we have to rely on
>> an abstraction layer so that we can prevent introducing coding
>> blocks like in the core logic:
> No, you have to fix the abstractions we already have to support the
> matrix of things you care about. If this can't be done then maybe we
> can add new abstractions, but abstractions like this absoultely should
> not be done inside drivers.
>
> Jason

That's a good point and we were actually thinking about this before and 
I believe that's the correct direction. But just like the situation 
mentioned above, it would be nice if people can really put a great 
influence on all in-kernel hypervisors to use VFIO which can really 
benefit all the users.

For now, we are just going to take christoph's patches.

Zhi


  parent reply	other threads:[~2021-07-29  8:19 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21 15:53 Christoph Hellwig
2021-07-21 15:53 ` [PATCH 01/21] drm/i915/gvt: integrate into the main Makefile Christoph Hellwig
2021-08-03  9:27   ` Zhenyu Wang
2021-07-21 15:53 ` [PATCH 02/21] drm/i915/gvt: remove module refcounting in intel_gvt_{,un}register_hypervisor Christoph Hellwig
2021-07-21 15:53 ` [PATCH 03/21] drm/i915/gvt: remove enum hypervisor_type Christoph Hellwig
2021-07-21 15:53 ` [PATCH 04/21] drm/i915/gvt: move the gvt code into kvmgt.ko Christoph Hellwig
2021-08-09 11:29   ` Joonas Lahtinen
2021-08-09 14:29     ` Christoph Hellwig
2021-07-21 15:53 ` [PATCH 05/21] drm/i915/gvt: remove intel_gvt_ops Christoph Hellwig
2021-07-21 15:53 ` [PATCH 06/21] drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops Christoph Hellwig
2021-07-21 15:53 ` [PATCH 07/21] drm/i915/gvt: remove the unused from_virt_to_mfn op Christoph Hellwig
2021-07-21 15:53 ` [PATCH 08/21] drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu Christoph Hellwig
2021-07-21 15:53 ` [PATCH 09/21] drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpu Christoph Hellwig
2021-07-21 15:53 ` [PATCH 10/21] drm/i915/gvt: remove vgpu->handle Christoph Hellwig
2021-07-21 15:53 ` [PATCH 11/21] drm/i915/gvt: devirtualize ->{read,write}_gpa Christoph Hellwig
2021-07-21 15:53 ` [PATCH 12/21] drm/i915/gvt: devirtualize ->{get,put}_vfio_device Christoph Hellwig
2021-07-21 15:53 ` [PATCH 13/21] drm/i915/gvt: devirtualize ->set_edid and ->set_opregion Christoph Hellwig
2021-07-21 15:53 ` [PATCH 14/21] drm/i915/gvt: devirtualize ->detach_vgpu Christoph Hellwig
2021-07-21 15:53 ` [PATCH 15/21] drm/i915/gvt: devirtualize ->inject_msi Christoph Hellwig
2021-07-21 15:53 ` [PATCH 16/21] drm/i915/gvt: devirtualize ->is_valid_gfn Christoph Hellwig
2021-07-21 15:53 ` [PATCH 17/21] drm/i915/gvt: devirtualize ->gfn_to_mfn Christoph Hellwig
2021-07-21 15:53 ` [PATCH 18/21] drm/i915/gvt: devirtualize ->{enable,disable}_page_track Christoph Hellwig
2021-07-21 15:53 ` [PATCH 19/21] drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page Christoph Hellwig
2021-07-21 15:53 ` [PATCH 20/21] drm/i915/gvt: devirtualize dma_pin_guest_page Christoph Hellwig
2021-07-21 15:53 ` [PATCH 21/21] drm/i915/gvt: remove struct intel_gvt_mpt Christoph Hellwig
2021-07-22  9:45 ` refactor the i915 GVT support Zhenyu Wang
2021-07-22 12:55   ` Christoph Hellwig
2021-07-22 10:49 ` Wang, Zhi A
2021-07-22 11:26   ` Gerd Hoffmann
2021-07-27 12:12     ` Jason Gunthorpe
2021-07-28 13:38       ` Wang, Zhi A
2021-07-28 13:43         ` Greg KH
2021-07-28 17:59         ` Jason Gunthorpe
2021-07-29  7:20           ` Christoph Hellwig
2021-07-29  7:30             ` [Intel-gfx] " Daniel Vetter
2021-08-03  9:43             ` Zhenyu Wang
2021-08-03 14:30               ` Jason Gunthorpe
2021-08-04  5:26                 ` Zhenyu Wang
2021-08-16 17:34                   ` Christoph Hellwig
2021-08-17  1:08                     ` Zhenyu Wang
2021-08-17  5:22                       ` Zhenyu Wang
2021-08-19  8:29                         ` Zhenyu Wang
2021-08-19 14:43                           ` Joonas Lahtinen
2021-08-26  6:04                             ` Zhenyu Wang
2021-08-20 14:17                           ` Christoph Hellwig
2021-08-20 19:56                             ` Luis Chamberlain
2021-08-26  6:12                               ` Zhenyu Wang
2021-09-28  7:41                                 ` Wang, Zhi A
2021-09-28 14:00                                   ` Luis Chamberlain
2021-09-28 14:35                                     ` Wang, Zhi A
2021-09-28 15:05                                       ` Jason Gunthorpe
2021-09-29 18:27                                         ` Wang, Zhi A
2021-09-29 18:55                                           ` Jason Gunthorpe
2021-10-01 13:01                                             ` Wang, Zhi A
2021-10-05  7:33                                               ` Wang, Zhi A
2021-09-30  5:24                                           ` Christoph Hellwig
2021-08-26  6:08                             ` Zhenyu Wang
2021-08-04  5:40                 ` Christoph Hellwig
2021-07-29  8:19           ` Wang, Zhi A [this message]
2021-07-22 13:16   ` Greg KH

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=9cab9765-79ce-fca0-3599-474f7ffb2034@intel.com \
    --to=zhi.a.wang@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.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=joonas.lahtinen@linux.intel.com \
    --cc=kraxel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=zhenyuw@linux.intel.com \
    --subject='Re: refactor the i915 GVT support' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).