[ 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_bla...@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 _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
