[Intel-gfx] [PATCH 1/8] drm/i915: Introduce a PV INFO page structure for Intel GVT-g.

[Chris Wilson]

On Mon, Sep 29, 2014 at 07:44:56PM +0800, Jike Song wrote:
> On 09/19/2014 03:25 PM, Chris Wilson wrote:
> >Now, given that these are simply trapped memory access, wouldn't it be
> >simply to have:
> >
> >struct i915_virtual_gpu {
> >	struct vgt_if *if;
> >} vgu;
> >
> >static inline bool intel_vgpu_active(struct drm_i915_private *i915) { return i915->vgpu.if; }
> >
> >then you have constructs like
> >void i915_check_vgpu(struct drm_i915_private *i915)
> >{
> >	struct vgt_if *if;
> >
> >	if = i915->regs + VGT_PVINFO_PAGE;
> >	if (if->magic != VGT_MAGIC)
> >		return;
> >	
> >	if (INTEL_VGT_IF_VERSION !=
> >	    INTEL_VGT_IF_VERSION_ENCODE(if->version_major,
> >					if->version_minor))
> >		return;
> >
> >
> >	i915->vgpu.if = if;
> >}
> >
> >And later, for example:
> >
> >if (intel_vgpu_active(dev_priv))
> >	dev_priv->num_fence_regs = dev_priv->vgpu.if->fence_num;
> >
> 
> Hi Chris, sorry that I didn't understand you correctly. After discussion
> with Yu today, I realized that unfortunately, the vgt_if can't be
> dereferenced directly.
> 
> There are several reasons:
> 
> 	- dereferencing a MMIO address will be complained by sparse(1)
> 
> 	- for Guest VM, such accesses will be trapped by hypervisor, and
> 	  hence emulated correctly; However this doesn't work for Host(e.g.
> 	  Domain 0 of Xen, the Linux host KVM resides in). For host, we used
> 	  a proactive mechanism to redirect i915 MMIO accesses to vgt,
> 	  the GPU device-model, for the sake of central management & sharing
> 	  among VMs, including host.

You only need to be careful during vgpu detection. After that you know
everything is safe. If you do the detection during intel_uncore_init(),
or similar, you can use raw mmio access and explict sparse annotations
to do the right thing.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre