* Building GVT-g as a sub-module of i915 @ 2016-05-23 7:03 Wang, Zhi A 2016-05-23 14:16 ` Joonas Lahtinen 0 siblings, 1 reply; 4+ messages in thread From: Wang, Zhi A @ 2016-05-23 7:03 UTC (permalink / raw) To: joonas.lahtinen@linux.intel.com Cc: Vetter, Daniel, intel-gfx@lists.freedesktop.org Hi Guys: I'm trying to make GVT-g as a sub-module of i915 in the next version patchset. The basic idea is to introduce a "gvt-g pre-enabled state" in i915. I think it should be a kernel option. When this kernel option is enabled by user, i915 will do GGTT partition and save HW initial MMIO snapshot for gvt-g module during loading. When GVT-g modules is loaded, first it should check if the "gvt-g pre-eanbled state" is enabled in i915. If yes, then it will use the snapshot in i915 and continue to load. If no, then bail out. Thanks, Zhi. _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Building GVT-g as a sub-module of i915 2016-05-23 7:03 Building GVT-g as a sub-module of i915 Wang, Zhi A @ 2016-05-23 14:16 ` Joonas Lahtinen 2016-05-23 14:18 ` Daniel Vetter 0 siblings, 1 reply; 4+ messages in thread From: Joonas Lahtinen @ 2016-05-23 14:16 UTC (permalink / raw) To: Wang, Zhi A; +Cc: Vetter, Daniel, intel-gfx@lists.freedesktop.org On ma, 2016-05-23 at 07:03 +0000, Wang, Zhi A wrote: > Hi Guys: > I'm trying to make GVT-g as a sub-module of i915 in the next > version patchset. The basic idea is to introduce a "gvt-g pre-enabled > state" in i915. I think it should be a kernel option. > Could not the GGTT partitioning be done ad hoc by moving objects out of the memory areas to be ballooned? This way gvt module could just be loaded and it would work, instead of having to reboot and change kernel parameters. > When this kernel option is enabled by user, i915 will do GGTT > partition and save HW initial MMIO snapshot for gvt-g module during > loading. Like discussed in the F2F, I really think taking a MMIO snapshot in Dom0 at boot sounds a little suspicious to me as changing Dom0 BIOS settings could very obscurely break VM booting, especially if migration is at some point wanted. It will also leak the Dom0 boot state to a VM, which I do not like either. I would be more comfortable if the VMs are booting to a driver-fixed MMIO state. Any thoughts by others on these? Regards, Joonas > When GVT-g modules is loaded, first it should check if the "gvt-g > pre-eanbled state" is enabled in i915. If yes, then it will use the > snapshot in i915 and continue to load. If no, then bail out. > > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Building GVT-g as a sub-module of i915 2016-05-23 14:16 ` Joonas Lahtinen @ 2016-05-23 14:18 ` Daniel Vetter 2016-05-23 14:48 ` Wang, Zhi A 0 siblings, 1 reply; 4+ messages in thread From: Daniel Vetter @ 2016-05-23 14:18 UTC (permalink / raw) To: Joonas Lahtinen; +Cc: Vetter, Daniel, intel-gfx@lists.freedesktop.org On Mon, May 23, 2016 at 4:16 PM, Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote: > On ma, 2016-05-23 at 07:03 +0000, Wang, Zhi A wrote: >> Hi Guys: >> I'm trying to make GVT-g as a sub-module of i915 in the next >> version patchset. The basic idea is to introduce a "gvt-g pre-enabled >> state" in i915. I think it should be a kernel option. >> > > Could not the GGTT partitioning be done ad hoc by moving objects out of > the memory areas to be ballooned? This way gvt module could just be > loaded and it would work, instead of having to reboot and change kernel > parameters. Yeah, if we want to make gvt loadable, then it should indeed not reserve anything if it's not loaded. Otherwise there's no point in that option, and it's no better than just a static Kconfig+ maybe i915 module option. If dynamic loading is too hard for v1, then I'd say we should postpone it to post-merging. GVT-g is already tricky to integrate as-is. >> When this kernel option is enabled by user, i915 will do GGTT >> partition and save HW initial MMIO snapshot for gvt-g module during >> loading. > > Like discussed in the F2F, I really think taking a MMIO snapshot in > Dom0 at boot sounds a little suspicious to me as changing Dom0 BIOS > settings could very obscurely break VM booting, especially if migration > is at some point wanted. It will also leak the Dom0 boot state to a VM, > which I do not like either. > > I would be more comfortable if the VMs are booting to a driver-fixed > MMIO state. > > Any thoughts by others on these? Golden MMIO state sounds like a good idea. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Building GVT-g as a sub-module of i915 2016-05-23 14:18 ` Daniel Vetter @ 2016-05-23 14:48 ` Wang, Zhi A 0 siblings, 0 replies; 4+ messages in thread From: Wang, Zhi A @ 2016-05-23 14:48 UTC (permalink / raw) To: Daniel Vetter, Joonas Lahtinen Cc: Vetter, Daniel, intel-gfx@lists.freedesktop.org Thanks Daniel and Joonas. : p See my replies below. > -----Original Message----- > From: daniel.vetter@ffwll.ch [mailto:daniel.vetter@ffwll.ch] On Behalf Of > Daniel Vetter > Sent: Monday, May 23, 2016 5:18 PM > To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > Cc: Wang, Zhi A <zhi.a.wang@intel.com>; Vetter, Daniel > <daniel.vetter@intel.com>; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] Building GVT-g as a sub-module of i915 > > On Mon, May 23, 2016 at 4:16 PM, Joonas Lahtinen > <joonas.lahtinen@linux.intel.com> wrote: > > On ma, 2016-05-23 at 07:03 +0000, Wang, Zhi A wrote: > >> Hi Guys: > >> I'm trying to make GVT-g as a sub-module of i915 in the next > >> version patchset. The basic idea is to introduce a "gvt-g pre-enabled > >> state" in i915. I think it should be a kernel option. > >> > > > > Could not the GGTT partitioning be done ad hoc by moving objects out > > of the memory areas to be ballooned? This way gvt module could just be > > loaded and it would work, instead of having to reboot and change > > kernel parameters. > > Yeah, if we want to make gvt loadable, then it should indeed not reserve > anything if it's not loaded. Otherwise there's no point in that option, and it's no > better than just a static Kconfig+ maybe i915 module option. > > If dynamic loading is too hard for v1, then I'd say we should postpone it to > post-merging. GVT-g is already tricky to integrate as-is. > Yes. We can try to reserve some portion of GGTT by allocating 2 gem object and pin them into mappable / high GGTT memory. I think better we can postpone it to post-merging. For now statically partition only requires little changes. :) > >> When this kernel option is enabled by user, i915 will do GGTT > >> partition and save HW initial MMIO snapshot for gvt-g module during > >> loading. > > > > Like discussed in the F2F, I really think taking a MMIO snapshot in > > Dom0 at boot sounds a little suspicious to me as changing Dom0 BIOS > > settings could very obscurely break VM booting, especially if > > migration is at some point wanted. It will also leak the Dom0 boot > > state to a VM, which I do not like either. > > > > I would be more comfortable if the VMs are booting to a driver-fixed > > MMIO state. > > > > Any thoughts by others on these? > > Golden MMIO state sounds like a good idea. Yes. It's a good idea. I agree with that. But consider that each GT stepping/generation might need a dedicated MMIO snapshot. They could become huge, probably at the very beginning 2MB is OK, in future we should get them out of kernel. BTW: It's not only MMIO bar needs a snapshot, PCI configuration space also needs a golden snapshot. :) So consider the GT/SKUs we have, maybe we should figure out a way to store them at first. :) > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-05-23 14:48 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-05-23 7:03 Building GVT-g as a sub-module of i915 Wang, Zhi A 2016-05-23 14:16 ` Joonas Lahtinen 2016-05-23 14:18 ` Daniel Vetter 2016-05-23 14:48 ` Wang, Zhi A
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.