[vfio-users] Mediated device interface + nvidia

[Jike Song]

[ I didn't monitor this list a lot, sorry :) ]

On 12/16/2016 06:23 AM, Alex Williamson wrote:
> On Thu, 15 Dec 2016 21:01:19 +0000
> Zir Blazer <zir_blazer at hotmail.com> wrote:
> 
>>> This guide still indicates support for 4th generation (aka
>>> Haswell), but I don't know how accurate it is:
>>>
>>> https://github.com/01org/gvt-linux/wiki/GVTg_Setup_Guide  
>>
>> Probabily a typo or oversight. Here is a quote straight from one of the Intel devs from less than a month ago on iGVT-g Mailing List:
>> https://lists.01.org/pipermail/igvt-g/2016-November/001024.html
>>
>> Q: Will Haswell ever be put back into the validation matrix and possibly considered for KVM support?
>> A: Unfortunately, the answer is no. :(
>> KVMGT supported platform starts from Broadwell (including Broadwell). We have no plan to add Haswell platform code into KVMGT because Broadwell GPU has big difference with Haswell's.
> 
> 
> I had assumed Broadwell since that's where support for Universal
> Pass-Thru (UPT) mode starts for direct assigned IGD, but the setup
> guide got my hopes up.  Darn.
> 

The decision that not supporting HSW in upstream was made according to the
fact that it is highly differently from BDW+ in consideration of graphics
implementations.

I guess it costs a lot to maintain the HSW support in GVT-g device-model, which
apparently cannot share much with BDW+. I'm sorry if you happen to have
a HSW and KVMGT is wanted, it seems the non-upstream implementation (2016Q3?)
serves as a mitigation :-)

>>> One of the advantages of the vfio mediated device interface is that API
>>> exposed to the user, and thus QEMU, is identical to a directly assigned
>>> device.  Therefore AFAIK, there are no QEMU changes necessary for
>>> KVMGT.  
>> As far that I recall, QEMU modifications were required because iGVT-g added a lot of new invokation parameters, but I checked the new KVMGT Setup Guide you linked, and it seems that they changed the procedure a bit.
>>
>> As of Sep 2016, according to near the end of this file:
>> https://01.org/igvt-g/blogs/wangbo85/2016/kvmgt-environment-setup-guide-using-gvt-g-installation-iso
>> ...in order to use iGVT-g in a VM, you had to invoke QEMU using these custom parameters:
>>
>> -vgt
>> -vga vgt
>> -vgt_high_gm_sz 384
>> -vgt_fence_sz 4
>> -vgt_low_gm_sz 128
>>
>>
>> On the guide you listed, here:
>> https://github.com/01org/gvt-linux/wiki/GVTg_Setup_Guide
>> ...instead, you use some command line parameters to create a vGPU in the host, then invoke QEMU with -device vfio-pci as if you were doing Passthrough but with a sysfsdev parameter pointing to the vGPU:
>>
>> -vga none
>> -device isa-vga
>> -device vfio-pci,sysfsdev=/sys/bus/pci/devices/0000:00:02.0/894f3983-1a36-42b3-b52c-1024aca216be
>>
>>
>> I didn't followed what changes they did to get the iGVT-g support upstream, but previously QEMU also needed a few tweaks to work with it. I suppose that some logic that they used to do in their custom QEMU got moved into the Kernel and thus it may work without further modifications, as you said.
> 
> 
> Prior to this summer Intel was on a very different path to enable KVMGT
> through QEMU.  Earlier prototypes used a completely different
> architecture from what we have now, so I'm not surprised that you can
> find older guides with QEMU options that exist anymore.  Thanks,

Yes, exactly. Before VFIO/MDEV, the MPT part of KVMGT is implemented mainly in 
kvm.ko, and QEMU (and even seabios!) needs to be modified.

--
Thanks,
Jike