[Intel-gfx] [RFC 01/29] drm/i915/gvt: Introduce the basic architecture of GVT-g

[Zhiyuan Lv]

On Wed, Feb 03, 2016 at 02:01:15PM +0800, Zhi Wang wrote:
> Hi Joonas:
>     Thanks you very much! We're very excited for receiving your
> advice and continue to be open to any comments. :)
> 
> I'm supposed that we should make the agreements on i915 host change
> at the very beginning, as I'm concerned during the discussion of
> i915 host change, you know, maybe some code of GVT-g needs to be
> refined or re-designed. So we put the i915 host changes to the
> beginning of the patch set for the convenience of discussion.
> 
> I summarize your comments as below, very applicate. :)
> 
> - Replace boolean return value with int as much as possible.
> - Replace customized debug ASSERT() function & macros with DRM_DEBUG_*
> - Document all non-static functions like i915
> - Fix all whitespace via scripts/cleanpatch.pl
> - Commit function structure refinement.
> - Change the register access behavior just like what i915 does.
> 
> For other comments, see my comments below. :)
> 
> On 01/29/16 21:57, Joonas Lahtinen wrote:

snip

> >>+		/* Xen Dom0 */
> >>+		host->kdm = try_then_request_module(symbol_get(xengt_kdm), "xengt");
> >>+		host->hypervisor_type = GVT_HYPERVISOR_TYPE_XEN;
> >>+	} else if(xen_domain()) {
> >>+		/* Xen DomU */
> >>+		return false;
> >>+	} else {
> >>+		/* not in Xen. Try KVMGT */
> >>+		host->kdm = try_then_request_module(symbol_get(kvmgt_kdm), "kvm");
> >>+		host->hypervisor_type = GVT_HYPERVISOR_TYPE_KVM;
> >>+	}
> >>+
> >
> >Why do we need to keep track of hypervisor type, are there plenty of
> >hypervisor specific behaviour differences?
> 
> [Zhi] As GVT-g needs some hypervisor services to work, we write a
> abstraction layer to connect GVT-g to different hypervisor. But
> still there are some emulation logic couldn't be fitted into that
> abstraction layer, like OpRegion emulation. In Xen, we emulates it
> in kernel space, while we emulates it in Qemu under KVM. I also

Just a small clarify: most likely the cfg-emulation for KVMGT will be
in kernel as well. This part is under discussion. But still we may
have code related to hypervisor type in device model, for instance,
VFIO based implementation for KVM only. Thanks!

Regards,
-Zhiyuan