arch/um/include/asm/tsc.h | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 arch/um/include/asm/tsc.h
The following commit has been merged into the x86/msr branch of tip:
Commit-ID: 24b58adaa7508d9d2cdb6bca44803954baf24459
Gitweb: https://git.kernel.org/tip/24b58adaa7508d9d2cdb6bca44803954baf24459
Author: Ingo Molnar <mingo@kernel.org>
AuthorDate: Wed, 07 May 2025 20:18:22 +02:00
Committer: Ingo Molnar <mingo@kernel.org>
CommitterDate: Wed, 07 May 2025 20:30:39 +02:00
um: Add UML version of <asm/tsc.h> to define rdtsc()
In the x86 tree rdtsc() methods got moved out of <asm/msr.h>, but this
broke UML, as the x86 version of <asm/tsc.h> cannot be used by UML as-is:
CC [M] drivers/accel/habanalabs/common/habanalabs_ioctl.o
In file included from drivers/accel/habanalabs/common/habanalabs_ioctl.c:20:
./arch/x86/include/asm/tsc.h:70:28: error: conflicting types for ‘cycles_t’; have ‘long long unsigned int’
70 | typedef unsigned long long cycles_t;
| ^~~~~~~~
In file included from ./arch/um/include/asm/timex.h:7,
from ./include/linux/timex.h:67,
from ./include/linux/time32.h:13,
from ./include/linux/time.h:60,
from ./include/linux/skbuff.h:15,
from ./include/linux/if_ether.h:19,
from ./include/linux/habanalabs/cpucp_if.h:12,
from drivers/accel/habanalabs/common/habanalabs.h:11,
from drivers/accel/habanalabs/common/habanalabs_ioctl.c:11:
./include/asm-generic/timex.h:8:23: note: previous declaration of ‘cycles_t’ with type ‘cycles_t’ {aka ‘long unsigned int’}
8 | typedef unsigned long cycles_t;
| ^~~~~~~~
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.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Johannes Berg <johannes.berg@intel.com>
Link: https://lore.kernel.org/r/202505080003.0t7ewxGp-lkp@intel.com
---
arch/um/include/asm/tsc.h | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 arch/um/include/asm/tsc.h
diff --git a/arch/um/include/asm/tsc.h b/arch/um/include/asm/tsc.h
new file mode 100644
index 0000000..a52b0e4
--- /dev/null
+++ b/arch/um/include/asm/tsc.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_UM_TSC_H
+#define _ASM_UM_TSC_H
+
+#include <asm/asm.h>
+
+/**
+ * rdtsc() - returns the current TSC without ordering constraints
+ *
+ * rdtsc() returns the result of RDTSC as a 64-bit integer. The
+ * only ordering constraint it supplies is the ordering implied by
+ * "asm volatile": it will put the RDTSC in the place you expect. The
+ * CPU can and will speculatively execute that RDTSC, though, so the
+ * results can be non-monotonic if compared on different CPUs.
+ */
+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);
+}
+
+#endif /* _ASM_UM_TSC_H */+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
* 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 HWMONOn 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
* 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
Johannes: this is basically an RFC, not a final commit, will add your
Reviewed-by if it's fine to you, or will change the patch if it's not.
Thanks,
Ingo
* tip-bot2 for Ingo Molnar <tip-bot2@linutronix.de> wrote:
> The following commit has been merged into the x86/msr branch of tip:
>
> Commit-ID: 24b58adaa7508d9d2cdb6bca44803954baf24459
> Gitweb: https://git.kernel.org/tip/24b58adaa7508d9d2cdb6bca44803954baf24459
> Author: Ingo Molnar <mingo@kernel.org>
> AuthorDate: Wed, 07 May 2025 20:18:22 +02:00
> Committer: Ingo Molnar <mingo@kernel.org>
> CommitterDate: Wed, 07 May 2025 20:30:39 +02:00
>
> um: Add UML version of <asm/tsc.h> to define rdtsc()
>
> In the x86 tree rdtsc() methods got moved out of <asm/msr.h>, but this
> broke UML, as the x86 version of <asm/tsc.h> cannot be used by UML as-is:
>
> CC [M] drivers/accel/habanalabs/common/habanalabs_ioctl.o
> In file included from drivers/accel/habanalabs/common/habanalabs_ioctl.c:20:
> ./arch/x86/include/asm/tsc.h:70:28: error: conflicting types for ‘cycles_t’; have ‘long long unsigned int’
> 70 | typedef unsigned long long cycles_t;
> | ^~~~~~~~
> In file included from ./arch/um/include/asm/timex.h:7,
> from ./include/linux/timex.h:67,
> from ./include/linux/time32.h:13,
> from ./include/linux/time.h:60,
> from ./include/linux/skbuff.h:15,
> from ./include/linux/if_ether.h:19,
> from ./include/linux/habanalabs/cpucp_if.h:12,
> from drivers/accel/habanalabs/common/habanalabs.h:11,
> from drivers/accel/habanalabs/common/habanalabs_ioctl.c:11:
> ./include/asm-generic/timex.h:8:23: note: previous declaration of ‘cycles_t’ with type ‘cycles_t’ {aka ‘long unsigned int’}
> 8 | typedef unsigned long cycles_t;
> | ^~~~~~~~
>
> 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.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> Cc: Johannes Berg <johannes.berg@intel.com>
> Link: https://lore.kernel.org/r/202505080003.0t7ewxGp-lkp@intel.com
> ---
> arch/um/include/asm/tsc.h | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 arch/um/include/asm/tsc.h
>
> diff --git a/arch/um/include/asm/tsc.h b/arch/um/include/asm/tsc.h
> new file mode 100644
> index 0000000..a52b0e4
> --- /dev/null
> +++ b/arch/um/include/asm/tsc.h
> @@ -0,0 +1,25 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_UM_TSC_H
> +#define _ASM_UM_TSC_H
> +
> +#include <asm/asm.h>
> +
> +/**
> + * rdtsc() - returns the current TSC without ordering constraints
> + *
> + * rdtsc() returns the result of RDTSC as a 64-bit integer. The
> + * only ordering constraint it supplies is the ordering implied by
> + * "asm volatile": it will put the RDTSC in the place you expect. The
> + * CPU can and will speculatively execute that RDTSC, though, so the
> + * results can be non-monotonic if compared on different CPUs.
> + */
> +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);
> +}
> +
> +#endif /* _ASM_UM_TSC_H */
© 2016 - 2025 Red Hat, Inc.