Re: refactor the i915 GVT support

From: Wang, Zhi A
Date: Wed Sep 29 2021 - 14:27:29 EST

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".



> Jason