Re: [libvirt] [PATCH 0/3] sample: vfio mdev display devices.
-----Original Message-----
From: intel-gvt-dev [mailto:intel-gvt-dev-bounces@lists.freedesktop.org] On
Behalf Of Alex Williamson
Sent: Wednesday, April 25, 2018 1:36 AM
To: Gerd Hoffmann <kraxel(a)redhat.com>
Cc: kvm(a)vger.kernel.org; Erik Skultety <eskultet(a)redhat.com>; libvirt <libvir-
list(a)redhat.com>; Zhang, Tina <tina.zhang(a)intel.com>;
kwankhede(a)nvidia.com; intel-gvt-dev(a)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(a)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(a)lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev