linux-kernel - Re: [PATCH] rust: Add PowerPC support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6a4799d9-48fe-410e-acad-fe687edebc7e@kernel.org>
Date: Wed, 4 Feb 2026 18:19:19 +0100
From: "Christophe Leroy (CS GROUP)" <chleroy@...nel.org>
To: Alice Ryhl <aliceryhl@...gle.com>, Link Mauve <linkmauve@...kmauve.fr>
Cc: rust-for-linux@...r.kernel.org, Miguel Ojeda <ojeda@...nel.org>,
 Boqun Feng <boqun@...nel.org>, Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>,
 Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>,
 Jonathan Corbet <corbet@....net>, Madhavan Srinivasan <maddy@...ux.ibm.com>,
 Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>,
 Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.org>,
 Jason Baron <jbaron@...mai.com>, Steven Rostedt <rostedt@...dmis.org>,
 Ard Biesheuvel <ardb@...nel.org>, Nathan Chancellor <nathan@...nel.org>,
 Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
 Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linuxppc-dev@...ts.ozlabs.org, llvm@...ts.linux.dev,
 officialTechflashYT@...il.com, Ash Logan <ash@...quark.com>,
 Roberto Van Eeden <rw-r-r-0644@...tonmail.com>,
 Jonathan Neuschäfer <j.neuschaefer@....net>,
 "Mukesh Kumar Chaurasiya (IBM)" <mkchauras@...il.com>
Subject: Re: [PATCH] rust: Add PowerPC support



Le 04/02/2026 à 11:41, Alice Ryhl a écrit :
> On Wed, Feb 04, 2026 at 04:05:04AM +0100, Link Mauve wrote:
>> 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.
> 
> Super cool!
> 
>> 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.
> 
> Uh oh this seems tricky. How is this not a problem on arm32 too?
> 
> Perhaps we should just be providing __udivdi3() and __umoddi3() in
> general?

We don't want those functions in the kernel as they are sub-optimal and 
unnecessary. Usually the kernel needs can be covered with do_div() or 
other functions in include/asm-generic/div64.h. If we add those 
functions people will start doing divides blindly in the kernel 
forgetting the huge cost a 64 bits divide has on a 32 bits processor.

> 
>> diff --git a/arch/powerpc/include/asm/jump_label.h b/arch/powerpc/include/asm/jump_label.h
>> index d4eaba459a0e..238f0f625a36 100644
>> --- a/arch/powerpc/include/asm/jump_label.h
>> +++ b/arch/powerpc/include/asm/jump_label.h
>> @@ -15,14 +15,18 @@
>>   #define JUMP_ENTRY_TYPE		stringify_in_c(FTR_ENTRY_LONG)
>>   #define JUMP_LABEL_NOP_SIZE	4
>>   
>> +/* This macro is also expanded on the Rust side. */
>> +#define ARCH_STATIC_BRANCH_ASM(key, label)		\
>> +	"1:\n\t"					\
>> +	"nop # arch_static_branch\n\t"			\
>> +	".pushsection __jump_table,  \"aw\"\n\t"	\
>> +	".long 1b - ., " label " - .\n\t"		\
>> +	 JUMP_ENTRY_TYPE key " - .\n\t"			\
>> +	 ".popsection \n\t"
>> +

Would be better split in two with a JUMP_TABLE_ENTRY() macro as other 
architectures and as done by Mukesh in its patch, see 
https://lore.kernel.org/r/20260204042417.83903-1-mkchauras@gmail.com

>>   static __always_inline bool arch_static_branch(struct static_key *key, bool branch)
>>   {
>> -	asm goto("1:\n\t"
>> -		 "nop # arch_static_branch\n\t"
>> -		 ".pushsection __jump_table,  \"aw\"\n\t"
>> -		 ".long 1b - ., %l[l_yes] - .\n\t"
>> -		 JUMP_ENTRY_TYPE "%c0 - .\n\t"
>> -		 ".popsection \n\t"
>> +	asm goto(ARCH_STATIC_BRANCH_ASM("%c0", "%l[l_yes]")
>>   		 : :  "i" (&((char *)key)[branch]) : : l_yes);
> 
> In case this patch takes a long time to land, it may make sense to split
> this part out in a separate patch that can land now.
> 
> Also, consider pre-emptively updating arch_static_branch_jump too. We
> probably need it at some point in the future.
> 
>> diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
>> index 38b3416bb979..0054880ba0ea 100644
>> --- a/scripts/generate_rust_target.rs
>> +++ b/scripts/generate_rust_target.rs
>> @@ -188,6 +188,16 @@ fn main() {
>>           panic!("arm uses the builtin rustc target");
>>       } else if cfg.has("ARM64") {
>>           panic!("arm64 uses the builtin rustc aarch64-unknown-none target");
>> +    } else if cfg.has("PPC32") {
>> +        ts.push("arch", "powerpc");
>> +        ts.push("data-layout", "E-m:e-p:32:32-Fn32-i64:64-n32");
>> +        ts.push("features", "+soft-float");
>> +        ts.push("llvm-target", "powerpc-unknown-eabi");
>> +        if cfg.rustc_version_atleast(1, 91, 0) {
>> +            ts.push("target-pointer-width", 32);
>> +        } else {
>> +            ts.push("target-pointer-width", "32");
>> +        }
> 
> Is there no built-in target we can use? I think we want to avoid adding
> new targets if at all possible.
> 
> Alice