On 09/12/2014 03:49, Tian, Kevin wrote: > - 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. :-) Could the virtual device model introduce new registers in order to avoid poking at the ISA bridge? I'm not sure that you "can leverage from GPU pass-through support once it's in Qemu", since the Xen IGD passthrough support is being added to a separate machine that is specific to Xen IGD passthrough; no ISA bridge hacking will probably be allowed on the "-M pc" and "-M q35" machine types. Paolo _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
