FW: Wrt golden MMIO/CFG snaphot in GVT-g

FW: Wrt golden MMIO/CFG snaphot in GVT-g

[Wang, Zhi A]

[-- Attachment #1.1: Type: text/plain, Size: 1180 bytes --]

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' <chris@chris-wilson.co.uk>; Vetter, Daniel <daniel.vetter@intel.com>; tvrtko.ursulin@linux.intel.com
Cc: Tian, Kevin <kevin.tian@intel.com>; Lv, Zhiyuan <zhiyuan.lv@intel.com>
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. 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. :)

Thanks,
Zhi.

[-- Attachment #1.2: Type: text/html, Size: 4379 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Wrt golden MMIO/CFG snaphot in GVT-g

[Tian, Kevin]

[-- Attachment #1.1: Type: text/plain, Size: 1758 bytes --]

Curious why leaking BIOS configuration to VM is a security problem... Can someone elaborate this view?

From: Wang, Zhi A
Sent: Friday, May 27, 2016 6:05 PM
To: intel-gfx@lists.freedesktop.org
Cc: joonas.lahtinen@linux.intel.com; Chris Wilson; Vetter, Daniel; tvrtko.ursulin@linux.intel.com; Tian, Kevin; Lv, Zhiyuan
Subject: FW: Wrt golden MMIO/CFG snaphot in GVT-g

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<mailto:joonas.lahtinen@linux.intel.com>; 'Chris Wilson' <chris@chris-wilson.co.uk<mailto:chris@chris-wilson.co.uk>>; Vetter, Daniel <daniel.vetter@intel.com<mailto:daniel.vetter@intel.com>>; tvrtko.ursulin@linux.intel.com<mailto:tvrtko.ursulin@linux.intel.com>
Cc: Tian, Kevin <kevin.tian@intel.com<mailto:kevin.tian@intel.com>>; Lv, Zhiyuan <zhiyuan.lv@intel.com<mailto:zhiyuan.lv@intel.com>>
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. 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. :)

Thanks,
Zhi.

[-- Attachment #1.2: Type: text/html, Size: 6685 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Wrt golden MMIO/CFG snaphot in GVT-g

[Joonas Lahtinen]

On pe, 2016-05-27 at 10:09 +0000, Tian, Kevin wrote:
> Curious why leaking BIOS configuration to VM is a security problem…
> Can someone elaborate this view?
>  

Hi,

It is a potential vector in case we are blindly reading everything but
blacklisted registers. Whitelisting would make it less so.

But bigger problem is that it is a one more variable to the VM
boot/operation; one could make a server farm non-operational by
changing BIOS settings from one machine whose tasks are migrated to
other servers.

I think both are rather big inconvenience compared to making one-time
golden MMIO snapshot for strange SKUs.

Regards, Joonas
-- 
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

Re: Wrt golden MMIO/CFG snaphot in GVT-g

[Tian, Kevin]

> From: Joonas Lahtinen [mailto:joonas.lahtinen@linux.intel.com]
> Sent: Friday, May 27, 2016 7:39 PM
> 
> On pe, 2016-05-27 at 10:09 +0000, Tian, Kevin wrote:
> > Curious why leaking BIOS configuration to VM is a security problem…
> > Can someone elaborate this view?
> >
> 
> Hi,
> 
> It is a potential vector in case we are blindly reading everything but
> blacklisted registers. Whitelisting would make it less so.
> 
> But bigger problem is that it is a one more variable to the VM
> boot/operation; one could make a server farm non-operational by
> changing BIOS settings from one machine whose tasks are migrated to
> other servers.

I don't think it's a real problem. In reality we'll allow migration between
machines with same generation/configuration, which is also the typical
case in data center/cloud vendors who usually provide one service with
a pool of same models.

> 
> I think both are rather big inconvenience compared to making one-time
> golden MMIO snapshot for strange SKUs.
> 

However there is no such golden MMIO definition in spec which works on all
SKUs. There are many states which might be sku specific. Using a golden
state different from underlying hardware would lead to unexpected issues
and difficult to debug.

Thanks
Kevin
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FW: Wrt golden MMIO/CFG snaphot in GVT-g

[Joonas Lahtinen]

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.

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

Re: FW: Wrt golden MMIO/CFG snaphot in GVT-g

[Zhiyuan Lv]

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!

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

Re: FW: Wrt golden MMIO/CFG snaphot in GVT-g

[Joonas Lahtinen]

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

Re: FW: Wrt golden MMIO/CFG snaphot in GVT-g

[Zhiyuan Lv]

Hi Joonas,

On Wed, Jun 01, 2016 at 03:49:59PM +0300, Joonas Lahtinen wrote:
> 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.

The only concern is the maintenance of the golden states. We may have to
statically generate the state for each device id, which could be many, still
not yet be able to cover customers odd cases. If maintaining those states is
not an issue, that should be all fine.

BTW, I am also wondering how the gfx driver's behavior relies on the system
initial MMIO value, and whether it is possible to get the golden MMIO initial
state from PRM, for instance, use default value of MMIO if defined in PRM,
otherwise 0. Thanks!

Regards,
-Zhiyuan

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

Re: FW: Wrt golden MMIO/CFG snaphot in GVT-g

[Tian, Kevin]

> From: Joonas Lahtinen [mailto:joonas.lahtinen@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@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.
> 
> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: FW: Wrt golden MMIO/CFG snaphot in GVT-g

[Joonas Lahtinen]

On pe, 2016-06-03 at 12:36 +0000, Tian, Kevin wrote:
> > 
> > From: Joonas Lahtinen [mailto:joonas.lahtinen@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@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.
> > 
> > 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...)
> 

My specific rejection is on making the snapsot each and every boot. 

> 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. 
> 

I do not think golden state is required per se, it just sounded it
would resolve the problems rather easily.

Would it be possible to do register whitelisted dump, that way we would
not have to worry about leaking information we do not know of.

So my major concerns are 1. The MMIO state keeps changing once the VM's
have been installed, will lead to problems at some point once migration
support comes to play. 2. If we grab everything but blacklisted
registers, we do not know what information we expose to VM's (could be
encryption keys and what not). So whitelisting registers we need to
move to VMs to make them detect W/A's and everything would sound more
calming to me.

Regards, Joonas

> 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
-- 
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

Re: FW: Wrt golden MMIO/CFG snaphot in GVT-g

[Tian, Kevin]

> From: Joonas Lahtinen [mailto:joonas.lahtinen@linux.intel.com]
> Sent: Wednesday, June 08, 2016 5:23 PM
> 
> On pe, 2016-06-03 at 12:36 +0000, Tian, Kevin wrote:
> > >
> > > From: Joonas Lahtinen [mailto:joonas.lahtinen@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@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.
> > >
> > > 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...)
> >
> 
> My specific rejection is on making the snapsot each and every boot.
> 
> > 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.
> >
> 
> I do not think golden state is required per se, it just sounded it
> would resolve the problems rather easily.
> 
> Would it be possible to do register whitelisted dump, that way we would
> not have to worry about leaking information we do not know of.
> 
> So my major concerns are 1. The MMIO state keeps changing once the VM's
> have been installed, will lead to problems at some point once migration
> support comes to play. 2. If we grab everything but blacklisted
> registers, we do not know what information we expose to VM's (could be
> encryption keys and what not). So whitelisting registers we need to
> move to VMs to make them detect W/A's and everything would sound more
> calming to me.
> 

We can investigate the feasibility of the whitelist way, but please understand
this approach though cleaner requires quite some time to investigate and 
stabilize (no such definition in bspec for a minimal list of registers necessary
to make driver happy. If you have any recommendation it would be highly
appreciated). 

Then wonder whether still possible to have the boot option available as alternative
so our customer can benefit from GVT-g technology earlier. Intel provides graphics
virtualization features through multiple technologies, e.g. GVT-d which dedicates
the whole device to a single VM, and GVT-g which shares the device among
multiple VMs through mediated pass-through. In GVT-d case, all the registers
are accessible to the very VM (directly passed through w/o hypervisor intervention), 
which is essentially a blacklist style. That is also the initial reason why we use this 
style for GVT-g. Definitely with whitelist it's possible for GVT-g to behave even 
better than GVT-d, but if possible to set it as a future goal it could accelerate GVT-g 
TTM quicker (with baseline on par with GVT-d). :-)

Thanks
Kevin
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx