[Intel-gfx] Discuss GVT context hacks in i915

[Tian, Kevin]

> From: Wang, Zhi A
> Sent: Tuesday, February 16, 2016 12:04 AM
> 
> The better design idea is to reuse the data structures and helper
> functions, but have new top-level entry functions for creating e.g. a
> xengt lrc context. So e.g. have a lrc init function for xengt which
> takes the setup stuff as parameters. Wrt ppgtt my idea was to reuse
> struct i915_hw_ppgtt for managing the shadow pagetable, with xengt using
> the i915_gem_gtt.c functions to write shadow pagetable entries. That way
> i915 still knows the virtual->physical mapping, which aids in e.g. crash
> dump recording. Of course you're not going to bind entire vma, but
> instead will use the lower-level functions that just bind pages.
> 
> [Zhi] Thanks! Just want to make sure that you prefer that GVT-g specific
> modifications should be put into a fork of top-level i915 APIs? For example,
> we prepare a new function to create the GVT context, which is a fork of
> simplified i915_gem_create_context().

Not specific for GVT. You need to make it generic to accept any lrc init
function where GVT is just one user.

> 
> For i915_hw_ppgtt and GVT-g shadow page table, we tried to think about how
> to merge these two similar things into one, but have some opens:
> 
> Most of the GTT/PPGTT page table entry routines in i915_gem_gtt.c, e.g. the
> abstractions/ insert_entries() are aimed to generate the page table entry, but
> GVT-g shadow page implementation also need the per-platform page table
> entry bit field extraction routines. For example, extract the GFN from guest page
> table, which means we have to add some new callbacks which native i915
> will not use at all.  Is it OK for host i915 to add such kinds of callbacks?

What Daniel suggested is to reuse low level functions to write shadow
PTE entries. It's not about how we sync shadow PTE content from guest
PTE content. So how to extract GFN from guest page table will be still
kept within GVT shadow code. Only when GVT shadow wants to operate
shadow PTE entries, it goes to i915_gem_gtt.c.

> 
> b.  GVT-g shadow page table implementation should be the most complicated
> part in GVT-g, maybe the first easy step should be putting the shadow page
> table root pointer into i915_hw_ppgtt. E.g. GVT-g allocates a fake i915_hw_ppgtt
> only use it to store root pointer and addressing mode bit?

Not a 'fake' one. It a real i915_hw_ppgtt but in a special mode that the 
actual mgmt. logic comes from another place (GVT shadow) but the low 
level interface can be reused (possibly some slight changes still required)

Thanks
Kevin