Re: Discuss GVT context hacks in i915

[Zhi Wang <zhi.a.wang@intel.com>]

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx