[PATCH 0/4] s390: enable Rust support and add required arch glue

[PATCH 0/4] s390: enable Rust support and add required arch glue

[Jan Polensky]

Rust support on s390 requires a small set of architecture-specific pieces
before the generic Rust kernel infrastructure can be used.

The series wires up s390 as a Rust-capable 64-bit architecture, adds the
missing assembly interfaces needed by Rust for WARN/BUG reporting and for
static branches, and adjusts bindgen parameters to avoid repr layout
conflicts caused by packed and aligned s390 structures.

s390 currently requires a nightly rustc due to -Zpacked-stack, and the
minimum tool version gating is adjusted accordingly.

Jan Polensky (4):
  s390/bug: Provide ARCH_WARN_ASM for Rust WARN/BUG support
  s390/jump_label: Implement ARCH_STATIC_BRANCH_JUMP_ASM and
    ARCH_STATIC_BRANCH_ASM macros
  rust/bindgen_parameters: Mark s390 types as opaque to prevent repr
    conflicts
  s390: enable Rust support

 Documentation/rust/arch-support.rst |  1 +
 arch/s390/Kconfig                   |  1 +
 arch/s390/Makefile                  | 28 ++++++++++++++----------
 arch/s390/include/asm/bug.h         | 12 +++++++++++
 arch/s390/include/asm/jump_label.h  | 33 +++++++++++++++++------------
 rust/Makefile                       |  1 +
 rust/bindgen_parameters             |  7 ++++++
 scripts/generate_rust_target.rs     |  2 ++
 scripts/min-tool-version.sh         |  6 +++++-
 9 files changed, 65 insertions(+), 26 deletions(-)


base-commit: 50897c955902c93ae71c38698abb910525ebdc89
--
2.51.0

[PATCH 1/4] s390/bug: Provide ARCH_WARN_ASM for Rust WARN/BUG support

[Jan Polensky]

Rust WARN and BUG support relies on ARCH_WARN_ASM to emit __bug_table
entries. On s390 the macro is missing, so Rust code cannot generate
proper WARN/BUG metadata for the kernel's bug reporting infrastructure.

Define ARCH_WARN_ASM to produce the same assembly sequence and
__bug_table entry format as the existing s390 BUG handling, including
the monitor call. Define ARCH_WARN_REACHABLE as empty since s390 does
not provide reachability analysis for warning paths.

Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
 arch/s390/include/asm/bug.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/s390/include/asm/bug.h b/arch/s390/include/asm/bug.h
index 59017fd3d935..baaf5d571785 100644
--- a/arch/s390/include/asm/bug.h
+++ b/arch/s390/include/asm/bug.h
@@ -4,6 +4,7 @@
 
 #include <linux/compiler.h>
 #include <linux/const.h>
+#include <linux/stringify.h>
 
 #define	MONCODE_BUG	_AC(0, U)
 #define	MONCODE_BUG_ARG _AC(1, U)
@@ -121,6 +122,17 @@ do {									\
 #define HAVE_ARCH_BUG_FORMAT
 #define HAVE_ARCH_BUG_FORMAT_ARGS
 
+#define ARCH_WARN_ASM(file, line, flags, size)				\
+	".section .rodata.str,\"aMS\",@progbits,1\n"			\
+	"9:\n"								\
+	".asciz \"\"\n"		/* Empty string for compatibility */	\
+	".previous\n"							\
+	"0:\n"								\
+	__stringify(mc MONCODE_BUG(%r0),0) "\n"				\
+	__BUG_ENTRY("9b", file, line, flags, size)
+
+#define ARCH_WARN_REACHABLE
+
 #endif /* CONFIG_BUG && CONFIG_CC_HAS_ASM_IMMEDIATE_STRINGS */
 #endif /* __ASSEMBLER__ */
 
-- 
2.51.0

[PATCH 2/4] s390/jump_label: Implement ARCH_STATIC_BRANCH_JUMP_ASM and ARCH_STATIC_BRANCH_ASM macros

[Jan Polensky]

Rust static branch support needs the s390 jump label instruction sequence
and __jump_table emission in a reusable form. The current implementation
embeds the sequence directly in the C asm goto blocks, which cannot be
shared with Rust.

Introduce ARCH_STATIC_BRANCH_ASM and ARCH_STATIC_BRANCH_JUMP_ASM to
describe the brcl sequences for the likely-false and likely-true cases
and to emit the same __jump_table entries as before. Switch the existing
C helpers to use the new macros to avoid duplication without changing
the generated code.

Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
 arch/s390/include/asm/jump_label.h | 33 +++++++++++++++++-------------
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/arch/s390/include/asm/jump_label.h b/arch/s390/include/asm/jump_label.h
index d9cbc18f6b2e..1f0114150786 100644
--- a/arch/s390/include/asm/jump_label.h
+++ b/arch/s390/include/asm/jump_label.h
@@ -23,15 +23,25 @@
  * We use a brcl 0,<offset> instruction for jump labels so it
  * can be easily distinguished from a hotpatch generated instruction.
  */
+#define ARCH_JUMP_TABLE_ENTRY(key, label, local_label)	\
+	".pushsection __jump_table,\"aw\"\n"		\
+	".balign	8\n"				\
+	".long	" local_label "-.," label "-.\n"	\
+	".quad	" key "-.\n"				\
+	".popsection\n"
+
+#define ARCH_STATIC_BRANCH_ASM(key, label)	\
+	"0:	brcl 0," label "\n"		\
+	ARCH_JUMP_TABLE_ENTRY(key, label, "0b")
+
+#define ARCH_STATIC_BRANCH_JUMP_ASM(key, label)	\
+	"0:	brcl 15," label "\n"		\
+	ARCH_JUMP_TABLE_ENTRY(key, label, "0b")
+
 static __always_inline bool arch_static_branch(struct static_key *key, bool branch)
 {
-	asm goto("0:	brcl 0,%l[label]\n"
-			  ".pushsection __jump_table,\"aw\"\n"
-			  ".balign	8\n"
-			  ".long	0b-.,%l[label]-.\n"
-			  ".quad	%0+%1-.\n"
-			  ".popsection\n"
-			  : : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
+	asm goto(ARCH_STATIC_BRANCH_ASM("%0+%1", "%l[label]")
+		: : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
 	return false;
 label:
 	return true;
@@ -39,13 +49,8 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran
 
 static __always_inline bool arch_static_branch_jump(struct static_key *key, bool branch)
 {
-	asm goto("0:	brcl 15,%l[label]\n"
-			  ".pushsection __jump_table,\"aw\"\n"
-			  ".balign	8\n"
-			  ".long	0b-.,%l[label]-.\n"
-			  ".quad	%0+%1-.\n"
-			  ".popsection\n"
-			  : : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
+	asm goto(ARCH_STATIC_BRANCH_JUMP_ASM("%0+%1", "%l[label]")
+		: : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
 	return false;
 label:
 	return true;
-- 
2.51.0

Re: [PATCH 2/4] s390/jump_label: Implement ARCH_STATIC_BRANCH_JUMP_ASM and ARCH_STATIC_BRANCH_ASM macros

[Gary Guo]

On Tue May 12, 2026 at 11:59 AM BST, Jan Polensky wrote:
> Rust static branch support needs the s390 jump label instruction sequence
> and __jump_table emission in a reusable form. The current implementation
> embeds the sequence directly in the C asm goto blocks, which cannot be
> shared with Rust.
>
> Introduce ARCH_STATIC_BRANCH_ASM and ARCH_STATIC_BRANCH_JUMP_ASM to
> describe the brcl sequences for the likely-false and likely-true cases
> and to emit the same __jump_table entries as before. Switch the existing
> C helpers to use the new macros to avoid duplication without changing
> the generated code.
>
> Signed-off-by: Jan Polensky <japo@linux.ibm.com>
> ---
>  arch/s390/include/asm/jump_label.h | 33 +++++++++++++++++-------------
>  1 file changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/arch/s390/include/asm/jump_label.h b/arch/s390/include/asm/jump_label.h
> index d9cbc18f6b2e..1f0114150786 100644
> --- a/arch/s390/include/asm/jump_label.h
> +++ b/arch/s390/include/asm/jump_label.h
> @@ -23,15 +23,25 @@
>   * We use a brcl 0,<offset> instruction for jump labels so it
>   * can be easily distinguished from a hotpatch generated instruction.
>   */

The comment looks out of place now, you probably want to move
ARCH_JUMP_TABLE_ENTRY above it.

Best,
Gary

> +#define ARCH_JUMP_TABLE_ENTRY(key, label, local_label)	\
> +	".pushsection __jump_table,\"aw\"\n"		\
> +	".balign	8\n"				\
> +	".long	" local_label "-.," label "-.\n"	\
> +	".quad	" key "-.\n"				\
> +	".popsection\n"
> +
> +#define ARCH_STATIC_BRANCH_ASM(key, label)	\
> +	"0:	brcl 0," label "\n"		\
> +	ARCH_JUMP_TABLE_ENTRY(key, label, "0b")
> +
> +#define ARCH_STATIC_BRANCH_JUMP_ASM(key, label)	\
> +	"0:	brcl 15," label "\n"		\
> +	ARCH_JUMP_TABLE_ENTRY(key, label, "0b")
> +
>  static __always_inline bool arch_static_branch(struct static_key *key, bool branch)
>  {
> -	asm goto("0:	brcl 0,%l[label]\n"
> -			  ".pushsection __jump_table,\"aw\"\n"
> -			  ".balign	8\n"
> -			  ".long	0b-.,%l[label]-.\n"
> -			  ".quad	%0+%1-.\n"
> -			  ".popsection\n"
> -			  : : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
> +	asm goto(ARCH_STATIC_BRANCH_ASM("%0+%1", "%l[label]")
> +		: : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
>  	return false;
>  label:
>  	return true;
> @@ -39,13 +49,8 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran
>  
>  static __always_inline bool arch_static_branch_jump(struct static_key *key, bool branch)
>  {
> -	asm goto("0:	brcl 15,%l[label]\n"
> -			  ".pushsection __jump_table,\"aw\"\n"
> -			  ".balign	8\n"
> -			  ".long	0b-.,%l[label]-.\n"
> -			  ".quad	%0+%1-.\n"
> -			  ".popsection\n"
> -			  : : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
> +	asm goto(ARCH_STATIC_BRANCH_JUMP_ASM("%0+%1", "%l[label]")
> +		: : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
>  	return false;
>  label:
>  	return true;

Re: [PATCH 2/4] s390/jump_label: Implement ARCH_STATIC_BRANCH_JUMP_ASM and ARCH_STATIC_BRANCH_ASM macros

[Jan Polensky]

On Tue, May 12, 2026 at 03:21:42PM +0100, Gary Guo wrote:
> On Tue May 12, 2026 at 11:59 AM BST, Jan Polensky wrote:
> > Rust static branch support needs the s390 jump label instruction sequence
> > and __jump_table emission in a reusable form. The current implementation
> > embeds the sequence directly in the C asm goto blocks, which cannot be
> > shared with Rust.
> >
> > Introduce ARCH_STATIC_BRANCH_ASM and ARCH_STATIC_BRANCH_JUMP_ASM to
> > describe the brcl sequences for the likely-false and likely-true cases
> > and to emit the same __jump_table entries as before. Switch the existing
> > C helpers to use the new macros to avoid duplication without changing
> > the generated code.
> >
> > Signed-off-by: Jan Polensky <japo@linux.ibm.com>
> > ---
> >  arch/s390/include/asm/jump_label.h | 33 +++++++++++++++++-------------
> >  1 file changed, 19 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/s390/include/asm/jump_label.h b/arch/s390/include/asm/jump_label.h
> > index d9cbc18f6b2e..1f0114150786 100644
> > --- a/arch/s390/include/asm/jump_label.h
> > +++ b/arch/s390/include/asm/jump_label.h
> > @@ -23,15 +23,25 @@
> >   * We use a brcl 0,<offset> instruction for jump labels so it
> >   * can be easily distinguished from a hotpatch generated instruction.
> >   */
>
> The comment looks out of place now, you probably want to move
> ARCH_JUMP_TABLE_ENTRY above it.
>
> Best,
> Gary
>
Hi Gary,

good catch, thanks. I’ll move ARCH_JUMP_TABLE_ENTRY above the comment.

Best Regards
Jan
> > +#define ARCH_JUMP_TABLE_ENTRY(key, label, local_label)	\
> > +	".pushsection __jump_table,\"aw\"\n"		\
> > +	".balign	8\n"				\
> > +	".long	" local_label "-.," label "-.\n"	\
> > +	".quad	" key "-.\n"				\
> > +	".popsection\n"
> > +
> > +#define ARCH_STATIC_BRANCH_ASM(key, label)	\
> > +	"0:	brcl 0," label "\n"		\
> > +	ARCH_JUMP_TABLE_ENTRY(key, label, "0b")
> > +
> > +#define ARCH_STATIC_BRANCH_JUMP_ASM(key, label)	\
> > +	"0:	brcl 15," label "\n"		\
> > +	ARCH_JUMP_TABLE_ENTRY(key, label, "0b")
> > +
> >  static __always_inline bool arch_static_branch(struct static_key *key, bool branch)
> >  {
> > -	asm goto("0:	brcl 0,%l[label]\n"
> > -			  ".pushsection __jump_table,\"aw\"\n"
> > -			  ".balign	8\n"
> > -			  ".long	0b-.,%l[label]-.\n"
> > -			  ".quad	%0+%1-.\n"
> > -			  ".popsection\n"
> > -			  : : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
> > +	asm goto(ARCH_STATIC_BRANCH_ASM("%0+%1", "%l[label]")
> > +		: : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
> >  	return false;
> >  label:
> >  	return true;
> > @@ -39,13 +49,8 @@ static __always_inline bool arch_static_branch(struct static_key *key, bool bran
> >
> >  static __always_inline bool arch_static_branch_jump(struct static_key *key, bool branch)
> >  {
> > -	asm goto("0:	brcl 15,%l[label]\n"
> > -			  ".pushsection __jump_table,\"aw\"\n"
> > -			  ".balign	8\n"
> > -			  ".long	0b-.,%l[label]-.\n"
> > -			  ".quad	%0+%1-.\n"
> > -			  ".popsection\n"
> > -			  : : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
> > +	asm goto(ARCH_STATIC_BRANCH_JUMP_ASM("%0+%1", "%l[label]")
> > +		: : JUMP_LABEL_STATIC_KEY_CONSTRAINT (key), "i" (branch) : : label);
> >  	return false;
> >  label:
> >  	return true;
>

[PATCH 3/4] rust/bindgen_parameters: Mark s390 types as opaque to prevent repr conflicts

[Jan Polensky]

Bindgen attempts to generate Rust layouts for a number of s390 structs
that are packed but contain, or transitively contain, aligned fields.
Rust rejects such layouts with E0588 ("packed type cannot transitively
contain a #[repr(align)] type").

Add the affected s390 types to the opaque type list so bindgen emits
opaque blob types instead of full representations. This matches existing
workarounds for x86 types such as alt_instr and x86_msi_data.

References: https://lore.kernel.org/all/e5c7aa10-590d-0d20-dd3b-385bee2377e7@intel.com/
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
 rust/bindgen_parameters | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/rust/bindgen_parameters b/rust/bindgen_parameters
index 6f02d9720ad2..8402b0c93545 100644
--- a/rust/bindgen_parameters
+++ b/rust/bindgen_parameters
@@ -14,6 +14,13 @@
 --opaque-type alt_instr
 --opaque-type x86_msi_data
 --opaque-type x86_msi_addr_lo
+# s390-only: same packed/align issue as above (E0588).
+--opaque-type lowcore
+--opaque-type tod_clock
+--opaque-type tpi_info
+--opaque-type uv_cb.*
+--opaque-type uv_secret.*
+--opaque-type zpci_fib
 
 # If SMP is disabled, `arch_spinlock_t` is defined as a ZST which triggers a Rust
 # warning. We don't need to peek into it anyway.
-- 
2.51.0

Re: [PATCH 3/4] rust/bindgen_parameters: Mark s390 types as opaque to prevent repr conflicts

[Gary Guo]

On Tue May 12, 2026 at 11:59 AM BST, Jan Polensky wrote:
> Bindgen attempts to generate Rust layouts for a number of s390 structs
> that are packed but contain, or transitively contain, aligned fields.
> Rust rejects such layouts with E0588 ("packed type cannot transitively
> contain a #[repr(align)] type").
> 
> Add the affected s390 types to the opaque type list so bindgen emits
> opaque blob types instead of full representations. This matches existing
> workarounds for x86 types such as alt_instr and x86_msi_data.
> 
> References: https://lore.kernel.org/all/e5c7aa10-590d-0d20-dd3b-385bee2377e7@intel.com/
> Signed-off-by: Jan Polensky <japo@linux.ibm.com>

Reviewed-by: Gary Guo <gary@garyguo.net>

> ---
>  rust/bindgen_parameters | 7 +++++++
>  1 file changed, 7 insertions(+)

[PATCH 4/4] s390: enable Rust support

[Jan Polensky]

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

Re: [PATCH 4/4] s390: enable Rust support

[Miguel Ojeda]

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

Re: [PATCH 4/4] s390: enable Rust support

[Jan Polensky]

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

Re: [PATCH 4/4] s390: enable Rust support

[Alice Ryhl]

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

Re: [PATCH 4/4] s390: enable Rust support

[Jan Polensky]

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

Re: [PATCH 4/4] s390: enable Rust support

[Miguel Ojeda]

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

Re: [PATCH 4/4] s390: enable Rust support

[Jan Polensky]

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

Re: [PATCH 4/4] s390: enable Rust support

[Miguel Ojeda]

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