[Intel-gfx] Building GVT-g as a sub-module of i915

Daniel Vetter daniel at ffwll.ch
Mon May 23 14:18:04 UTC 2016


On Mon, May 23, 2016 at 4:16 PM, Joonas Lahtinen
<joonas.lahtinen at 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


More information about the Intel-gfx mailing list