From: Nathan Chancellor <nathan@kernel.org>
To: "Chang S. Bae" <chang.seok.bae@intel.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, Omar Avelar <omar.avelar@intel.com>,
stable@vger.kernel.org, Miguel Ojeda <ojeda@kernel.org>
Subject: Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions
Date: Sun, 12 Jul 2026 16:25:38 -0400 [thread overview]
Message-ID: <20260712202538.GA1697833@ax162> (raw)
In-Reply-To: <20260708211435.402426-1-chang.seok.bae@intel.com>
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
prev parent reply other threads:[~2026-07-12 20:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 21:14 [PATCH] x86/build/64: Prevent native builds from generating APX instructions Chang S. Bae
2026-07-09 12:36 ` Miguel Ojeda
2026-07-14 22:15 ` Chang S. Bae
2026-07-15 10:30 ` Miguel Ojeda
2026-07-12 20:25 ` Nathan Chancellor [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260712202538.GA1697833@ax162 \
--to=nathan@kernel.org \
--cc=bp@alien8.de \
--cc=chang.seok.bae@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=ojeda@kernel.org \
--cc=omar.avelar@intel.com \
--cc=stable@vger.kernel.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.