Yep, if you can upstream enough for iGVT-g to be functional using
mainline kernel 4.10, then sure, having an updated ISO probably
wouldn't be of much benefit.
But if you expect to need another kernel iteration for upstreaming,
then I hope that maybe, in the meantime, you can release an updated
ISO (preferably based on a newer version of Ubuntu and a newer kernel)
to make testing easier.
On Wed, Dec 7, 2016 at 4:49 AM, Jike Song <jike.song(a)intel.com> wrote:
On 12/07/2016 03:00 PM, Gizmo Chicken wrote:
> Hi Jike,
> I read on Phoronix that the iGVT-g team is nearly ready to submit more
> code for upstreaming. See
> Congratulations to the entire iGVT-g team for making great progress on
> such a challenging project!
Thanks sincerely for your support ever since the very beginning :-)
The upstreaming is not yet fully done, but the most important part is in,
and I guess the others will be done shortly.
> I do NOT want to ask anything of you or the iGVT-g team that will
> divert work from your upstreaming efforts. But once your upstreaming
> efforts have slowed down a bit, I hope that it may be possible to
> update the pre-built ISO referenced in the instructions found here:
> The pre-built ISO referenced in the instructions is found here:
> Note that, although the "last modified" date is 2016-09-05 for the
> ISO, the actual build date seems to have been about 2016-05-24. And I
> think that there have been many improvements since then.
> Again, please don't update the pre-built ISO if doing so will divert
> work from your upstreaming efforts. But once your upstreaming efforts
> have slowed down a bit, I hope that it may be possible to release an
> updated pre-built ISO version, so that more people can test iGVT-g
> while waiting for it to reach the distributions.
Yes the ISO is kind of old, it should have been updated to newer versions.
On the other hand, we will eventually get all codes upstreamed into mainline
kernel/hypervisor, and it will effectively make the ISO unnecessary - that is,
running a KVM guest with Intel vGPU support would be quite easy.
Hongbo will make the decision if we should update the ISO before its being
obsoleted by the upstreaming effort :-)
> Thanks again to you and the entire iGVT-g team for working so hard on
> this project!
> Best regards,
Personally I'm not even the one who made the most incredible thing happen,
but hey, I'm pretty sure that everyone in the team will be flattered by
your compliment and thrilled to have so passionate users .. :-)
> On Sun, Nov 6, 2016 at 10:23 AM, Jike Song <jike.song(a)intel.com> wrote:
>> Hi all,
>> While spending efforts for upstreaming, we are pleased to announce another update
of Intel GVT-g for KVM.
>> Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with
mediated pass-through, starting from 5th generation Intel Core(TM) processors with Intel
Graphics processors. A virtual GPU instance is maintained for each VM, with part of
performance critical resources directly assigned. The capability of running native
graphics driver inside a VM, without hypervisor intervention in performance critical
paths, achieves a good balance among performance, feature, and sharing capability.
>> - Kernel: https://github.com/01org/igvtg-kernel
>> - Qemu: https://github.com/01org/igvtg-qemu
>> This update consists of:
>> - Preliminary support new platform: KabyLake, for windows OS, it only supports
Win10 RedStone 64 bit.
>> - Windows 10 RedStone guest Support
>> - Windows Guest QoS preliminary support: Administrators now are able to
control the maximum amount of vGPU resource to be consumed by each VM from value 1% ~
>> - Display virtualization preliminary support: Besides the tracking of display
register visit in guest VM, removing irrelative display pipeline info between host and
>> - Live Migration and savevm/restorevm preliminary support on BDW with 2D/3D
>> Known issues:
>> - At least 2GB memory is suggested for Guest Virtual Machine (win7-32/64,
win8.1-64, win10-64) to run most 3D workloads
>> - Windows8 and later Windows fast boot is not supported, the workaround is to
disable power S3/S4 in HVM file by adding "acpi_S3=0, acpi_S4=0"
>> - Sometimes when dom0 and guest has heavy workload, i915 in dom0 will trigger a
false-alarmed TDR. The workaround is to disable dom0 hangcheck in dom0 grub file by adding
>> - Stability: When QoS feature is enabled, Windows guest full GPU reset is often
trigger during MTBF test. This bug will be fixed in next release
>> - Windows guest running OpenCL allocations occurs to host crash; the workaround
is to disable logd in dom0 grub file by adding "i915.logd_enable=0"
>> Please subscribe the mailing list: https://lists.01.org/mailman/listinfo/igvt-g
>> Official iGVT-g portal: https://01.org/igvt-g
>> More information about background, architecture and others about Intel GVT-g, can
be found at:
>> The KVMGT project should be considered a work in progress. As such it is not a
complete product nor should it be considered one. Extra care should be taken when testing
and configuring a system to use the KVMGT project.