refactor the i915 GVT support

[Wang, Zhi A]

On 9/28/21 3:05 PM, Jason Gunthorpe wrote:
> On Tue, Sep 28, 2021 at 02:35:06PM +0000, Wang, Zhi A wrote:
>
>> Yes. I was thinking of the possibility of putting off some work later so
>> that we don't need to make a lot of changes. GVT-g needs to take a
>> snapshot of GPU registers as the initial virtual states for other vGPUs,
>> which requires the initialization happens at a certain early time of
>> initialization of i915. I was thinking maybe we can take other patches
>> from Christoph like "de-virtualize*" except this one because currently
>> we have to maintain a TEST-ONLY patch on our tree to prevent i915 built
>> as kernel module.
> How about just capture these registers in the main module/device and
> not try so hard to isolate it to the gvt stuff?

Hi Jason:

Thanks for the idea. I am not sure i915 guys would take this idea since 
that it's only for GVT-g, i915 doesn't use this at all. We need to take 
a snapshot of both PCI configuration space and MMIO registers before 
i915 driver starts to touch the HW.

One idea is we capture the registers in intel_gvt.c during the early 
initialization and do everything else when i915.ko is fully loaded. But 
how about dependence between i915.ko and kvmgt.ko? We cannot do 
request_module("kvmgt") in i915.ko.

Maybe Christoph can give more input on this and how we can deal with 
this? Before we figure out an solution, we have to pick that patch out 
since it blocks our pull request schedule.

Also I was thinking if moving gvt into kvmgt.ko is the right direction. 
It seems the module loading system in kernel is not designed for "module 
A loading module B, which needs symbols from module A, in the 
initialization path of module A".

Thanks,

Zhi.

> Jason