linux-kernel - Re: refactor the i915 GVT support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210930052402.GA21841@lst.de>
Date:   Thu, 30 Sep 2021 07:24:02 +0200
From:   Christoph Hellwig <hch@....de>
To:     "Wang, Zhi A" <zhi.a.wang@...el.com>
Cc:     Jason Gunthorpe <jgg@...dia.com>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Jessica Yu <jeyu@...nel.org>,
        "De Marchi, Lucas" <lucas.demarchi@...el.com>,
        Zhenyu Wang <zhenyuw@...ux.intel.com>,
        Christoph Hellwig <hch@....de>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Gerd Hoffmann <kraxel@...hat.com>,
        "Vivi, Rodrigo" <rodrigo.vivi@...el.com>,
        "intel-gvt-dev@...ts.freedesktop.org" 
        <intel-gvt-dev@...ts.freedesktop.org>,
        "Nikula, Jani" <jani.nikula@...el.com>
Subject: Re: refactor the i915 GVT support

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

I have a few idea on how to sort this "deadlock" out.  But I'm completely
swamped until the end of next week, so I won't get to anything before
that.