From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [libvirt] [PATCH 0/3] sample: vfio mdev display devices.
Date: Thu, 26 Apr 2018 09:44:45 -0600
Message-ID: <20180426094445.2175df21@w520.home>
References: <20180409103513.8020-1-kraxel@redhat.com>
	<20180418123153.0f4f037d@w520.home>
	<AADFC41AFE54684AB9EE6CBC0274A5D191138993@SHSMSX101.ccr.corp.intel.com>
	<20180426061427.h2glnfonfjpo6cr4@sirius.home.kraxel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Erik Skultety <eskultet@redhat.com>,
	libvirt <libvir-list@redhat.com>, "Zhang, Tina" <tina.zhang@intel.com>,
	"kwankhede@nvidia.com" <kwankhede@nvidia.com>,
	"intel-gvt-dev@lists.freedesktop.org" <intel-gvt-dev@lists.freedesktop.org>
To: Gerd Hoffmann <kraxel@redhat.com>
Return-path: <libvir-list-bounces@redhat.com>
In-Reply-To: <20180426061427.h2glnfonfjpo6cr4@sirius.home.kraxel.org>
List-Unsubscribe: <https://www.redhat.com/mailman/options/libvir-list>,
	<mailto:libvir-list-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/libvir-list>
List-Post: <mailto:libvir-list@redhat.com>
List-Help: <mailto:libvir-list-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/libvir-list>,
	<mailto:libvir-list-request@redhat.com?subject=subscribe>
Sender: libvir-list-bounces@redhat.com
Errors-To: libvir-list-bounces@redhat.com
List-Id: kvm.vger.kernel.org

On Thu, 26 Apr 2018 08:14:27 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:

> On Thu, Apr 26, 2018 at 03:44:15AM +0000, Tian, Kevin wrote:
> > > From: Alex Williamson
> > > Sent: Thursday, April 19, 2018 2:32 AM
> > > 
> > > That almost begins to look reasonable, but then we can only expose this
> > > for mdev devices, what if we were to hack a back door into a directly
> > > assigned GPU that tracks the location of active display in the
> > > framebuffer and implement the GFX_PLANE interface for that?  We have no
> > > sysfs representation for either the template or the actual device for
> > > anything other than mdev.  This inconsistency with physically assigned
> > > devices has been one of my arguments against enhancing mdev sysfs.  
> > 
> > One possible option is to wrap directly assigned GPU into a mdev. The
> > parent driver could be a dummy PCI driver which does basic PCI
> > initialization, and then provide hooks for vendor-specific hack.   
> 
> Thowing amdgpu into the mix.  Looks they have vgpu support too, but
> using sriov instead of mdev.  Having VFIO_GFX support surely looks
> useful there.  Adding a mdev dependency to the VFIO_GFX api would makes
> things more complicated there for (IMHO) no good reason ...

Yes, it may be that a device wanting to implement display or migration
might take the mdev approach, but that should be a choice of the
implementation, not a requirement imposed by the API.  Thanks,

Alex