From: David Laight <david.laight.linux@gmail.com>
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>,
Nathan Chancellor <nathan@kernel.org>
Subject: Re: [PATCH] x86/build/64: Prevent native builds from generating APX instructions
Date: Sat, 1 Aug 2026 12:44:29 +0100 [thread overview]
Message-ID: <20260801124429.45d03af7@pumpkin> (raw)
In-Reply-To: <20260708211435.402426-1-chang.seok.bae@intel.com>
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
prev parent reply other threads:[~2026-08-01 11:44 UTC|newest]
Thread overview: 9+ 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-31 20:46 ` Chang S. Bae
2026-07-31 20:57 ` Miguel Ojeda
2026-07-31 21:15 ` Chang S. Bae
2026-07-12 20:25 ` Nathan Chancellor
2026-08-01 11:44 ` David Laight [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=20260801124429.45d03af7@pumpkin \
--to=david.laight.linux@gmail.com \
--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=nathan@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox