> -----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
