On Fri, 23 Apr 2021 09:07:09 -0300
Jason Gunthorpe <jgg@xxxxxxxx> wrote:
> On Fri, Apr 23, 2021 at 11:54:26AM +0800, Zhenyu Wang wrote:
> > On 2021.04.22 10:58:10 -0300, Jason Gunthorpe wrote:
> > > On Thu, Apr 22, 2021 at 03:35:33PM +0200, Arnd Bergmann wrote:
> > > > From: Arnd Bergmann <arnd@xxxxxxxx>
> > > >
> > > > The Kconfig dependency is incomplete since DRM_I915_GVT is a 'bool'
> > > > symbol that depends on the 'tristate' VFIO_MDEV. This allows a
> > > > configuration with VFIO_MDEV=m, DRM_I915_GVT=y and DRM_I915=y that
> > > > causes a link failure:
> > > >
> > > > x86_64-linux-ld: drivers/gpu/drm/i915/gvt/gvt.o: in function `available_instances_show':
> > > > gvt.c:(.text+0x67a): undefined reference to `mtype_get_parent_dev'
> > > > x86_64-linux-ld: gvt.c:(.text+0x6a5): undefined reference to `mtype_get_type_group_id'
> > > > x86_64-linux-ld: drivers/gpu/drm/i915/gvt/gvt.o: in function `description_show':
> > > > gvt.c:(.text+0x76e): undefined reference to `mtype_get_parent_dev'
> > > > x86_64-linux-ld: gvt.c:(.text+0x799): undefined reference to `mtype_get_type_group_id'
> > > >
> > > > Clarify the dependency by specifically disallowing the broken
> > > > configuration. If VFIO_MDEV is built-in, it will work, but if
> > > > VFIO_MDEV=m, the i915 driver cannot be built-in here.
> > > >
> > > > Fixes: 07e543f4f9d1 ("vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV")
> > > > Fixes: 9169cff168ff ("vfio/mdev: Correct the function signatures for the mdev_type_attributes")
> > > > Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
> > > > drivers/gpu/drm/i915/Kconfig | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > Oh kconfig stuff like this makes my head hurt, thanks for finding it
> > >
> > > I also can't see an alternative to this ugly thing, besides having the
> > > i915 guys properly modularize this code someday
> > >
> > > Reviewed-by: Jason Gunthorpe <jgg@xxxxxxxxxx>
> > >
> >
> > I don't really want this mess to propagate further. We should move
> > mdev related stuff to kvmgt module instead, so not pretend any more to
> > possibly use that for other hypervisor..
> >
> > Sorry that I didn't realize this issue when Jason proposed this. Let
> > me do the left cleanup.
>
> It would be good, but Alex should still take this patch for the
> upcoming merge window, you can revert it when you do all the cleanups
I can include it, but I'll wait for confirmation from Zhenyu. Thanks,
Alex
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
