From: Ingo Molnar <mingo@kernel.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-tip-commits@vger.kernel.org"
<linux-tip-commits@vger.kernel.org>, lkp <lkp@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
linux-um@lists.infradead.org
Subject: [PATCH -v2] accel/habanalabs: Don't build the driver on UML
Date: Thu, 8 May 2025 10:57:51 +0200 [thread overview]
Message-ID: <aBxyDyVT5QbOlhPq@gmail.com> (raw)
In-Reply-To: <007a7132d1396912b1381e96cc4401a10071ed24.camel@sipsolutions.net>
* Johannes Berg <johannes@sipsolutions.net> 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 <asm/tsc.h> to be included on UML,
> > add a simplified version of <asm/tsc.h>, 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 <mingo@kernel.org>
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 <asm/tsc.h>")
removed the <asm/msr.h> 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 <johannes.berg@intel.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Ofir Bitton <obitton@habana.ai>
Cc: Oded Gabbay <ogabbay@kernel.org>
Link: https://lore.kernel.org/r/202505080003.0t7ewxGp-lkp@intel.com
---
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
next prev parent reply other threads:[~2025-05-08 9:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <202505080003.0t7ewxGp-lkp@intel.com>
[not found] ` <174664324585.406.10812098910624084030.tip-bot2@tip-bot2>
2025-05-07 20:36 ` [tip: x86/msr] um: Add UML version of <asm/tsc.h> to define rdtsc() Johannes Berg
2025-05-08 8:57 ` Ingo Molnar [this message]
2025-05-08 9:02 ` [PATCH -v2] accel/habanalabs: Don't build the driver on UML Johannes Berg
2025-05-08 9:03 ` Ingo Molnar
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=aBxyDyVT5QbOlhPq@gmail.com \
--to=mingo@kernel.org \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=lkp@intel.com \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).