Yes - I am trying to make use of iGVT in our own hypervisor, and am adding the necessary callbacks in our kernel module for the i915 driver to use. And I don't have to modify your code at all currently, except I have to change the registration in the i915 driver to call out to register with our module. If three other hypervisors with their own kernel modules wanted to work with gvt, three more cases would need to be added there in the i915 driver. That's why I was hoping it could request a generic symbol, rather than a symbol based on the name of the hypervisor (especially since it seems this is supposed to be a black box abstraction that enables any hypervisor to supply the right functionality).


On Mon, Sep 5, 2016 at 1:29 AM Zhiyuan Lv <> wrote:
Hi Brad,

On Fri, Sep 02, 2016 at 08:15:13PM +0000, Brad Bozarth wrote:
> In i915_start_vgt, the method of filling out the callback struct is to
> query two hardcoded options - xengt and kvm. This is not conducive to
> allowing another hypervisor to work with iGVT - though this seems to be the
> only spot where the split isn't a modular abstraction. Can this be made
> generic? Perhaps query a generic vgt_kdm symbol, or have an interface for a
> hypervisor to initiate registration?

Then we need to have one more kernel module for each hypervisor right? The new
module depends on both gvtg device model and hypervisor, providing the
registration. In our initial version for upstream, we may take the simplest
approach. At least for KVM, there might not be a separate kvmgt.ko. Comments
are welcome!


> Thanks,
> Brad

> _______________________________________________
> iGVT-g mailing list