Enable building Rust code on s390 by wiring the architecture into the
kernel Rust infrastructure.
Add s390 to the Rust arch support documentation, provide the s390 Rust
target and required compiler flags, and set the bindgen target for
arch/s390. Adjust the Rust target generation and minimum rustc version
gating so the s390 setup is handled explicitly.
The Rust toolchain uses the "s390x" triple naming for the 64 bit target.
Rust support is currently incompatible with CONFIG_EXPOLINE, which
relies on compiler support for the -mindirect-branch= and
-mfunction_return= options. Therefore, select HAVE_RUST only when
EXPOLINE is disabled.
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
Documentation/rust/arch-support.rst | 1 +
arch/s390/Kconfig | 1 +
arch/s390/Makefile | 28 +++++++++++++++++-----------
rust/Makefile | 1 +
scripts/generate_rust_target.rs | 2 ++
scripts/min-tool-version.sh | 6 +++++-
6 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst
index 6e6a515d0899..ce9804b8226c 100644
--- a/Documentation/rust/arch-support.rst
+++ b/Documentation/rust/arch-support.rst
@@ -19,6 +19,7 @@ Architecture Level of support Constraints
``arm64`` Maintained Little Endian only.
``loongarch`` Maintained \-
``riscv`` Maintained ``riscv64`` and LLVM/Clang only.
+``s390`` Maintained \-
``um`` Maintained \-
``x86`` Maintained ``x86_64`` only.
============= ================ ==============================================
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index ecbcbb781e40..26951781d74d 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -248,6 +248,7 @@ config S390
select HAVE_RELIABLE_STACKTRACE
select HAVE_RETHOOK
select HAVE_RSEQ
+ select HAVE_RUST if !EXPOLINE
select HAVE_SAMPLE_FTRACE_DIRECT
select HAVE_SAMPLE_FTRACE_DIRECT_MULTI
select HAVE_SETUP_PER_CPU_AREA
diff --git a/arch/s390/Makefile b/arch/s390/Makefile
index 297976b41088..c393c22c47c8 100644
--- a/arch/s390/Makefile
+++ b/arch/s390/Makefile
@@ -35,25 +35,31 @@ KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO),-g)
KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO_DWARF4), $(call cc-option, -gdwarf-4,))
KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_CC_NO_ARRAY_BOUNDS),-Wno-array-bounds)
+KBUILD_RUSTFLAGS += --target=s390x-unknown-none-softfloat -Zpacked-stack -Ctarget-feature=+backchain
+
UTS_MACHINE := s390x
STACK_SIZE := $(if $(CONFIG_KASAN),65536,$(if $(CONFIG_KMSAN),65536,16384))
CHECKFLAGS += -D__s390__ -D__s390x__
export LD_BFD
-mflags-$(CONFIG_MARCH_Z10) := -march=z10
-mflags-$(CONFIG_MARCH_Z196) := -march=z196
-mflags-$(CONFIG_MARCH_ZEC12) := -march=zEC12
-mflags-$(CONFIG_MARCH_Z13) := -march=z13
-mflags-$(CONFIG_MARCH_Z14) := -march=z14
-mflags-$(CONFIG_MARCH_Z15) := -march=z15
-mflags-$(CONFIG_MARCH_Z16) := -march=z16
-mflags-$(CONFIG_MARCH_Z17) := -march=z17
+march-name-$(CONFIG_MARCH_Z10) := z10
+march-name-$(CONFIG_MARCH_Z196) := z196
+march-name-$(CONFIG_MARCH_ZEC12) := zEC12
+march-name-$(CONFIG_MARCH_Z13) := z13
+march-name-$(CONFIG_MARCH_Z14) := z14
+march-name-$(CONFIG_MARCH_Z15) := z15
+march-name-$(CONFIG_MARCH_Z16) := z16
+march-name-$(CONFIG_MARCH_Z17) := z17
-export CC_FLAGS_MARCH := $(mflags-y)
+mflags += -march=$(march-name-y)
-aflags-y += $(mflags-y)
-cflags-y += $(mflags-y)
+export CC_FLAGS_MARCH := $(mflags)
+
+aflags-y += $(mflags)
+cflags-y += $(mflags)
+
+KBUILD_RUSTFLAGS += -Ctarget-cpu=$(march-name-y)
cflags-$(CONFIG_MARCH_Z10_TUNE) += -mtune=z10
cflags-$(CONFIG_MARCH_Z196_TUNE) += -mtune=z196
diff --git a/rust/Makefile b/rust/Makefile
index b9e9f512cec3..77460502f576 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -403,6 +403,7 @@ BINDGEN_TARGET_x86 := x86_64-linux-gnu
BINDGEN_TARGET_arm64 := aarch64-linux-gnu
BINDGEN_TARGET_arm := arm-linux-gnueabi
BINDGEN_TARGET_loongarch := loongarch64-linux-gnusf
+BINDGEN_TARGET_s390 := s390x-linux-gnu
# This is only for i386 UM builds, which need the 32-bit target not -m32
BINDGEN_TARGET_i386 := i386-linux-gnu
BINDGEN_TARGET_um := $(BINDGEN_TARGET_$(SUBARCH))
diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
index 38b3416bb979..8f1df6819d0b 100644
--- a/scripts/generate_rust_target.rs
+++ b/scripts/generate_rust_target.rs
@@ -256,6 +256,8 @@ fn main() {
}
} else if cfg.has("LOONGARCH") {
panic!("loongarch uses the builtin rustc loongarch64-unknown-none-softfloat target");
+ } else if cfg.has("S390") {
+ panic!("s390 uses the builtin rustc s390x-unknown-none-softfloat target");
} else {
panic!("Unsupported architecture");
}
diff --git a/scripts/min-tool-version.sh b/scripts/min-tool-version.sh
index b96ec2d379b6..b1020cb9b755 100755
--- a/scripts/min-tool-version.sh
+++ b/scripts/min-tool-version.sh
@@ -31,7 +31,11 @@ llvm)
fi
;;
rustc)
- echo 1.85.0
+ if [ "$SRCARCH" = "s390" ]; then
+ echo 1.97.0-nightly
+ else
+ echo 1.85.0
+ fi
;;
bindgen)
echo 0.71.1
--
2.51.0On Tue, May 12, 2026 at 1:00 PM Jan Polensky <japo@linux.ibm.com> wrote: > > Signed-off-by: Jan Polensky <japo@linux.ibm.com> Closes: https://github.com/Rust-for-Linux/linux/issues/106 I am happy to see IBM getting involved and being able to close a 5 year issue! :) I backlinked there this thread. > +KBUILD_RUSTFLAGS += --target=s390x-unknown-none-softfloat -Zpacked-stack -Ctarget-feature=+backchain I added `-Zpacked-stack` and a bunch of related links to: https://github.com/Rust-for-Linux/linux/issues/2 Is there a tracking issue for it? I linked https://github.com/rust-lang/rust/issues/150259 for the backchain feature. > + if [ "$SRCARCH" = "s390" ]; then > + echo 1.97.0-nightly `-Zpacked-stack` landed for 1.96. Is there something queued for 1.97? If not, does the beta work? Either way, I would prefer waiting until we know the actual version number, i.e. without `-nightly`. It is just a few weeks away anyway. Thanks! Cheers, Miguel
On Tue, May 12, 2026 at 02:10:52PM +0200, Miguel Ojeda wrote: > On Tue, May 12, 2026 at 1:00 PM Jan Polensky <japo@linux.ibm.com> wrote: > > > > Signed-off-by: Jan Polensky <japo@linux.ibm.com> > > Closes: https://github.com/Rust-for-Linux/linux/issues/106 > > I am happy to see IBM getting involved and being able to close a 5 > year issue! :) :) > > I backlinked there this thread. > > > +KBUILD_RUSTFLAGS += --target=s390x-unknown-none-softfloat -Zpacked-stack -Ctarget-feature=+backchain > > I added `-Zpacked-stack` and a bunch of related links to: > > https://github.com/Rust-for-Linux/linux/issues/2 > > Is there a tracking issue for it? I linked > https://github.com/rust-lang/rust/issues/150259 for the backchain > feature. > > > + if [ "$SRCARCH" = "s390" ]; then > > + echo 1.97.0-nightly > > `-Zpacked-stack` landed for 1.96. Is there something queued for 1.97? > If not, does the beta work? > > Either way, I would prefer waiting until we know the actual version > number, i.e. without `-nightly`. It is just a few weeks away anyway. > > Thanks! > > Cheers, > Miguel Hi Miguel, thanks for the review. -Zpacked-stack: I’m not aware of a dedicated rust-lang/rust tracking issue for this flag. The implementation landed via rust-lang/rust PR 152432, but it doesn’t appear to reference a tracking issue. backchain: ack, the s390x target-feature tracking issue you linked is the right umbrella reference. minimum toolchain version / beta: as long as we pass -Zpacked-stack in KBUILD_RUSTFLAGS, we need a nightly compiler; beta/stable won’t accept -Z flags. In v2 I’ll drop the 1.97.0-nightly guess and set the minimum to 1.96.0-nightly (the first release line that includes -Zpacked-stack). We’ll keep the “-nightly” suffix while this remains a -Z flag. If it gets stabilized and nothing blocks, the earliest stable release that could plausibly carry it would be 1.98. Thanks, Jan
On Mon, May 18, 2026 at 5:19 PM Jan Polensky <japo@linux.ibm.com> wrote: > > thanks for the review. You're welcome! > -Zpacked-stack: I’m not aware of a dedicated rust-lang/rust tracking > issue for this flag. The implementation landed via rust-lang/rust PR > 152432, but it doesn’t appear to reference a tracking issue. Yeah, #152432 is the one I linked in our live list. Sometimes tracking issues are missing, but I think upstream Rust is generally OK adding them -- I have created one, tagged and linked it, please feel free to modify it, close it, etc. if needed: https://github.com/rust-lang/rust/issues/156724 I hope that helps. > minimum toolchain version / beta: as long as we pass -Zpacked-stack in > KBUILD_RUSTFLAGS, we need a nightly compiler; beta/stable won’t accept -Z > flags. In v2 I’ll drop the 1.97.0-nightly guess and set the minimum to > 1.96.0-nightly (the first release line that includes -Zpacked-stack). > We’ll keep the “-nightly” suffix while this remains a -Z flag. If it gets > stabilized and nothing blocks, the earliest stable release that could > plausibly carry it would be 1.98. No, it is meant to work -- we use `-Z` flags (and other unstable features) on a regular basis, as you can see in our issue #2 that I linked above, e.g. you can see some of them with: git grep '\-Z' Makefile Please see: https://rust-for-linux.com/unstable-features for some more details. That is why I was suggesting that you test the current beta, because it will become soon 1.96. If it doesn't, then it would be wise to try to see why it doesn't! :) Thanks! Cheers, Miguel
On Mon, May 18, 2026 at 07:23:09PM +0200, Miguel Ojeda wrote: > On Mon, May 18, 2026 at 5:19 PM Jan Polensky <japo@linux.ibm.com> wrote: > > > > thanks for the review. > > You're welcome! > > > -Zpacked-stack: I’m not aware of a dedicated rust-lang/rust tracking > > issue for this flag. The implementation landed via rust-lang/rust PR > > 152432, but it doesn’t appear to reference a tracking issue. > > Yeah, #152432 is the one I linked in our live list. > > Sometimes tracking issues are missing, but I think upstream Rust is > generally OK adding them -- I have created one, tagged and linked it, > please feel free to modify it, close it, etc. if needed: > > https://github.com/rust-lang/rust/issues/156724 > > I hope that helps. > > > minimum toolchain version / beta: as long as we pass -Zpacked-stack in > > KBUILD_RUSTFLAGS, we need a nightly compiler; beta/stable won’t accept -Z > > flags. In v2 I’ll drop the 1.97.0-nightly guess and set the minimum to > > 1.96.0-nightly (the first release line that includes -Zpacked-stack). > > We’ll keep the “-nightly” suffix while this remains a -Z flag. If it gets > > stabilized and nothing blocks, the earliest stable release that could > > plausibly carry it would be 1.98. > > No, it is meant to work -- we use `-Z` flags (and other unstable > features) on a regular basis, as you can see in our issue #2 that I > linked above, e.g. you can see some of them with: > > git grep '\-Z' Makefile > > Please see: > > https://rust-for-linux.com/unstable-features > > for some more details. > > That is why I was suggesting that you test the current beta, because > it will become soon 1.96. If it doesn't, then it would be wise to try > to see why it doesn't! :) > > Thanks! > > Cheers, > Miguel Hi Miguel, Thanks again for creating the tracking issue for -Zpacked-stack and for all the references, they were very helpful. Regarding the toolchain: since this works with the Rust-for-Linux bootstrap mechanism, I tested with rustc 1.96.0-beta.7 (6be5f81e1 2026-05-17) and everything behaves as expected. I’ll update v2 accordingly (min-tool 1.96.0 without the -nightly suffix, and adjust the wording so it doesn’t imply nightly-only). Best Regards Jan
On Mon, May 18, 2026 at 9:22 PM Jan Polensky <japo@linux.ibm.com> wrote: > > Thanks again for creating the tracking issue for -Zpacked-stack and for > all the references, they were very helpful. > > Regarding the toolchain: since this works with the Rust-for-Linux > bootstrap mechanism, I tested with rustc 1.96.0-beta.7 (6be5f81e1 > 2026-05-17) and everything behaves as expected. I’ll update v2 > accordingly (min-tool 1.96.0 without the -nightly suffix, and adjust the > wording so it doesn’t imply nightly-only). You're welcome, and thanks a lot for testing the beta -- it is good to know it works! Cheers, Miguel
On Mon, May 18, 2026 at 5:19 PM Jan Polensky <japo@linux.ibm.com> wrote: > > On Tue, May 12, 2026 at 02:10:52PM +0200, Miguel Ojeda wrote: > > On Tue, May 12, 2026 at 1:00 PM Jan Polensky <japo@linux.ibm.com> wrote: > > > > > > Signed-off-by: Jan Polensky <japo@linux.ibm.com> > > > > Closes: https://github.com/Rust-for-Linux/linux/issues/106 > > > > I am happy to see IBM getting involved and being able to close a 5 > > year issue! :) > :) > > > > I backlinked there this thread. > > > > > +KBUILD_RUSTFLAGS += --target=s390x-unknown-none-softfloat -Zpacked-stack -Ctarget-feature=+backchain > > > > I added `-Zpacked-stack` and a bunch of related links to: > > > > https://github.com/Rust-for-Linux/linux/issues/2 > > > > Is there a tracking issue for it? I linked > > https://github.com/rust-lang/rust/issues/150259 for the backchain > > feature. > > > > > + if [ "$SRCARCH" = "s390" ]; then > > > + echo 1.97.0-nightly > > > > `-Zpacked-stack` landed for 1.96. Is there something queued for 1.97? > > If not, does the beta work? > > > > Either way, I would prefer waiting until we know the actual version > > number, i.e. without `-nightly`. It is just a few weeks away anyway. > > > > Thanks! > > > > Cheers, > > Miguel > > Hi Miguel, > > thanks for the review. > > -Zpacked-stack: I’m not aware of a dedicated rust-lang/rust tracking > issue for this flag. The implementation landed via rust-lang/rust PR > 152432, but it doesn’t appear to reference a tracking issue. > > backchain: ack, the s390x target-feature tracking issue you linked is the > right umbrella reference. > > minimum toolchain version / beta: as long as we pass -Zpacked-stack in > KBUILD_RUSTFLAGS, we need a nightly compiler; beta/stable won’t accept -Z > flags. In v2 I’ll drop the 1.97.0-nightly guess and set the minimum to > 1.96.0-nightly (the first release line that includes -Zpacked-stack). > We’ll keep the “-nightly” suffix while this remains a -Z flag. If it gets > stabilized and nothing blocks, the earliest stable release that could > plausibly carry it would be 1.98. You should not add a nightly suffix for this reason. If it's available in nightly since 1.96.0, then you just write 1.96.0 here. Linux uses RUSTC_BOOTSTRAP to allow use of such flags on stable compiler builds. Alice
On Mon, May 18, 2026 at 05:30:26PM +0200, Alice Ryhl wrote: > On Mon, May 18, 2026 at 5:19 PM Jan Polensky <japo@linux.ibm.com> wrote: > > > > On Tue, May 12, 2026 at 02:10:52PM +0200, Miguel Ojeda wrote: > > > On Tue, May 12, 2026 at 1:00 PM Jan Polensky <japo@linux.ibm.com> wrote: > > > > > > > > Signed-off-by: Jan Polensky <japo@linux.ibm.com> > > > > > > Closes: https://github.com/Rust-for-Linux/linux/issues/106 > > > > > > I am happy to see IBM getting involved and being able to close a 5 > > > year issue! :) > > :) > > > > > > I backlinked there this thread. > > > > > > > +KBUILD_RUSTFLAGS += --target=s390x-unknown-none-softfloat -Zpacked-stack -Ctarget-feature=+backchain > > > > > > I added `-Zpacked-stack` and a bunch of related links to: > > > > > > https://github.com/Rust-for-Linux/linux/issues/2 > > > > > > Is there a tracking issue for it? I linked > > > https://github.com/rust-lang/rust/issues/150259 for the backchain > > > feature. > > > > > > > + if [ "$SRCARCH" = "s390" ]; then > > > > + echo 1.97.0-nightly > > > > > > `-Zpacked-stack` landed for 1.96. Is there something queued for 1.97? > > > If not, does the beta work? > > > > > > Either way, I would prefer waiting until we know the actual version > > > number, i.e. without `-nightly`. It is just a few weeks away anyway. > > > > > > Thanks! > > > > > > Cheers, > > > Miguel > > > > Hi Miguel, > > > > thanks for the review. > > > > -Zpacked-stack: I’m not aware of a dedicated rust-lang/rust tracking > > issue for this flag. The implementation landed via rust-lang/rust PR > > 152432, but it doesn’t appear to reference a tracking issue. > > > > backchain: ack, the s390x target-feature tracking issue you linked is the > > right umbrella reference. > > > > minimum toolchain version / beta: as long as we pass -Zpacked-stack in > > KBUILD_RUSTFLAGS, we need a nightly compiler; beta/stable won’t accept -Z > > flags. In v2 I’ll drop the 1.97.0-nightly guess and set the minimum to > > 1.96.0-nightly (the first release line that includes -Zpacked-stack). > > We’ll keep the “-nightly” suffix while this remains a -Z flag. If it gets > > stabilized and nothing blocks, the earliest stable release that could > > plausibly carry it would be 1.98. > > You should not add a nightly suffix for this reason. If it's available > in nightly since 1.96.0, then you just write 1.96.0 here. Linux uses > RUSTC_BOOTSTRAP to allow use of such flags on stable compiler builds. > > Alice Hi Alice, thanks for the clarification. `-Zpacked-stack` is currently only available starting with 1.96.0-nightly, which is the last prerequisite for our toolchain and the kernel build. I will set the minimum rustc version to 1.96.0 (without “-nightly”), since the kernel uses RUSTC_BOOTSTRAP to allow `-Z` flags on stable compiler builds. Thanks, Jan
© 2016 - 2026 Red Hat, Inc.