That's a good news! I'm exciting about waiting for KVMGT, too. For direct IGD assignment: You'll need to use remote access Silly question, is that mean host or guest? Also I heard about QEMU GTK(or VNC) may support KVMGT, that means it possible in IGD passthrough?
2016-03-21 23:11 GMT+08:00 Alex Williamson <alex.l.william...@gmail.com>: > On Mon, Mar 21, 2016 at 4:54 AM, Okky Hendriansyah <okky....@gmail.com> > wrote: > >> On March 21, 2016 at 12:32:28, eric griffith (egriffit...@gmail.com) >> wrote: >> >>> Details, Alex? What fun technology is enabling this? I didn't think >>> something like this was currently / soon-to-be possible. >>> On Mar 20, 2016 23:28, "Alex Williamson" <alex.l.william...@gmail.com> >>> wrote: >>> >>>> It's coming. If you have a Broadwell or newer CPU and intend to use >>>> only Windows guests with IGD as the secondary graphics device VM, you can >>>> pretty much do it now. If you have anything older (I'm only intended to go >>>> back as far as Sandybridge) or want to run a different guest or want to use >>>> IGD as primary in the guest, you'll need host kernel changes that are >>>> coming in v4.6, QEMU changes that may or may not make 2.6, and an updated >>>> SeaBIOS. >>>> >>> >> I think Alex was referring to Intel KVMGT [1]. >> > > No, I'm referring to direct IGD assignment. vGPU via KVMGT is also coming > and some of the vfio API changes that enable IGD assignment were developed > as enablers for vGPU support. For Broadwell and newer, simply assign IGD > as a secondary graphics device. Caveats: you won't get a local display, > you'll need to use remote access (I know, I know), only Windows guests seem > to work, and you'll need option kvm ignore_msrs=1. For further support, > you'll need a new kernel (will be in 4.6-rc1), qemu.git + patches ( > https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg02837.html), > and a seabios patch (http://patchwork.ozlabs.org/patch/583731/). Support > is of course in flux until this is accepted upstream. I'm trying to make > configuration as automatic as possible, if IGD is assigned at guest address > 00:02.0, VGA is available, and an option ROM is available, it assumes > legacy mode and should work for SandyBridge and newer devices with Linux or > Windows guests. If assigned to another guest address it will only enable > the OpRegion to make the local display work. OVMF is not yet supported. > Q35 machine types can only support secondary mode (Broadwell+). There are > also still issues to deal with for assigning the host primary graphics > device, i915 seems to be ok with unbinding the device, but not so much with > re-binding to the device after use. So you may want to manually unbind it > with virsh nodedev-detach prior to starting a VM. Using pci-stub.ids or > vfio-pci.ids isn't a clean solution either because other drivers like efifb > or vesafb will attach to the device regardless. I typically use a serial > console, let i915 claim the device, then use virsh nodedev-detach to unbind > for the VM. Thanks, > > Alex > > _______________________________________________ > vfio-users mailing list > vfio-users@redhat.com > https://www.redhat.com/mailman/listinfo/vfio-users > >
_______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
