Hi Greg, On Thu, 2020-01-16 at 15:23 +0100, Greg KH wrote: > On Thu, Jan 16, 2020 at 03:13:01PM +0100, Julian Stecklina wrote: > > Hi Greg, Christoph, > > > > On Wed, 2020-01-15 at 16:22 +0100, Greg KH wrote: > > > On Thu, Jan 09, 2020 at 07:13:57PM +0200, Julian Stecklina wrote: > > > > Now that the GVT interface to hypervisors does not depend on i915/GVT > > > > internals anymore, we can move the headers to the global include/. > > > > > > > > This makes out-of-tree modules for hypervisor integration possible. > > > > > > What kind of out-of-tree modules do you need/want for this? > > > > The mediated virtualization support in the i915 driver needs a backend to > > the > > hypervisor. There is currently one backend for KVM in the tree > > (drivers/gpu/drm/i915/gvt/kvmgt.c) and at least 3 other hypervisor backends > > out > > of tree in various states of development that I know of. We are currently > > developing one of these. > > Great, then just submit this patch series as part of your patch series > when submitting yoru hypervisor code. That's the normal way to export > new symbols, we can't do so without an in-kernel user. Fair enough. As I already said, the KVMGT code is the in-kernel user. But I guess I can extend the already existing function pointer way of decoupling KVMGT from i915 and be on my way without exporting any symbols. Somewhat independent of the current discussion, I also think that it's valuable to have a defined API (I'm not saying stable API) for the hypervisor backends to define what's okay and not okay for them to do. Thanks, Julian _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
