From patchwork Thu May 8 08:57:51 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ingo Molnar X-Patchwork-Id: 2082760 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=mywjTpx+; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=m+bi/J7r; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.infradead.org (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org; envelope-from=linux-um-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=patchwork.ozlabs.org) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4ZtRPC3BkWz1yQ7 for ; Thu, 8 May 2025 19:17:51 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=69xk8QN9LbecGAAun+SdXIlnEDtczaO/7wGswwvBris=; b=mywjTpx+mxiv5EPgzv/TtGuqw2 Tv8Y+8P4jTinSgCVpmy8IFGrFxuABmZJVtu0Wqkv8MS1r/pV4b1tnaeF8fJ1qHCTt5QZfNUmOvE+x LRpHEJYX3H8nzuE/smK1Awd4M5+i7QOs4+sbOGsBLJEjpjoDXiLnw3HUqlRmShZijOLUMlcAhtZ50 /Wm3cJrHvFoZT/Qm4WKMa5FZUUzclixCqTMYRSCKvI+C2JdG/vNLrx7TsDiEtxoNQwZTG04yslZ2Z OtWxPuo54mD38GR51FgBGhbfPJf/8MhGnvHeRR4Igs2RWBGO/7qm6xHVzy8ilq/QWuIkBpRYRlsaz bzfqvWkQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uCxOI-00000000EiI-0MHQ; Thu, 08 May 2025 09:18:06 +0000 Received: from nyc.source.kernel.org ([147.75.193.91]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uCx4n-00000000BiA-0JJe for linux-um@lists.infradead.org; Thu, 08 May 2025 08:57:59 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 2A677A4AFCE; Thu, 8 May 2025 08:57:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48B85C4CEEB; Thu, 8 May 2025 08:57:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746694675; bh=wHPATXC9LkJsZRMeS2x8lNdgUXoYaxjzLb5iBN80POk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m+bi/J7r34LfUr94fxQXkxjMN93ATfTaQ26PPYNkdilIHd3MkJ78rtWPVgL7iTZ3c DZZEL8XgkNfveoCLgQemc6R6LWGfBb98fV4a/b9oqP+4ttnKUy7KLhFbwHZYBtQgKE kaWTMbPIwphXJyXeF3QoOwjNv4B7c7egGeE/fiAzh57y9UdQx0acsfVHhWmVHBeeGu DcDcmZlpKWfcHJfQeAwvwfTyo7RyhpSvmnPKdUhic3BKS8Gh7m0ZLad/d4DcHQhLaA hPd5scmwhnFt8Acf71o5Tz8i1C/PxZyzByZBIDgJd0u2pznhweP4PDli34VM/Wrnn/ vaGJoIVprpjpQ== Date: Thu, 8 May 2025 10:57:51 +0200 From: Ingo Molnar To: Johannes Berg Cc: "linux-kernel@vger.kernel.org" , "linux-tip-commits@vger.kernel.org" , lkp , "x86@kernel.org" , linux-um@lists.infradead.org Subject: [PATCH -v2] accel/habanalabs: Don't build the driver on UML Message-ID: References: <202505080003.0t7ewxGp-lkp@intel.com> <174664324585.406.10812098910624084030.tip-bot2@tip-bot2> <007a7132d1396912b1381e96cc4401a10071ed24.camel@sipsolutions.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <007a7132d1396912b1381e96cc4401a10071ed24.camel@sipsolutions.net> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250508_015757_252149_D681D070 X-CRM114-Status: GOOD ( 29.94 ) X-Spam-Score: -5.8 (-----) X-Spam-Report: Spam detection software, running on the system "bombadil.infradead.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: * Johannes Berg wrote: > +linux-um > > On Wed, 2025-05-07 at 18:40 +0000, tip-bot2 for Ingo Molnar wrote: > > > > To resolve these kinds of problems and to allow to be included on UML, > > add a simplified versi [...] Content analysis details: (-5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [147.75.193.91 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [147.75.193.91 listed in sa-trusted.bondedsender.org] 0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [147.75.193.91 listed in sa-accredit.habeas.com] -1.4 DKIMWL_WL_HIGH DKIMwl.org - High trust sender 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. [147.75.193.91 listed in bl.score.senderscore.com] X-BeenThere: linux-um@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-um" Errors-To: linux-um-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org * Johannes Berg wrote: > +linux-um > > On Wed, 2025-05-07 at 18:40 +0000, tip-bot2 for Ingo Molnar wrote: > > > > To resolve these kinds of problems and to allow to be included on UML, > > add a simplified version of , which only adds the rdtsc() definition. > > OK, weird, why would that be needed - UM isn't really X86. > > > arch/um/include/asm/tsc.h | 25 +++++++++++++++++++++++++ > > Feels that should be in arch/x86/um/asm/ instead, which I believe is > also included but then at least pretends to keep the notion that UML > could be ported to other architectures ;-) > > > +static __always_inline u64 rdtsc(void) > > +{ > > + EAX_EDX_DECLARE_ARGS(val, low, high); > > + > > + asm volatile("rdtsc" : EAX_EDX_RET(val, low, high)); > > + > > + return EAX_EDX_VAL(val, low, high); > > +} > > Though I also wonder where this is called at all that would be relevant > for UML? If it's not then perhaps we should just make using it > unbuildable, a la > > u64 __um_has_no_rdtsc(void); > #define rdtsc() __um_has_no_rdtsc() > > or something like that... (and then of course keep it in the current > location). But looking at the 0-day report that'd probably break > building the driver on UML; while the driver doesn't seem important we > wouldn't really want that... > > Actually, that's just because of the stupid quirk in UML/X86: > > config DRM_ACCEL_HABANALABS > tristate "HabanaLabs AI accelerators" > depends on DRM_ACCEL > depends on X86_64 > > that last line should almost certainly be "depends on X86 && X86_64" > because ARCH=um will set UM and X86_64, but not X86 since the arch > Kconfig symbols are X86 and UM respectively, but the UML subarch still > selects X86_64 ... > > > I dunno. I guess we can put rdtsc() into UML on x86 as I suggested about > the file placement, or we can also just fix the Kconfig there. The Kconfig solution looks much simpler to me too :) Patch attached, does this look good to you? Thanks, Ingo ===================================> From: Ingo Molnar Date: Wed, 7 May 2025 20:25:59 +0200 Subject: [PATCH] accel/habanalabs: Don't build the driver on UML The following commit: 288a4ff0ad29 ("x86/msr: Move rdtsc{,_ordered}() to ") removed the include from the accel/habanalabs driver, which broke the build on UML: drivers/accel/habanalabs/common/habanalabs_ioctl.c:326:23: error: call to undeclared function 'rdtsc'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] Make the driver depend on 'X86 && X86_64', instead of just 'X86_64', thus it won't be built on UML. Suggested-by: Johannes Berg Reported-by: kernel test robot Signed-off-by: Ingo Molnar Cc: Ofir Bitton Cc: Oded Gabbay Link: https://lore.kernel.org/r/202505080003.0t7ewxGp-lkp@intel.com Reviewed-by: Johannes Berg --- drivers/accel/habanalabs/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/accel/habanalabs/Kconfig b/drivers/accel/habanalabs/Kconfig index be85336107f9..1919fbb169c7 100644 --- a/drivers/accel/habanalabs/Kconfig +++ b/drivers/accel/habanalabs/Kconfig @@ -6,7 +6,7 @@ config DRM_ACCEL_HABANALABS tristate "HabanaLabs AI accelerators" depends on DRM_ACCEL - depends on X86_64 + depends on X86 && X86_64 depends on PCI && HAS_IOMEM select GENERIC_ALLOCATOR select HWMON