From: Jason Gunthorpe <jgg@nvidia.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Nick Desaulniers <ndesaulniers@google.com>,
Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH] vfio: Drop vfio_file_iommu_group() stub to fudge around a KVM wart
Date: Wed, 29 Nov 2023 20:12:16 -0400 [thread overview]
Message-ID: <20231130001216.GC1389974@nvidia.com> (raw)
In-Reply-To: <20231130001000.543240-1-seanjc@google.com>
On Wed, Nov 29, 2023 at 04:10:00PM -0800, Sean Christopherson wrote:
> Drop the vfio_file_iommu_group() stub and instead unconditionally declare
> the function to fudge around a KVM wart where KVM tries to do symbol_get()
> on vfio_file_iommu_group() (and other VFIO symbols) even if CONFIG_VFIO=n.
>
> Ensuring the symbol is always declared fixes a PPC build error when
> modules are also disabled, in which case symbol_get() simply points at the
> address of the symbol (with some attributes shenanigans). Because KVM
> does symbol_get() instead of directly depending on VFIO, the lack of a
> fully defined symbol is not problematic (ugly, but "fine").
>
> arch/powerpc/kvm/../../../virt/kvm/vfio.c:89:7:
> error: attribute declaration must precede definition [-Werror,-Wignored-attributes]
> fn = symbol_get(vfio_file_iommu_group);
> ^
> include/linux/module.h:805:60: note: expanded from macro 'symbol_get'
> #define symbol_get(x) ({ extern typeof(x) x __attribute__((weak,visibility("hidden"))); &(x); })
> ^
> include/linux/vfio.h:294:35: note: previous definition is here
> static inline struct iommu_group *vfio_file_iommu_group(struct file *file)
> ^
> arch/powerpc/kvm/../../../virt/kvm/vfio.c:89:7:
> error: attribute declaration must precede definition [-Werror,-Wignored-attributes]
> fn = symbol_get(vfio_file_iommu_group);
> ^
> include/linux/module.h:805:65: note: expanded from macro 'symbol_get'
> #define symbol_get(x) ({ extern typeof(x) x __attribute__((weak,visibility("hidden"))); &(x); })
> ^
> include/linux/vfio.h:294:35: note: previous definition is here
> static inline struct iommu_group *vfio_file_iommu_group(struct file *file)
> ^
> 2 errors generated.
>
> Although KVM is firmly in the wrong (there is zero reason for KVM to build
> virt/kvm/vfio.c when VFIO is disabled), fudge around the error in VFIO as
> the stub is unnecessary and doesn't serve its intended purpose (KVM is the
> only external user of vfio_file_iommu_group()), and there is an in-flight
> series to clean up the entire KVM<->VFIO interaction, i.e. fixing this in
> KVM would result in more churn in the long run, and the stub needs to go
> away regardless.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202308251949.5IiaV0sz-lkp@intel.com
> Closes: https://lore.kernel.org/oe-kbuild-all/202309030741.82aLACDG-lkp@intel.com
> Closes: https://lore.kernel.org/oe-kbuild-all/202309110914.QLH0LU6L-lkp@intel.com
> Link: https://lore.kernel.org/all/0-v1-08396538817d+13c5-vfio_kvm_kconfig_jgg@nvidia.com
> Link: https://lore.kernel.org/all/20230916003118.2540661-1-seanjc@google.com
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Cc: Jason Gunthorpe <jgg@nvidia.com>
> Tested-by: Michael Ellerman <mpe@ellerman.id.au>
> Fixes: c1cce6d079b8 ("vfio: Compile vfio_group infrastructure optionally")
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
> include/linux/vfio.h | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
next prev parent reply other threads:[~2023-11-30 0:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-30 0:10 [PATCH] vfio: Drop vfio_file_iommu_group() stub to fudge around a KVM wart Sean Christopherson
2023-11-30 0:12 ` Jason Gunthorpe [this message]
2023-11-30 18:50 ` Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231130001216.GC1389974@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpe@ellerman.id.au \
--cc=ndesaulniers@google.com \
--cc=seanjc@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.