[PATCH] x86/build/64: Prevent native builds from generating APX instructions

[PATCH] x86/build/64: Prevent native builds from generating APX instructions

[Chang S. Bae]

Omar reported this broad concern to me, when resolving a separate issue
with his custom module. CONFIG_X86_NATIVE_CPU=y allows builds to
opportunistically emit APX instructions when the build host supports APX
since commit:

  ea1dcca1de12 ("x86/kbuild/64: Add the CONFIG_X86_NATIVE_CPU option to locally optimize the kernel with '-march=native'")

The kernel is not yet prepared to use APX internally. For example, there
is no context-switch support for general in-kernel use of the extended
GPRs.

Explicitly disable APX when building with `-march=native`.

Since GCC 14 and LLVM 18, both compilers support APX. LLVM 19 is already
the minimum version to support native builds from:

  ad9b861824ac ("x86/kbuild/64: Restrict clang versions that can use '-march=native'")

RUST supports APX detection via XCR0 since v1.91 release. While the
support is not official yet, conservatively set that version as the
minimum.

Reported-by: Omar Avelar <omar.avelar@intel.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Cc: <stable@vger.kernel.org> # v6.16+
Cc: Miguel Ojeda <ojeda@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
---
I don't think it is fair to point out that commit to fix here. The issue
looks to be just in a hindsight. It was also merged at the same cycle
when APX userspace enabling was picked up.

Fortunately no APX systems are publicly available yet, but guard against
this before such hardware becomes generally available.
---
 arch/x86/Makefile | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 598f178102ee..256948e65073 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -161,7 +161,15 @@ else
 
 ifdef CONFIG_X86_NATIVE_CPU
         KBUILD_CFLAGS += -march=native
-        KBUILD_RUSTFLAGS += -Ctarget-cpu=native
+        # Do not generate APX instructions as in-kernel use isn't ready
+  ifdef CONFIG_CC_IS_GCC
+        KBUILD_CFLAGS += $(if $(call gcc-min-version,140000),-mno-apxf,)
+  endif
+  ifdef CONFIG_CC_IS_CLANG
+        # The minimum version for native build already supports the option
+        KBUILD_CFLAGS += -mno-apxf
+  endif
+        KBUILD_RUSTFLAGS += -Ctarget-cpu=native $(if $(call rust-min-version,109100),-Ctarget-feature=-apxf,)
 else
         KBUILD_CFLAGS += -march=x86-64 -mtune=generic
         KBUILD_RUSTFLAGS += -Ctarget-cpu=x86-64 -Ztune-cpu=generic
-- 
2.51.0

Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

[Miguel Ojeda]

On Wed, Jul 8, 2026 at 11:40 PM Chang S. Bae <chang.seok.bae@intel.com> wrote:
>
> +        KBUILD_RUSTFLAGS += -Ctarget-cpu=native $(if $(call rust-min-version,109100),-Ctarget-feature=-apxf,)

Hmm... I don't think this was tested?

There is a missing `c` there -- the flag is never going to get passed.

And while it is true that `rustc` knows about the target feature since
1.88.0, it will (sadly) still loudly warn about it:

    warning: unstable feature specified for `-Ctarget-feature`: `apxf`
      |
      = note: this feature is not stably supported; its behavior can
change in the future

Instead, we should be able to do it in the custom target spec, i.e. in
`scripts/generate_rust_target.rs`, assuming `-Ctarget-cpu=native`
enables it and we need to override it. But please double-check the
interaction between those and test that LLVM is actually getting the
right set of features you want.

Finally, we are trying to get rid of the custom target and instead use
flags as soon as possible, so if the flag will be eventually needed,
then it should be stabilized.

To help with that, I have tagged the tracking issue with our Rust for
Linux tag and will raise it to them in our next meeting, but it is
even better if the actual company pings as well:

  https://github.com/rust-lang/rust/issues/139284

I have also added it to our usual live list of features:

  https://github.com/Rust-for-Linux/linux/issues/2

Link: https://github.com/rust-lang/rust/issues/139284
Link: https://github.com/rust-lang/rust/pull/139534

Also Cc'ing rust-for-linux and the maintainers and reviewers.

I hope this helps.

Cheers,
Miguel

Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

[Chang S. Bae]

On 7/9/2026 5:36 AM, Miguel Ojeda wrote:
> On Wed, Jul 8, 2026 at 11:40 PM Chang S. Bae <chang.seok.bae@intel.com> wrote:
>>
>> +        KBUILD_RUSTFLAGS += -Ctarget-cpu=native $(if $(call rust-min-version,109100),-Ctarget-feature=-apxf,)
> 
> Hmm... I don't think this was tested?
> 
> There is a missing `c` there -- the flag is never going to get passed.

Ouch. :(

> 
> And while it is true that `rustc` knows about the target feature since
> 1.88.0, it will (sadly) still loudly warn about it:
> 
>      warning: unstable feature specified for `-Ctarget-feature`: `apxf`
>        |
>        = note: this feature is not stably supported; its behavior can
> change in the future
> 
> Instead, we should be able to do it in the custom target spec, i.e. in
> `scripts/generate_rust_target.rs`, assuming `-Ctarget-cpu=native`
> enables it and we need to override it. But please double-check the
> interaction between those and test that LLVM is actually getting the
> right set of features you want.

I did some investigation [*] into the APX code generation across Rust 
versions. A few notable observations:

  * Rust 1.88 is the first release to recognizes the apxf target feature.
    Prior to that, when LLVM supports APX, target-cpu=native appears to
    allow APX code generation.
  * Starting with Rust 1.95, target-cpu=native no longer appears to
    enable APX instruction generation even without explicitly disabling
    apxf. However, this seems to be implementation-specific and could
    change in future releases.
  * Passing target-feature=-apxf currently emits the warning you quoted
    because the feature is still unstable. Using the generated target
    JSON avoids the warning but Rust versions prior to 1.93 instead
    produce another noise:

    '-apxf' is not a recognized feature for this target ...

Given that, the goal here is to disable APX without build warnings. Rust
1.93 needs to be the minimum version via the generated target JSON.

> 
> Finally, we are trying to get rid of the custom target and instead use
> flags as soon as possible, so if the flag will be eventually needed,
> then it should be stabilized.
> 
> To help with that, I have tagged the tracking issue with our Rust for
> Linux tag and will raise it to them in our next meeting, but it is
> even better if the actual company pings as well:
> 
>    https://github.com/rust-lang/rust/issues/139284
> 
> I have also added it to our usual live list of features:
> 
>    https://github.com/Rust-for-Linux/linux/issues/2
> 
> Link: https://github.com/rust-lang/rust/issues/139284
> Link: https://github.com/rust-lang/rust/pull/139534
> 
> Also Cc'ing rust-for-linux and the maintainers and reviewers.
> 
> I hope this helps.
Indeed. This is very helpful!

Thanks,
Chang

[*]:
https://github.com/intel/apx/blob/study_rust-apxf/study_rust-apxf.md

Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

[Miguel Ojeda]

On Wed, Jul 15, 2026 at 12:15 AM Chang S. Bae <chang.seok.bae@intel.com> wrote:
>
>     JSON avoids the warning but Rust versions prior to 1.93 instead
>     produce another noise:
>
>     '-apxf' is not a recognized feature for this target ...

I think that warning may be coming from LLVM, not Rust, so it may
depend not on the Rust version, but on the LLVM backend being used
(Rust compilers support several major LLVM versions).

So I would recommend double-checking that -- and if so, perhaps you
may need to restrict the LLVM backend version. In case you need them,
we have nowadays e.g.

    CONFIG_RUSTC_LLVM_VERSION
    CONFIG_RUSTC_LLVM_MAJOR_VERSION

Also, from that
https://github.com/intel/apx/blob/study_rust-apxf/study_rust-apxf.md,
I notice you checked object files, which is a good check, but what I
meant is to check the LLVM module attributes in the LLVM IR emitted
from the Rust compiler.

For instance, if I do:

  https://godbolt.org/z/sMaajjYao

I see:

    +egpr,+push2pop2,+ppx,+ndd,+ccmp,+cf,+nf,+zu

being added to the LLVM module attributes when I pass a `+apxf`.

Also, I saw in your file:

  "The generated `rust/core.o` object was selected as the insepction target
    because it appears to represent the core Rust support built into
the kernel."

To clarify, that object file is "just" the standard library. Which is
definitely a good target to inspect, but since you scripted this
anyway, I would suggest checking others. In fact, you could even
inspect all and filter them out by the language DWARF tag. Or perhaps
you can just do it for every single object, since the C ones are
expected to behave the same, no?

I hope that helps!

> Indeed. This is very helpful!

You're welcome!

Cheers,
Miguel

Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

[Chang S. Bae]

Hi Miguel,

First, sorry for my delayed response.

On 7/15/2026 3:30 AM, Miguel Ojeda wrote:
> 
> I think that warning may be coming from LLVM, not Rust, so it may
> depend not on the Rust version, but on the LLVM backend being used
> (Rust compilers support several major LLVM versions).
> 
> So I would recommend double-checking that -- and if so, perhaps you
> may need to restrict the LLVM backend version. In case you need them,
> we have nowadays e.g.
> 
>      CONFIG_RUSTC_LLVM_VERSION
>      CONFIG_RUSTC_LLVM_MAJOR_VERSION

The backend LLVM does not recognize apxf in the target attribute. OTOH, 
Clang appears to translate -mapxf into the backend readables [1]:

   egpr,push2pop2,ppx,ndd,ccmp,nf,cf,zu,jmpabs

Support for the apxf attribute looks to be merged about two weeks ago 
[2], and which is also found in the LLVM 23 RC tree.

Given that one option would be relax the rustc version while tightening 
the backend like:

  Option 1: RUSTC_VERSION >= 108800 && RUSTC_LLVM_MAJOR_VERSION >= 23

Or, simply like the previous:

  Option2: RUSTC_VERSION >= 109301

Since the rustc front does no longer emits the `apxf` attribute starting 
from 1.93. Also, 1.93 requires at least LLVM 21 which already supports APX.

[1] 
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Options/Options.td#L7483
[2] https://github.com/llvm/llvm-project/pull/184078


> Also, from that
> https://github.com/intel/apx/blob/study_rust-apxf/study_rust-apxf.md,
> I notice you checked object files, which is a good check, but what I
> meant is to check the LLVM module attributes in the LLVM IR emitted
> from the Rust compiler.
> 
> For instance, if I do:
> 
>    https://godbolt.org/z/sMaajjYao
> 
> I see:
> 
>      +egpr,+push2pop2,+ppx,+ndd,+ccmp,+cf,+nf,+zu
> 
> being added to the LLVM module attributes when I pass a `+apxf`.

I see. --emit=llvm-ir looks to generate .ll files where target-features= 
is readable. Thanks for the clarification!

> anyway, I would suggest checking others. In fact, you could even
> inspect all and filter them out by the language DWARF tag. Or perhaps
> you can just do it for every single object, since the C ones are
> expected to behave the same, no?
> 

Yeah, I could check obj files running the below for example. Both LLVM 
and GCC builds appear free from EGPR use when with Option 2 above.

$ find . -type f -name "*.o" -print0 | xargs -0 -n 1 ./check_egprs.sh
$ cat check_egprs.sh
   egpr_refs=$(objdump -d --no-show-raw-insn $1 | \
     sed -E 's/^[[:space:]]+[0-9a-fA-F]+:[[:space:]]+//' | \
     grep -E 
'%r16|%r17|%r18|%r19|%r20|%r21|%r22|%r23|%r24|%r25|%r26|%r27|%r28|%r29|%r30|%r31' 
| \
     wc -l)

   if [ $egpr_refs != 0 ] ; then
     echo "Fail: $1, $egpr_refs EGPRs"
   fi

Thanks,
Chang

Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

[Miguel Ojeda]

On Fri, Jul 31, 2026 at 10:46 PM Chang S. Bae <chang.seok.bae@intel.com> wrote:
>
> Given that one option would be relax the rustc version while tightening
> the backend like:
>
>   Option 1: RUSTC_VERSION >= 108800 && RUSTC_LLVM_MAJOR_VERSION >= 23
>
> Or, simply like the previous:
>
>   Option2: RUSTC_VERSION >= 109301
>
> Since the rustc front does no longer emits the `apxf` attribute starting
> from 1.93. Also, 1.93 requires at least LLVM 21 which already supports APX.

Does it mean it could be the "OR" of those two?

i.e. it sounds like we could avoid having to pick one or the other.

Thanks for double-checking that and doing the analysis, I appreciate
it! Figuring out the precise version gates for this sort of thing is
always informative on its own.

Cheers,
Miguel

Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

[Chang S. Bae]

On 7/31/2026 1:57 PM, Miguel Ojeda wrote:
> 
> Does it mean it could be the "OR" of those two?
> 
> i.e. it sounds like we could avoid having to pick one or the other.
Yes, you're right.

Thanks,
Chang

Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

[Nathan Chancellor]

On Wed, Jul 08, 2026 at 09:14:35PM +0000, Chang S. Bae wrote:
> Omar reported this broad concern to me, when resolving a separate issue
> with his custom module. CONFIG_X86_NATIVE_CPU=y allows builds to
> opportunistically emit APX instructions when the build host supports APX
> since commit:
> 
>   ea1dcca1de12 ("x86/kbuild/64: Add the CONFIG_X86_NATIVE_CPU option to locally optimize the kernel with '-march=native'")
> 
> The kernel is not yet prepared to use APX internally. For example, there
> is no context-switch support for general in-kernel use of the extended
> GPRs.
> 
> Explicitly disable APX when building with `-march=native`.
> 
> Since GCC 14 and LLVM 18, both compilers support APX. LLVM 19 is already
> the minimum version to support native builds from:
> 
>   ad9b861824ac ("x86/kbuild/64: Restrict clang versions that can use '-march=native'")
> 
> RUST supports APX detection via XCR0 since v1.91 release. While the
> support is not official yet, conservatively set that version as the
> minimum.
> 
> Reported-by: Omar Avelar <omar.avelar@intel.com>
> Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
> Cc: <stable@vger.kernel.org> # v6.16+
> Cc: Miguel Ojeda <ojeda@kernel.org>
> Cc: Nathan Chancellor <nathan@kernel.org>
> ---

Miguel's comment aside:

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

Some style feedback below.

> ---
>  arch/x86/Makefile | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index 598f178102ee..256948e65073 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -161,7 +161,15 @@ else
>  
>  ifdef CONFIG_X86_NATIVE_CPU
>          KBUILD_CFLAGS += -march=native
> -        KBUILD_RUSTFLAGS += -Ctarget-cpu=native
> +        # Do not generate APX instructions as in-kernel use isn't ready
> +  ifdef CONFIG_CC_IS_GCC
> +        KBUILD_CFLAGS += $(if $(call gcc-min-version,140000),-mno-apxf,)
> +  endif
> +  ifdef CONFIG_CC_IS_CLANG
> +        # The minimum version for native build already supports the option
> +        KBUILD_CFLAGS += -mno-apxf
> +  endif

As the flag is the same between the two compilers, I think it would be
more readable to do something like:

  # Do not generate APX instructions as in-kernel use isn't ready
  # Supported by GCC 14+ and LLVM 18+
  KBUILD_CFLAGS += $(call cc-option,-mno-apxf)

I realize this was probably written to intentionally avoid calling
cc-option but I am not sure it is worth micro-optimizing the build like
this. Another option that avoids the separate blocks and cc-option would
be something like:

  KBUILD_CFLAGS += $(if $(call gcc-min-version,140000)$(CONFIG_CC_IS_CLANG),-mno-apxf)

That said, it is ultimately up to the -tip folks.

> +        KBUILD_RUSTFLAGS += -Ctarget-cpu=native $(if $(call rust-min-version,109100),-Ctarget-feature=-apxf,)

The trailing comma is not necessary for this if, it is implicit.

>  else
>          KBUILD_CFLAGS += -march=x86-64 -mtune=generic
>          KBUILD_RUSTFLAGS += -Ctarget-cpu=x86-64 -Ztune-cpu=generic
> -- 
> 2.51.0
> 

-- 
Cheers,
Nathan

Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions

[David Laight]

On Wed,  8 Jul 2026 21:14:35 +0000
"Chang S. Bae" <chang.seok.bae@intel.com> wrote:

> Omar reported this broad concern to me, when resolving a separate issue
> with his custom module. CONFIG_X86_NATIVE_CPU=y allows builds to
> opportunistically emit APX instructions when the build host supports APX
> since commit:
> 
>   ea1dcca1de12 ("x86/kbuild/64: Add the CONFIG_X86_NATIVE_CPU option to locally optimize the kernel with '-march=native'")
> 
> The kernel is not yet prepared to use APX internally. For example, there
> is no context-switch support for general in-kernel use of the extended
> GPRs.

Isn't this a just a big compiler bug?

Much like when AVX support was added, -march-native needs to check that the
operating system is saving the registers not that the cpu supports them.

I'd have thought that would be true even if the code is actually destined
to be part of a different kernel - the compiler doesn't really know what
the code is being compiler for.

	David