Enable experimental rust support for ppc64le and ppc32be. The patch for
ppc32 has been provided by Link Mauve[1] and ppc64le support[2] has been
merged over it. ppc32 needs some toolchain fixes mentioned in the patch
`rust: Add PowerPC support` and the discussion for that is done here[1].
This has been tested on powernv9 hardware and power10 pseries qemu. I
I request Link to test the ppc32 part as i don't have a hardware to test
it out.
[1] https://lore.kernel.org/all/20260204030507.8203-1-linkmauve@linkmauve.fr
[2] https://lore.kernel.org/all/20260204042417.83903-1-mkchauras@gmail.com
Changelog:
V1 -> V2:
- jump label fix for rust has been moved to a separate patch
- PPC32 support has been taken
- rust support has been marked experimental
- target.json dependency has been removed
- HAVE_RUST now depends on CPU_LITTLE_ENDIAN for PPC64
Link Mauve (1):
rust: Add PowerPC support
Mukesh Kumar Chaurasiya (IBM) (2):
powerpc/jump_label: adjust inline asm to be consistent
powerpc: Enable Rust for ppc64le
Documentation/rust/arch-support.rst | 1 +
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 9 +++++++++
arch/powerpc/include/asm/jump_label.h | 23 +++++++++++++----------
rust/Makefile | 11 ++++++++++-
5 files changed, 34 insertions(+), 11 deletions(-)
--
2.52.0
Added support for a new macro ARCH_STATIC_BRANCH_ASM in powerpc
to avoid duplication of inline asm between C and Rust. This is
inline with commit aecaf181651c '("jump_label: adjust inline asm to be consistent")'
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <redacted>
---
arch/powerpc/include/asm/jump_label.h | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
From: Link Mauve <redacted>
For now only Big Endian 32-bit PowerPC is supported, as that is the only
hardware I have. This has been tested on the Nintendo Wii so far, but I
plan on also using it on the GameCube, Wii U and Apple G4.
These changes aren’t the only ones required to get the kernel to compile
and link on PowerPC, libcore will also have to be changed to not use
integer division to format u64, u128 and core::time::Duration, otherwise
__udivdi3() and __umoddi3() will have to be added. I have tested this
change by replacing the three implementations with unimplemented!() and
it linked just fine.
Signed-off-by: Link Mauve <redacted>
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <redacted>
---
Documentation/rust/arch-support.rst | 1 +
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 2 ++
rust/Makefile | 4 +++-
4 files changed, 7 insertions(+), 1 deletion(-)
@@ -392,10 +392,17 @@ BINDGEN_TARGET_x86 := x86_64-linux-gnuBINDGEN_TARGET_arm64:=aarch64-linux-gnuBINDGEN_TARGET_arm:=arm-linux-gnueabiBINDGEN_TARGET_loongarch:=loongarch64-linux-gnusf-BINDGEN_TARGET_powerpc:=powerpc-linux-gnuBINDGEN_TARGET_um:=$(BINDGEN_TARGET_$(SUBARCH))BINDGEN_TARGET:=$(BINDGEN_TARGET_$(SRCARCH))+ifdef CONFIG_PPC64+ifdef CONFIG_CPU_LITTLE_ENDIAN+BINDGEN_TARGET_powerpc:=powerpc64le-linux-gnu+endif+else+BINDGEN_TARGET_powerpc:=powerpc-linux-gnu+endif+# All warnings are inhibited since GCC builds are very experimental,# many GCC warnings are not supported by Clang, they may only appear in# some configurations, with new GCC versions, etc.
Le 04/02/2026 à 22:01, Mukesh Kumar Chaurasiya (IBM) a écrit :
[Vous ne recevez pas souvent de courriers de mkchauras@gmail.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
Added support for a new macro ARCH_STATIC_BRANCH_ASM in powerpc
to avoid duplication of inline asm between C and Rust. This is
inline with commit aecaf181651c '("jump_label: adjust inline asm to be consistent")'
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <redacted>
Would be better to leave the first line as is and add a second line as
follows:
select HAVE_RUST if PPC64 && CPU_LITTLE_ENDIAN
quoted hunk
select HAVE_SAMPLE_FTRACE_DIRECT if HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
select HAVE_SAMPLE_FTRACE_DIRECT_MULTI if HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
select HAVE_SETUP_PER_CPU_AREA if PPC64
@@ -392,10 +392,17 @@ BINDGEN_TARGET_x86 := x86_64-linux-gnuBINDGEN_TARGET_arm64:=aarch64-linux-gnuBINDGEN_TARGET_arm:=arm-linux-gnueabiBINDGEN_TARGET_loongarch:=loongarch64-linux-gnusf-BINDGEN_TARGET_powerpc:=powerpc-linux-gnuBINDGEN_TARGET_um:=$(BINDGEN_TARGET_$(SUBARCH))BINDGEN_TARGET:=$(BINDGEN_TARGET_$(SRCARCH))+ifdef CONFIG_PPC64+ifdef CONFIG_CPU_LITTLE_ENDIAN+BINDGEN_TARGET_powerpc:=powerpc64le-linux-gnu+endif+else+BINDGEN_TARGET_powerpc:=powerpc-linux-gnu+endif+ # All warnings are inhibited since GCC builds are very experimental, # many GCC warnings are not supported by Clang, they may only appear in # some configurations, with new GCC versions, etc.--
From: Alice Ryhl <aliceryhl@google.com> Date: 2026-02-05 08:24:20
On Thu, Feb 05, 2026 at 02:31:23AM +0530, Mukesh Kumar Chaurasiya (IBM) wrote:
Added support for a new macro ARCH_STATIC_BRANCH_ASM in powerpc
to avoid duplication of inline asm between C and Rust. This is
inline with commit aecaf181651c '("jump_label: adjust inline asm to be consistent")'
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <redacted>
You define BINDGEN_TARGET_powerpc after BINDGEN_TARGET has been set to
the value of $(BINDGEN_TARGET_$(SRCARCH)), so it is empty and bindgen
then gets passed --target= which makes it fail here, with this error
message:
+
# All warnings are inhibited since GCC builds are very experimental,
# many GCC warnings are not supported by Clang, they may only appear in
# some configurations, with new GCC versions, etc.
--
2.52.0
With this fixed:
Reviewed-by: Link Mauve <redacted>
Tested-by: Link Mauve <redacted>
--
Link Mauve
You define BINDGEN_TARGET_powerpc after BINDGEN_TARGET has been set to
the value of $(BINDGEN_TARGET_$(SRCARCH)), so it is empty and bindgen
then gets passed --target= which makes it fail here, with this error
message:
On ppc64le, I am not able to get a successful Rust‑enabled build yet.
I am consistently hitting bindgen/libclang failures during the prepare
phase.
Build Failures:
error: unsupported option '-mlong-double-128' for target 'unknown'
error: unsupported argument 'medium' to option '-mcmodel=' for target
'unknown'
error: unknown target triple 'unknown'
panicked at bindgen-0.72.1/ir/context.rs:562:15:
libclang error; possible causes include:
- Invalid flag syntax
- Unrecognized flags
- Invalid flag arguments
- File I/O errors
- Host vs. target architecture mismatch
make[2]: *** [rust/Makefile:468: rust/bindings/bindings_generated.rs]
Error 101
make[2]: *** Deleting file 'rust/bindings/bindings_generated.rs'
make[2]: *** [rust/Makefile:488:
rust/bindings/bindings_helpers_generated.rs] Error 101
make[2]: *** Deleting file 'rust/bindings/bindings_helpers_generated.rs'
make[2]: *** [rust/Makefile:474: rust/uapi/uapi_generated.rs] Error 101
make[2]: *** Deleting file 'rust/uapi/uapi_generated.rs'
make[2]: *** [rust/Makefile:643: rust/core.o] Error 1
make[1]: *** [/root/linux/Makefile:1320: prepare] Error 2
make: *** [Makefile:248: __sub-make] Error 2
Regards,
Venkat.
quoted
+
# All warnings are inhibited since GCC builds are very experimental,
# many GCC warnings are not supported by Clang, they may only appear in
# some configurations, with new GCC versions, etc.
--
2.52.0
With this fixed:
Reviewed-by: Link Mauve <redacted>
Tested-by: Link Mauve <redacted>
You define BINDGEN_TARGET_powerpc after BINDGEN_TARGET has been set to
the value of $(BINDGEN_TARGET_$(SRCARCH)), so it is empty and bindgen
then gets passed --target= which makes it fail here, with this error
message:
I am able to compile it and boot it on ppc64le qemu pseries and
powernv9 hardware.
I agree this might cause an issue. Will fix this and send out a new
revision.
ppc64be still has some missing things from the toolchain side. For
ppc64le it does works, atleast on powernv9 hardware and pseries POWER10
qemu.
quoted
+
# All warnings are inhibited since GCC builds are very experimental,
# many GCC warnings are not supported by Clang, they may only appear in
# some configurations, with new GCC versions, etc.
--
2.52.0
With this fixed:
Reviewed-by: Link Mauve <redacted>
Tested-by: Link Mauve <redacted>
You define BINDGEN_TARGET_powerpc after BINDGEN_TARGET has been set to
the value of $(BINDGEN_TARGET_$(SRCARCH)), so it is empty and bindgen
then gets passed --target= which makes it fail here, with this error
message:
+
# All warnings are inhibited since GCC builds are very experimental,
# many GCC warnings are not supported by Clang, they may only appear in
# some configurations, with new GCC versions, etc.
--
2.52.0
With this fixed:
Reviewed-by: Link Mauve <redacted>
Tested-by: Link Mauve <redacted>
It appears to be a bug in LLVM 22 for ppc64, not present in 21.
If I understand correctly, then it may be fixed in 22.1.9 if it gets released.
Thanks Jubilee for the quick reply there!
Cc'ing Clang/LLVM build support, in case they didn't hear about it.
I linked it in our usual lists.
Cheers,
Miguel
It appears to be a bug in LLVM 22 for ppc64, not present in 21.
If I understand correctly, then it may be fixed in 22.1.9 if it gets released.
Thanks Jubilee for the quick reply there!
Cc'ing Clang/LLVM build support, in case they didn't hear about it.
Thanks for the CC, I had not seen that issue. LLVM 22 is currently in
the -rc phase and I see that the fix has been merged into the
release/22.x branch as of yesterday so it should be in LLVM 21.1.0-rc3
when it get released on February 10. LLVM 21.1.8 was the last release of
the 21.x series (hard to keep up with all the numbers...) and it sounds
like this is only a regression from the LLVM 22 development cycle.
Cheers,
Nathan
From: Miguel Ojeda <hidden> Date: 2026-02-05 20:15:45
On Thu, Feb 5, 2026 at 9:02 PM Nathan Chancellor [off-list ref] wrote:
Thanks for the CC, I had not seen that issue. LLVM 22 is currently in
the -rc phase and I see that the fix has been merged into the
release/22.x branch as of yesterday so it should be in LLVM 21.1.0-rc3
when it get released on February 10. LLVM 21.1.8 was the last release of
the 21.x series (hard to keep up with all the numbers...) and it sounds
like this is only a regression from the LLVM 22 development cycle.
Yeah, sorry, mixed up 21.1.9 with the potential 22.1.9 in summer this year, bah!
Fixed my comment in the issue to avoid confusion.
Thanks!
Cheers,
Miguel
From: Miguel Ojeda <hidden> Date: 2026-02-11 22:23:23
On Thu, Feb 5, 2026 at 9:02 PM Nathan Chancellor [off-list ref] wrote:
Thanks for the CC, I had not seen that issue. LLVM 22 is currently in
the -rc phase and I see that the fix has been merged into the
release/22.x branch as of yesterday so it should be in LLVM 21.1.0-rc3
when it get released on February 10. LLVM 21.1.8 was the last release of
the 21.x series (hard to keep up with all the numbers...) and it sounds
like this is only a regression from the LLVM 22 development cycle.
Another reason to use a nightly version is that Rust inline assembly for
PowerPC will only be stabilized[1] in version 1.94, so current release
versions fail like this (tested with 1.91.1):
error[E0658]: inline assembly is not stable yet on this architecture
--> ../rust/kernel/sync/barrier.rs:19:14
|
19 | unsafe { core::arch::asm!("") };
| ^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #93335 <https://github.com/rust-lang/rust/issues/93335> for more information
= help: add `#![feature(asm_experimental_arch)]` to the crate attributes to enable
= note: this compiler was built on 2025-11-07; consider upgrading it if it is out of date
This is somewhat at odds with Documentation/process/changes.rst which
only requires Rust 1.78. I wonder if the rust version requirement should
generally be bumped, or if there should be arch-specific requirements
somewhere in changes.rst or rust/arch-support.rst.
Best regards,
J. Neuschäfer
[1]: https://github.com/rust-lang/rust/pull/147996
Another reason to use a nightly version is that Rust inline assembly for
PowerPC will only be stabilized[1] in version 1.94, so current release
versions fail like this (tested with 1.91.1):
error[E0658]: inline assembly is not stable yet on this architecture
--> ../rust/kernel/sync/barrier.rs:19:14
|
19 | unsafe { core::arch::asm!("") };
| ^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #93335 <https://github.com/rust-lang/rust/issues/93335> for more information
= help: add `#![feature(asm_experimental_arch)]` to the crate attributes to enable
= note: this compiler was built on 2025-11-07; consider upgrading it if it is out of date
This is somewhat at odds with Documentation/process/changes.rst which
only requires Rust 1.78. I wonder if the rust version requirement should
generally be bumped, or if there should be arch-specific requirements
somewhere in changes.rst or rust/arch-support.rst.
Best regards,
J. Neuschäfer
[1]: https://github.com/rust-lang/rust/pull/147996
The MSRV is planned to be bumped to 1.85.
If it's available as a nightly feature on 1.78, then you can just add
#![feature(asm_experimental_arch)] to lib.rs, which already enables
several other stabilized feature on older compilers.
Otherwise powerpc support can always be gated to require a larger
rustc version than other platforms.
Alice