Here is some background of this KVMGT release: - the major purpose is for early experiment of this technique in KVM, and throw out issues about adding in-kernel device model (or mediated pass-through framework) in KVM. - KVMGT shares 90% code as XenGT, regarding to vGPU device model. The only difference is the in-kernel dm interface. The vGPU device model will be split and integrated in i915 driver. It will register to in-kernel dm framework provided either by Xen or KVM at boot time. Upstreaming of vGPU device model is already in progress, with valuable comments received from i915 community. However the refactoring mostly happen in XenGT repo now - Now we have XenGT/KVMGT separately maintained, and KVMGT lags behind XenGT regarding to features and qualities. Likely you'll continue see stale code (like Xen inst decoder) for some time. In the future we plan to maintain a single kernel repo for both, so KVMGT can share same quality as XenGT once KVM in-kernel dm framework is stable. - Regarding to Qemu hacks, KVMGT really doesn't have any different requirements as what have been discussed for GPU pass-through, e.g. about ISA bridge. Our implementation is based on an old Qemu repo, and honestly speaking not cleanly developed, because we know we can leverage from GPU pass-through support once it's in Qemu. At that time we'll leverage the same logic with minimal changes to hook KVMGT mgmt. APIs (e.g. create/destroy a vGPU instance). So we can ignore this area for now. :-) Thanks Kevin > From: Paolo Bonzini > Sent: Friday, December 05, 2014 9:04 PM > > > > On 05/12/2014 09:50, Gerd Hoffmann wrote: > > A few comments on the kernel stuff (brief look so far, also > > compile-tested only, intel gfx on my test machine is too old). > > > > * Noticed the kernel bits don't even compile when configured as > > module. Everything (vgt, i915, kvm) must be compiled into the > > kernel. > > I'll add that the patch is basically impossible to review with all the > XenGT bits still in. For example, the x86 emulator seems to be > unnecessary for KVMGT, but I am not 100% sure. > > I would like a clear understanding of why/how Andrew Barnes was able to > do i915 passthrough (GVT-d) without hacking the ISA bridge, and why this > does not apply to GVT-g. > > Paolo > > > * Design approach still seems to be i915 on vgt not the other way > > around. > > > > Qemu/SeaBIOS bits: > > > > I've seen the host bridge changes identity from i440fx to > > copy-pci-ids-from-host. Guess the reason for this is that seabios uses > > this device to figure whenever it is running on i440fx or q35. Correct? > > > > What are the exact requirements for the device? Must it match the host > > exactly, to not confuse the guest intel graphics driver? Or would > > something more recent -- such as the q35 emulation qemu has -- be good > > enough to make things work (assuming we add support for the > > graphic-related pci config space registers there)? > > > > The patch also adds a dummy isa bridge at 0x1f. Simliar question here: > > What exactly is needed here? Would things work if we simply use the q35 > > lpc device here? > > > > more to come after I've read the paper linked above ... > > > > cheers, > > Gerd > > > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
