[Intel-gfx] FW: Wrt golden MMIO/CFG snaphot in GVT-g

[Tian, Kevin]

> From: Joonas Lahtinen [mailto:joonas.lahtinen at linux.intel.com]
> Sent: Friday, May 27, 2016 7:32 PM
> 
> On pe, 2016-05-27 at 10:05 +0000, Wang, Zhi A wrote:
> > For me I think maybe i915 could save the snapshot for GVT, then GVT-g
> > patch the snapshot itself, then there won’t be leaking happened I
> > think. Even we wrote a dedicated little program, we would do the same
> > thing.
> >
> > From: Wang, Zhi A
> > Sent: Friday, May 27, 2016 12:59 PM
> > To: joonas.lahtinen at linux.intel.com; 'Chris Wilson' ; Vetter, Daniel
> <daniel.vetter at intel.com>; tvrtko.ursulin at linux.intel.com
> > Cc: Tian, Kevin <kevin.tian at intel.com>; Lv, Zhiyuan
> > Subject: Wrt golden MMIO/CFG snaphot in GVT-g
> >
> > Hi Guys:
> > I received some comments on from Kevin. Mostly his concern is the
> > burden of maintain/releasing the MMIO/CFG snapshot for customers. As
> > we might not have all the SKUs/platform which customers have, even we
> > release the snapshot file generator for customer, it would still
> > bring some extra effort when customer deploying the SW. And he
> > suggested i915 better i915 could keep the snapshot for GVT-g during
> > module loading.
> 
> It will be much harder to ask everyone else in addition to those with
> odd hardware revisions to provide the boot-captured register state for
> each bug they report. I do not feel adding some extra (one-time!)
> effort for customers deploying on weird SKUs overcomes that everyone
> would have to provide a register dump for each bug.
> 
> So I am still very much against making a register freeze at each boot.
> Even creating a one-shot golden state automatically when one is found
> missing the SKU from firmware package and then using that each time
> would make the system operation more stable. It should not be too hard
> to instruct customer to do that?
> 
> Regards, Joonas
> 

Sorry for late response.

I'm open about not making snapshot at each boot. It's convenient for
GVT-g usage, but I can understand its limitation - we need allocate
2MB buffer in kernel even when GVT-g is not enabled (if GVT-g will be
built as a separate module in the future). Using boot-captured state
through firmware interface is more flexible, but also adding more
dependency to our release cycle (but maybe we can tolerate it if
it's strongly preferred...)

However I'm against using one golden state on multiple SKUs. As I
replied in another mail, there is no architectural definition of such
golden state in Bspec. It means that we can only choose some
'pseudo' golden state based on experimental results on limited
skus, which cannot guarantee same golden state applicable to other
skus which just makes problem analysis more complex. 

Even we finally turn to using boot-captured state, there should
be an exact sku configuration match before customer can download
and use a firmware image, but then there is still a gray area which 
configuration info should be included in comparison...

If a public-distributed firmware model ends up to be inflexible, is it
easier we just ask customer to always make boot-captured state
themselves and then provision into GVT-g through i915 specific 
interface? To make the process easier (instead of manually disabling
i915, dump mmio, reboot, etc.), it might be also useful to bring back
making snapshot within i915 which is a module parameter, serving
two purposes:
	- if user doesn't care about 2MB memory consumption, he can
always enables this option so GVT-g can get initial state like today;
	- or user just enables the option once on a platform to get
snapshot into a file, and then later provision to GVT-g.

Thanks
Kevin