Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 29 Sep 2021 15:55:41 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     "Wang, Zhi A" <zhi.a.wang@intel.com>
Cc:     Luis Chamberlain <mcgrof@kernel.org>, Jessica Yu <jeyu@kernel.org>,
        "De Marchi, Lucas" <lucas.demarchi@intel.com>,
        Zhenyu Wang <zhenyuw@linux.intel.com>,
        Christoph Hellwig <hch@lst.de>,
        "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
        Greg KH <gregkh@linuxfoundation.org>,
        "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>,
        Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Jani Nikula <jani.nikula@linux.intel.com>,
        Gerd Hoffmann <kraxel@redhat.com>,
        "Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
        "intel-gvt-dev@lists.freedesktop.org" 
        <intel-gvt-dev@lists.freedesktop.org>,
        "Nikula, Jani" <jani.nikula@intel.com>
Subject: Re: refactor the i915 GVT support
Message-ID: <20210929185541.GW964074@nvidia.com>
References: <20210817052203.GX13928@zhen-hp.sh.intel.com>
 <20210819082929.GB13928@zhen-hp.sh.intel.com>
 <20210820141724.GA29034@lst.de>
 <YSAI8pKAvvW/8S2O@bombadil.infradead.org>
 <20210826061219.GD9942@zhen-hp.sh.intel.com>
 <55c11f22-99e5-6109-3be3-a04b06b3336e@intel.com>
 <YVMgGKk1K4gO8ls6@bombadil.infradead.org>
 <af40291a-de36-b39f-9ded-aaf4ddba641f@intel.com>
 <20210928150507.GM964074@nvidia.com>
 <24c7bbec-b425-52fb-d3f9-539a0a391dfa@intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <24c7bbec-b425-52fb-d3f9-539a0a391dfa@intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?FPXaFNRgGk7n+jhy3PjT0+xLZr+gHD2teAQ1dTYJZk5zsrsb3yFm8Rao7Riw?=
 =?us-ascii?Q?2qDJ9nNTrR3x87cZsPYXaD/tcWY/En6b0SfTVWWQk4WSkkicy9NEJxPT0kfA?=
 =?us-ascii?Q?K4FNBI73iIYn5qBPLD+yGMQVcOtpdXXFhOy2W/Kphr9pedI34QOkSG9Hti27?=
 =?us-ascii?Q?OB41PhOMMxQXm64bXehLbY3LtIAv/kUr4OAvcR0+KCRKQjKb5mEoDRb/MZ03?=
 =?us-ascii?Q?A1r1jRgkDP6ULUdgKlpDObb8ZNTsTEcRbwRTHSF1kYm1Np8d+sRAdHm3R4uS?=
 =?us-ascii?Q?Rbvyu5yqmOBNVpOYqKO75aEH7XMncAe7fWyCF/Ey5g6/Dt/mppLChUrolICY?=
 =?us-ascii?Q?LKFJLinJngRezRn8gdyJBJtmHKXvFOJ26Nz2E7boFoAAFfLlXHXSIlcN0wqK?=
 =?us-ascii?Q?5eGG4tyb4Hlg4s54Owyqw/f2/VIC1i2tVU5b9KqQ2t9sGnMiPpFWpHRTo9dV?=
 =?us-ascii?Q?hzypliLrrfwyoy0rnos07dLlYVnUGqHqg0H51NB8rMVrY4iXlZGIxUdj52HO?=
 =?us-ascii?Q?tglCv+/8OlZxbHak3iIRYzQBvYcgr5HvLw5GzGLjJ1JcDsi1rlVaC/qgIJFC?=
 =?us-ascii?Q?7vOEas8oyfBUKXL9PC0FrgYiUzLuZqzcMziq+DY7Ab0b4ff1H4iGIPqVMCJW?=
 =?us-ascii?Q?YTEGQmqrQsvF/ytO8CQEZR7XpXit1VlJ9W9fwVwmNNe7lpawAHZrX/+vioA0?=
 =?us-ascii?Q?W2Wl5WhNJcS3FUu1F5iTkyaObK4m2McvCWqxf2VTovfYh6R5I1hgWmyW9e6M?=
 =?us-ascii?Q?SLPoHQS8QheOeoYzZQVs8/bEJxpvFZsrOZ5EpMdj10K6cu3LAsmXz7iNv7FZ?=
 =?us-ascii?Q?8dh8zq++faHmsTC5lWfinag4CD5YpYFYR/7/64xw1kld3YCFyRW2g8qk9ocB?=
 =?us-ascii?Q?wnTE8iRGzUoBK6ynGpXRkiReFJv53ldDd5nABhbZb+iG3azVzZ/prGR1sbYX?=
 =?us-ascii?Q?h18bypSZIA+klZNESoplMIN4YnOIC89/fNGTDdMK/3kFTsxa931fgsqU15uq?=
 =?us-ascii?Q?brZsX39Rh9kgEM9Vhb2w+8/JVju/wGr4L/zK7TzhfmWrPW3wMGzVMSQw7MkK?=
 =?us-ascii?Q?2QBPACTlZjDkoVNsWpDoFcFFuDETXKxbvL32PAY9PIiwq+BZcUoFjh+S+O+8?=
 =?us-ascii?Q?ZFgBC6riawGsNy0LSIQyHlAlfhD2jY6QVU6MbbzKABRTEzvPXE17cJUxXIX5?=
 =?us-ascii?Q?dz4TGCeq6c+/gyTe4hdRh3TCHdsTIck4uq9sspuykXjSowUST+Q81wvahkzY?=
 =?us-ascii?Q?VYQzwcMKpCbIiY1NadSnt7AZd8Xq+aS2R0gAGmEnBafULTA8eryQxUuEwAzS?=
 =?us-ascii?Q?BxQib5alCvo6sBc55DEI5SCY?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c6b1b814-fe1f-4f62-bfa7-08d9837abcdd
X-MS-Exchange-CrossTenant-AuthSource: BL0PR12MB5506.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Sep 2021 18:55:42.9007
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Q5r0wJpETa3q69/4wUDgC8u9zu7YK7n7yd0rP+MxR2TyXNIBiPUpjwri2Fahv6tK
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5158
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Sep 29, 2021 at 06:27:16PM +0000, Wang, Zhi A wrote:
> 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.

Given the code is already linked into i915 I don't see there is much
to object to here. It can remain conditional on the kernel parameter
as today.

As a general philosophy this would all be much less strange if the
mdev .ko is truely optional. It should be cleanly seperate from its
base device and never request_module'd..

In this case auxiliary device might be a good option, have i915 create
one and the mdev module be loaded against it.

In the mean time is there some shortcut to get this series to move
ahead? Is patch 4 essential to the rest of the series?

A really awful hack would be to push the pci_driver_register into a
WQ so that the request_module is guarenteed to not be part of the
module_init callchain.

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

Of course not, that is a circular module dependency, it should not be
that way. The SW layers need to be clean and orderly - meaning the
i915 module needs to have the minimal amount of code to support the
mdev module.

Jason