Building GVT-g as a sub-module of i915

Building GVT-g as a sub-module of i915

[Wang, Zhi A]

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

Re: Building GVT-g as a sub-module of i915

[Joonas Lahtinen]

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

Re: Building GVT-g as a sub-module of i915

[Daniel Vetter]

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

Re: Building GVT-g as a sub-module of i915

[Wang, Zhi A]

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