> From: Joonas Lahtinen [mailto:joonas.lahtinen@xxxxxxxxxxxxxxx] > 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@xxxxxxxxxxxxxxx] > > > 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@xxxxxxxxxxxxxxx; 'Chris Wilson' ; Vetter, Daniel > > > <daniel.vetter@xxxxxxxxx>; tvrtko.ursulin@xxxxxxxxxxxxxxx > > > > > > > > Cc: Tian, Kevin <kevin.tian@xxxxxxxxx>; 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
