[libvirt] [PATCH 0/3] sample: vfio mdev display devices.

[Zhang, Tina]

> -----Original Message-----
> From: intel-gvt-dev [mailto:intel-gvt-dev-bounces at lists.freedesktop.org] On
> Behalf Of Alex Williamson
> Sent: Wednesday, April 25, 2018 1:36 AM
> To: Gerd Hoffmann <kraxel at redhat.com>
> Cc: kvm at vger.kernel.org; Erik Skultety <eskultet at redhat.com>; libvirt <libvir-
> list at redhat.com>; Zhang, Tina <tina.zhang at intel.com>;
> kwankhede at nvidia.com; intel-gvt-dev at lists.freedesktop.org
> Subject: Re: [PATCH 0/3] sample: vfio mdev display devices.
> 
> On Tue, 24 Apr 2018 09:17:37 +0200
> Gerd Hoffmann <kraxel at redhat.com> wrote:
> 
> >   Hi,
> >
> > > Here's another proposal that's really growing on me:
> > >
> > >  * Fix the vendor drivers!  Allow devices to be opened and probed
> > >    without these external dependencies.
> >
> > Hmm.  If you try use gvt with tcg then, wouldn't qemu think "device
> > probed ok, all green" then even though that isn't the case?
> 
> Well, is there a way to make it work with tcg?  That would be the best solution.
> Perhaps KVM could be handled as an accelerator rather than a required
> component.  I don't really understand how the page tracking interface is used
> and why it's not required by NVIDIA if it's so fundamental to GVT-g.  Otherwise,

GVT-g needs hypervisors' (like Xen or KVM) help to trap the guest GPU page table update,
so that GVT-g can update the shadow page table correctly, in host, with host physical address,
not guest physical address. As this page table is in memory, GVT-g needs hypervisors' help
to make it write protected, so that it can trap the updates on time.

> are there other points at which the device could refuse to be enabled, for
> instance what if the write to enable bus-master in the PCI command register
> returned an error if the device isn't fully configured.  Paolo had suggested offline

If we add some logic to let GVT-g support basic VFIO APIs even in tcg use case, could the following things be reasonable?
1. A dummy vGPU is created with an UUID.
2. When VFIO_DEVICE_GET_INFO is invoked by libvirt, GVT-g tells that this vGPU is actually a dummy one and cannot work.
3. Then libvirt choose not to boot a VM with this dummy vGPU.
4. Maybe we also need some logic to let a VM with this dummy vGPU boot and work just as there is no vGPU support.

Thanks.

BR,
Tina

> that maybe there could be a read-only mode of the device that allows probing.  I
> think that would be a fair bit of work and complexity to support, but I'm open to
> those sorts of ideas.  I can't be sure the NVIDIA requirement isn't purely for
> accounting purposes within their own proprietary userspace manager, without
> any real technical requirement.
> Hoping Intel and NVIDIA can comment on these so we really understand why
> these are in place before we bend over backwards for a secondary API interface.
> Thanks,
> 
> Alex
> _______________________________________________
> intel-gvt-dev mailing list
> intel-gvt-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev