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]

Date:   Fri, 20 Aug 2021 16:17:24 +0200
From:   Christoph Hellwig <hch@....de>
To:     Zhenyu Wang <zhenyuw@...ux.intel.com>
Cc:     Christoph Hellwig <hch@....de>, Jason Gunthorpe <jgg@...dia.com>,
        "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>,
        "Wang, Zhi A" <zhi.a.wang@...el.com>,
        Jani Nikula <jani.nikula@...el.com>,
        Luis Chamberlain <mcgrof@...nel.org>
Subject: Re: refactor the i915 GVT support

On Thu, Aug 19, 2021 at 04:29:29PM +0800, Zhenyu Wang wrote:
> I'm working on below patch to resolve this. But I met a weird issue in
> case when building i915 as module and also kvmgt module, it caused
> busy wait on request_module("kvmgt") when boot, it doesn't happen if
> building i915 into kernel. I'm not sure what could be the reason?

Luis, do you know if there is a problem with a request_module from
a driver ->probe routine that is probably called by a module_init
function itself?

In the meantime I'll try to reproduce it locally, but I always had a
hard time getting useful results out of a modular i915, especially
when combined with module paramters. (no blame on i915, just the problem
with modules needed early on).

> 
> > But the problem I see is that after moving gvt device model (gvt/*.c
> > except kvmgt.c) into kvmgt module, we'll have issue with initial mmio
> > state which current gvt relies on, that is in design supposed to get
> > initial HW state before i915 driver has taken any operation.  Before
> > we can ensure that, I think we may only remove MPT part first but
> > still keep gvt device model as part of i915 with config. I'll try to
> > split that out.
> 
> Sorry I misread the code that as we always request kvmgt module when
> gvt init, so it should still apply original method that this isn't a
> problem. Our current validation result has shown no regression as well.

What does initial mmio state mean?  This is something new to me.  But
as you said in this mail unless I missed something very big it should
work the same as before.

> -static inline void intel_context_unpin(struct intel_context *ce)
> +static inline void _intel_context_unpin(struct intel_context *ce)
>  {
>  	if (!ce->ops->sched_disable) {
>  		__intel_context_do_unpin(ce, 1);
> @@ -150,6 +150,7 @@ static inline void intel_context_unpin(struct intel_context *ce)
>  		}
>  	}
>  }
> +void intel_context_unpin(struct intel_context *ce);

Looking at intel_context_unpin/_intel_context_unpin is there really
a need to have this inline to start with?  It don't see much the compiler
could optimize by inlining it.