[Intel-gfx] [PATCH v6 3/8] drm/i915: vgpu ppgtt update pv optimization

Zhang, Xiaolin xiaolin.zhang at intel.com
Mon Jun 10 07:47:35 UTC 2019


On 06/10/2019 03:44 PM, Chris Wilson wrote:
> Quoting Zhang, Xiaolin (2019-06-10 02:32:18)
>> On 06/04/2019 05:01 PM, Chris Wilson wrote:
>>> Quoting Xiaolin Zhang (2019-06-03 07:02:44)
>>>> +static void gen8_ppgtt_clear_4lvl_pv(struct i915_address_space *vm,
>>>> +                                 u64 start, u64 length)
>>>> +{
>>>> +       struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
>>>> +       struct i915_pml4 *pml4 = &ppgtt->pml4;
>>>> +       struct drm_i915_private *dev_priv = vm->i915;
>>>> +       struct pv_ppgtt_update *pv_ppgtt =
>>>> +                       &dev_priv->vgpu.shared_page->buf.pv_ppgtt;
>>>> +       u64 orig_start = start;
>>>> +       u64 orig_length = length;
>>>> +
>>>> +       gen8_ppgtt_clear_4lvl(vm, start, length);
>>>> +
>>>> +       pv_ppgtt->pdp = px_dma(pml4);
>>>> +       pv_ppgtt->start = orig_start;
>>>> +       pv_ppgtt->length = orig_length;
>>>> +       I915_WRITE(vgtif_reg(g2v_notify), VGT_G2V_PPGTT_L4_CLEAR);
>>>> +}
>>>> +
>>>> +static void gen8_ppgtt_insert_4lvl_pv(struct i915_address_space *vm,
>>>> +                                  struct i915_vma *vma,
>>>> +                                  enum i915_cache_level cache_level,
>>>> +                                  u32 flags)
>>>> +{
>>>> +       struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
>>>> +       struct drm_i915_private *dev_priv = vm->i915;
>>>> +       struct pv_ppgtt_update *pv_ppgtt =
>>>> +                       &dev_priv->vgpu.shared_page->buf.pv_ppgtt;
>>>> +
>>>> +       gen8_ppgtt_insert_4lvl(vm, vma, cache_level, flags);
>>>> +
>>>> +       pv_ppgtt->pdp = px_dma(&ppgtt->pml4);
>>>> +       pv_ppgtt->start = vma->node.start;
>>>> +       pv_ppgtt->length = vma->node.size;
>>>> +       pv_ppgtt->cache_level = cache_level;
>>>> +       I915_WRITE(vgtif_reg(g2v_notify), VGT_G2V_PPGTT_L4_INSERT);
>>>> +}
>>> For this to work, a vgpu mmio write must be trapped and suspend the
>>> client while the host processes the trap. Otherwise, we would be
>>> overwriting the side-channel before the host processes the command.
>>>
>>> That sounds horrible.
>>> -Chris
>> Chris, thanks your comment. do you think is the spin_lock to protect
>> this VGPU MMIO write enough to eliminate the side-channel effect?
> I would suggest you consider using a pair of command/response rings.
> -Chris
>
Chris, Thanks your suggestion and prompt response. I will rework them
for that direction.
BRs, Xiaolin




More information about the Intel-gfx mailing list