All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Zhiyuan Lv <zhiyuan.lv@intel.com>
Cc: "Vetter, Daniel" <daniel.vetter@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Subject: Re: FW: Wrt golden MMIO/CFG snaphot in GVT-g
Date: Wed, 01 Jun 2016 15:49:59 +0300	[thread overview]
Message-ID: <1464785399.6283.9.camel@linux.intel.com> (raw)
In-Reply-To: <20160531140152.GA18021@zlv-hp-dev>

On ti, 2016-05-31 at 22:01 +0800, Zhiyuan Lv wrote:
> Hi Joonas,
> 
> On Fri, May 27, 2016 at 02:32:25PM +0300, Joonas Lahtinen wrote:
> > 
> > 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@linux.intel.com; 'Chris Wilson' ; Vetter, Daniel <daniel.vetter@intel.com>; tvrtko.ursulin@linux.intel.com
> > > Cc: Tian, Kevin <kevin.tian@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.
> The bug reporting/reproducing is a good point. We assume that in each
> driver load, the captured register state would be almost the same, and
> the difference won't bring difficulty for reproducing bugs.
> 
> Then we may not need register dump for each bug submission. Consider
> the case of an odd hardware, if we can find the same in hand, we could
> get the dump automatically. If we cannot find the same, even with the
> dump state from reporter, it still cannot guarantee the bug
> reproducing. We make VM to see identical MMIO state, but the real
> hardware state is different. Thanks!
> 

What benefits do we get from using the boot-up state?

I do not see any technical benefits, just avoiding one step for
customers with odd SKUs vs. all the benefits we would get from golden
state.

Regards, Joonas

> Regards,
> -Zhiyuan
> 
> > 
> > 
> > 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
> > 
> > > 
> > > As we have shared some ideas about the security problem like leaking
> > > BIOS configuration to VM, better we could elaborate more ideas and
> > > figure out a better approach. Let’s discuss. J
> > >  
> > > Thanks,
> > > Zhi.
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-06-01 12:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-27 10:05 FW: Wrt golden MMIO/CFG snaphot in GVT-g Wang, Zhi A
2016-05-27 10:09 ` Tian, Kevin
2016-05-27 11:38   ` Joonas Lahtinen
2016-06-03 12:19     ` Tian, Kevin
2016-05-27 11:32 ` FW: " Joonas Lahtinen
2016-05-31 14:01   ` Zhiyuan Lv
2016-06-01 12:49     ` Joonas Lahtinen [this message]
2016-06-01 14:40       ` Zhiyuan Lv
2016-06-03 12:36   ` Tian, Kevin
2016-06-08  9:23     ` Joonas Lahtinen
2016-06-15  8:05       ` Tian, Kevin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1464785399.6283.9.camel@linux.intel.com \
    --to=joonas.lahtinen@linux.intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=zhiyuan.lv@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.