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

[Yu, Zhang]

On 9/29/2014 8:40 PM, Jike Song wrote:
> On 09/29/2014 08:16 PM, Chris Wilson wrote:
>> 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
>
> Hi Chris,
>
> Thanks for your suggestion, however, it addressed issue #1 but not issue
> #2.
> I'd like to give a detailed explanation :)
>
> For Guest i915 driver, when accessing a MMIO reg, it goes:
>
>      whatever I915_READ/readl or direct dereferencing(addr)
>          addr is translated to gpa(guest physical address) by guest
> paging structure
>              hypervisor trapped the gpa access and forward it to vgt
>                  vgt_emulate_read32(vgt instance of guest, gpa)
>
>
> The real problem is, when running as the host gpu driver, i915 MMIO/GTT
> accesses are:
>
>      1) every difficult to trap, say the domain 0 of Xen hypervisor; or
>      2) impossible to trap, say KVM(In KVM, the host i915 is running in
> the very same
>         privilege level and root mode as KVM hypervisor.)
>
> So, for Host i915 driver, when accessing a MMIO reg, it goes:
>
>      I915_READ(addr)
>          gen6_read32(addr)
>              offset = addr - dev_priv->regs
>              vgt_mmio_readl(the vgt instance of host, offset)
>                  .. some processing ..
>                  if (passed-throuth)
>                      readl(offset + dev_priv->regs)
>                  else
>                      pa = BAR0 + offset
>                      vgt_emulate_read32(vgt instance of host, pa)
>
>
> The vgt_if corresponds to the PVINFO page, not passed-through(actually
> it doesn't physically exist),
> should fall into the "else" above.
>
> Given that ... Yes we can dereference pointers for guest here, but
> consider that we'll
> deal with host in the future ...
>
Hi Chris,

   Any comments on this issue?
   The host side patches were sent out by Jike last week. As you can see
in his patch, the I915_READ/WRITEs are redefined, and the MMIO accesses
are mediated to vgt, by offset of the regs, instead of by read/write 
(dev_priv->regs + offset) for host i915.
   So, in order to let i915 in the host side access the PVINFO page
successfully, could we still use the I915_READ/WRTE, and keep the
vgpu_active flag when detecting virtual gpu? :)

Thanks
Yu

>
> --
> Thanks,
> Jike
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>