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
