Re: [tip: x86/msr] um: Add UML version of <asm/tsc.h> to define rdtsc()

Re: [tip: x86/msr] um: Add UML version of <asm/tsc.h> to define rdtsc()

[Johannes Berg]

+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.

johannes

[PATCH -v2] accel/habanalabs: Don't build the driver on UML

[Ingo Molnar]

* 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

Re: [PATCH -v2] accel/habanalabs: Don't build the driver on UML

[Johannes Berg]

On Thu, 2025-05-08 at 10:57 +0200, Ingo Molnar wrote:
> > 
> > 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?

Yeah looks good to me. Common gotcha really.

Reviewed-by: Johannes Berg <johannes@sipsolutions.net>

If anyone _really_ needs to have this driver built on UML (say for
simulations/testing, we do build iwlwifi for all the time), then they'd
probably want to replace the rdtsc() anyway with something else there.

johannes

Re: [PATCH -v2] accel/habanalabs: Don't build the driver on UML

[Ingo Molnar]

* Johannes Berg <johannes@sipsolutions.net> wrote:

> On Thu, 2025-05-08 at 10:57 +0200, Ingo Molnar wrote:
> > > 
> > > 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?
> 
> Yeah looks good to me. Common gotcha really.
> 
> Reviewed-by: Johannes Berg <johannes@sipsolutions.net>

Thanks, applied to tip:x86/msr.

> If anyone _really_ needs to have this driver built on UML (say for 
> simulations/testing, we do build iwlwifi for all the time), then 
> they'd probably want to replace the rdtsc() anyway with something 
> else there.

Yeah.

	Ingo