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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@xxxxxxxxxxxxxxxxxxxxx] On
> Behalf Of Alex Williamson
> Sent: Wednesday, April 25, 2018 1:36 AM
> To: Gerd Hoffmann <kraxel@xxxxxxxxxx>
> Cc: kvm@xxxxxxxxxxxxxxx; Erik Skultety <eskultet@xxxxxxxxxx>; libvirt <libvir-
> list@xxxxxxxxxx>; Zhang, Tina <tina.zhang@xxxxxxxxx>;
> kwankhede@xxxxxxxxxx; intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH 0/3] sample: vfio mdev display devices.
> 
> On Tue, 24 Apr 2018 09:17:37 +0200
> Gerd Hoffmann <kraxel@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux