Hi:
Thanks Kevin! See my comments below.
On 02/16/16 11:11, Tian, Kevin wrote:
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.
@Daniel, Just want to clarify the "new top-level entry functions "here,
should I refine the related i915 APIs as below:
int xengt_i915_api()
{
call i915_common_low_level_api();
}
or:
native_callbacks();
xengt_callbacks();
int i915_api(*callbacks);
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)
OK. That's much better! we could still keep some bitfield extraction
routines inside GVT-g.
Thanks
Kevin
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
