public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: Andrei Vagin <avagin@google.com>
Cc: Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	<linux-kernel@vger.kernel.org>, <criu@lists.linux.dev>,
	<x86@kernel.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH] Revert "x86/fpu: Refine and simplify the magic number check during signal return"
Date: Fri, 1 May 2026 12:13:07 -0700	[thread overview]
Message-ID: <02a4adb3-8829-4681-b170-e3a2f44bf11c@intel.com> (raw)
In-Reply-To: <CAEWA0a5zwHKP51V90A3J960e3o3pdVkSUMYwRJaxiD-fkP-JcQ@mail.gmail.com>

On 5/1/2026 11:44 AM, Andrei Vagin wrote:
> 
> I've been thinking about this more, and I believe the claim that XSAVE
> offsets can differ across CPUs for the same feature is inaccurate. The
> XSAVE standard format uses fixed offsets specifically to allow migration
> between different CPU generations. If a feature exists on both the
> source and destination CPUs, its data resides at the exact same byte
> offset.

There is commit ba386777a30b ("x86/elf: Add a new FPU buffer layout info 
to x86 core files") for this reason:

     ...
     The XSAVE layouts of modern AMD and Intel CPUs differ, especially
     since Memory Protection Keys and the AVX-512 features have been
     inculcated into the AMD CPUs.

     Since AMD never adopted (and hence never left room in the XSAVE
     layout for) the Intel MPX feature, tools like GDB had assumed a
     fixed XSAVE layout matching that of Intel (based on the XCR0 mask).

     Hence, core dumps from AMD CPUs didn't match the known size for the
     XCR0 mask. This resulted in GDB and other tools not being able to
     access the values of the AVX-512 and PKRU registers on AMD CPUs.
     ...

Thanks,
Chang

  reply	other threads:[~2026-05-01 19:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-29  0:06 [PATCH] Revert "x86/fpu: Refine and simplify the magic number check during signal return" Andrei Vagin
2026-04-29  7:26 ` Chang S. Bae
2026-04-29 16:44   ` Andrei Vagin
2026-04-29 17:15     ` Chang S. Bae
2026-04-29 20:44       ` Andrei Vagin
2026-04-29 21:44         ` Chang S. Bae
2026-04-30  0:28           ` Andrei Vagin
2026-05-01 18:44   ` Andrei Vagin
2026-05-01 19:13     ` Chang S. Bae [this message]
2026-05-01 20:50       ` Andrei Vagin
2026-05-01 21:04         ` Chang S. Bae
2026-05-01 21:42           ` Andrei Vagin
2026-05-02 19:23             ` Chang S. Bae

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=02a4adb3-8829-4681-b170-e3a2f44bf11c@intel.com \
    --to=chang.seok.bae@intel.com \
    --cc=avagin@google.com \
    --cc=bp@alien8.de \
    --cc=criu@lists.linux.dev \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.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