From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 237C8C4167B for ; Wed, 29 Nov 2023 02:22:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=m4etJprgXTwd510K+EhS2avFzYNER3N9Fvwxx8Y+7qs=; b=RhBVcvMRXHimGQBG/gQQUS7DyE UHwfy+pdMLrURdSIytK+ef6daFU80x2WYKYDuuyWRzYqo1imFwSEiWPVlGVXeM/KpkCfc+pAMjxKQ no7GuogXUEFd1VcpDVNjyD1E5HJiRWabz02Usr/8mj+ZYsgKgUvnYdUQyTPntHic5NMu23LsvNoDP y5gn0uafiukfK9Wppsv15uU4tWeCb2WU53mOq9E9E4LZZM/0DbsedzAoUCG0cBJs6ZCxntdFhWycB EKKoZmHAVZPdLuW0nY2zxTOzY4W44+ZgoE3VLz5M/e5QSYbc+QFBTbVhueXeEWdiS1EP+L68JJvYc ucOnK3JA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r8AD2-006psP-15; Wed, 29 Nov 2023 02:21:52 +0000 Received: from mail-yw1-x114a.google.com ([2607:f8b0:4864:20::114a]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r8ACy-006pqK-2Y for linux-arm-kernel@lists.infradead.org; Wed, 29 Nov 2023 02:21:50 +0000 Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5cb92becbf6so92867967b3.2 for ; Tue, 28 Nov 2023 18:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701224505; x=1701829305; darn=lists.infradead.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=mJUgPg47d4/pgx8Qlc5dU8QTKw0KSk/PtK3yQegaG7g=; b=OSHTpLjQ4X0Gcd9s9RVJJuZi9SFEeCgR97hgI6quveUXpBisXWaNSd0FvvCx8MhmN8 yBo4cv3ESjlr3qZckrx7b7rYtT7jVIh+Rx3KaNre0aRBsLA7pnetjKEAuTJ7V5i1c4HZ jF6VaZPP0seVp8RmrQgSXTXtsgHnVJB7GeCfPB8aS5JINyqrKY6gbezfKJ2f/V5EQjme tA8mg8/BBKsWqHuFkVnAxY7YW5bqWuvjDNkw7Owg4d6Wb1h5HpCzJ83yn1pyNxckEe1j qvTmSc/ZSrLhj73T74eQDCu2cPL+ilUd4eorylaKeC35v5LHulT7MsOGpzKMG2VKOVCh eizQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701224505; x=1701829305; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mJUgPg47d4/pgx8Qlc5dU8QTKw0KSk/PtK3yQegaG7g=; b=A3/Uqg9WdEsyPtKMu0BhAFzuvewpG/HufCs8OtBy58mMQIIf5rY1/roD22rs4BChSQ TczxR2O4mpdi8gTUe1gu5ryQe99DV7aMy2XNxM7M+I4F5WvROiveyTro332+DiszvlwR rSP8DX9LqfF579dFZUAkcpY1AUIIWWqo+glbTVclsgNt7lVEv+F1VlLjldAJs85Pgisi onRNZcgGU3tIOi0J/MUYLspSI4t8IBoNbuzMNY+7XQfvOuz98zr5YWo9DBJJc89tDgze /deN9CU42t+/dLhw+I7+nWO4hybugSkyx6BwZDx0VotOKc5QzZ65cqSaw0RsKlX8ELGk 7YOQ== X-Gm-Message-State: AOJu0YwepuvI0LRWvnHXIxivRf6Dc+8KKZvGNho9b+OWlUG38Vm0g09r 9nvi9S5uKocbkO2t3GdgpsSYbPI/E0Q= X-Google-Smtp-Source: AGHT+IEzvdnB4YF3ag5ypaUivwQ+a/1gSiOiue26Vf+Kzl2dkVc1+0BYVi7jXds4GjyyxEfKmNI6Cd+a9DA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a81:ff05:0:b0:5cd:c47d:d89a with SMTP id k5-20020a81ff05000000b005cdc47dd89amr593254ywn.2.1701224504362; Tue, 28 Nov 2023 18:21:44 -0800 (PST) Date: Tue, 28 Nov 2023 18:21:42 -0800 In-Reply-To: <87edgy87ig.fsf@mail.lhotse> Mime-Version: 1.0 References: <0-v1-08396538817d+13c5-vfio_kvm_kconfig_jgg@nvidia.com> <87edgy87ig.fsf@mail.lhotse> Message-ID: Subject: Re: Ping? Re: [PATCH rc] kvm: Prevent compiling virt/kvm/vfio.c unless VFIO is selected From: Sean Christopherson To: Michael Ellerman Cc: Paolo Bonzini , Jason Gunthorpe , Alexander Gordeev , Christian Borntraeger , Borislav Petkov , Catalin Marinas , Christophe Leroy , Dave Hansen , David Hildenbrand , Janosch Frank , Vasily Gorbik , Heiko Carstens , "H. Peter Anvin" , Claudio Imbrenda , James Morse , kvm@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Marc Zyngier , Ingo Molnar , Nicholas Piggin , Oliver Upton , Suzuki K Poulose , Sven Schnelle , Thomas Gleixner , Will Deacon , x86@kernel.org, Zenghui Yu X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231128_182148_849241_E48AC7A2 X-CRM114-Status: GOOD ( 19.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Nov 10, 2023, Michael Ellerman wrote: > Jason Gunthorpe writes: > > There are a bunch of reported randconfig failures now because of this, > > something like: > > > >>> arch/powerpc/kvm/../../../virt/kvm/vfio.c:89:7: warning: attribute declaration must precede definition [-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); }) > > > > It happens because the arch forces KVM_VFIO without knowing if VFIO is > > even enabled. > > This is still breaking some builds. Can we get this fix in please? > > cheers > > > Split the kconfig so the arch selects the usual HAVE_KVM_ARCH_VFIO and > > then KVM_VFIO is only enabled if the arch wants it and VFIO is turned on. Heh, so I was trying to figure out why things like vfio_file_set_kvm() aren't problematic, i.e. why the existing mess didn't cause failures. I can't repro the warning (requires clang-16?), but IIUC the reason only the group code is problematic is that vfio.h creates a stub for vfio_file_iommu_group() and thus there's no symbol, whereas vfio.h declares vfio_file_set_kvm() unconditionally. Because KVM is doing symbol_get() and not taking a direct dependency, the lack of an exported symbol doesn't cause problems, i.e. simply declaring the symbol makes the compiler happy. Given that the vfio_file_iommu_group() stub shouldn't exist (KVM is the only user, and so if I'm correct the stub is worthless), what about this as a temporary "fix"? I'm 100% on-board with fixing KVM properly, my motivation is purely to minimize the total amount of churn. E.g. if this works, then the only extra churn is to move the declaration of vfio_file_iommu_group() back under the #if, versus having to churn all of the KVM Kconfigs twice (once now, and again for the full cleanup). diff --git a/include/linux/vfio.h b/include/linux/vfio.h index 454e9295970c..a65b2513f8cd 100644 --- a/include/linux/vfio.h +++ b/include/linux/vfio.h @@ -289,16 +289,12 @@ void vfio_combine_iova_ranges(struct rb_root_cached *root, u32 cur_nodes, /* * External user API */ -#if IS_ENABLED(CONFIG_VFIO_GROUP) struct iommu_group *vfio_file_iommu_group(struct file *file); + +#if IS_ENABLED(CONFIG_VFIO_GROUP) bool vfio_file_is_group(struct file *file); bool vfio_file_has_dev(struct file *file, struct vfio_device *device); #else -static inline struct iommu_group *vfio_file_iommu_group(struct file *file) -{ - return NULL; -} - static inline bool vfio_file_is_group(struct file *file) { return false; _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel