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 <zhiyuan.lv(a)intel.com> wrote:
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
> 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
> hypervisor to initiate registration?
Then we need to have one more kernel module for each hypervisor right? The
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.
> iGVT-g mailing list