All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Brian Geffon <bgeffon@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Guenter Roeck <groeck@google.com>, Borislav Petkov <bp@suse.de>,
	Andy Lutomirski <luto@kernel.org>,
	stable@vger.kernel.org, the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: XSAVE / RDPKRU on Intel 11th Gen Core CPUs
Date: Mon, 8 Nov 2021 22:49:22 -0800	[thread overview]
Message-ID: <472b8dbf-2c55-98c9-39ad-2db32a649a20@intel.com> (raw)
In-Reply-To: <CADyq12y0o=Y1MOMe7pCghy2ZEV2Y0Dd7jm5e=3o2N4-i088MWw@mail.gmail.com>

On 11/8/21 5:47 PM, Brian Geffon wrote:
>> One more thing...  Does the protection_keys kernel selftest hit any
>> errors on this same setup?  It does a lot of PKRU sanity checking and
>> I'm a bit surprised it hasn't caught something yet.
> Hi Dave,
> 
> This issue does reproduce with the self tests too, my simple test
> program also fails consistently [1], all it does is spin executing
> RDPKRU waiting for a context switch to clobber the value.
> 
> $ ./test
> unexpected value on iteration 3772082 value:0x55555554 expected:0x55555550

Well, gosh, it's making it back to the software init value.  If you do:

	echo 0x15555554 > /sys/kernel/debug/x86/init_pkru

do you end up with 0x15555554 as the value?

The other thing you can try is to turn on all the
/sys/kernel/debug/tracing/events/x86_fpu tracepoints, pin your test
program to one CPU, then dump the trace buffer out for that CPU.  That
probably won't tell us too much for PKRU since it's generally not ever
in its init state.  But, another test would be to use XRSTOR to *get* it
into its init state then see how long it stays there.

Another thing you could do is figure out if pkeys _ever_ worked on that
hardware.  If so, a (long) bisect could figure out what broke it between
its introduction and the 5.13 kernel that you've been testing.
A random 5.11-based distro kernel that I have running on a Cascade Lake
Xeon doesn't seem to have any issues.

Does your system have any more XSAVE support than mine?

> kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
> kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x020: 'AVX-512 opmask'
> kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x040: 'AVX-512 Hi256'
> kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x080: 'AVX-512 ZMM_Hi256'
> kernel: [    0.000000] x86/fpu: Supporting XSAVE feature 0x200: 'Protection Keys User registers'
> kernel: [    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> kernel: [    0.000000] x86/fpu: xstate_offset[5]:  832, xstate_sizes[5]:   64
> kernel: [    0.000000] x86/fpu: xstate_offset[6]:  896, xstate_sizes[6]:  512
> kernel: [    0.000000] x86/fpu: xstate_offset[7]: 1408, xstate_sizes[7]: 1024
> kernel: [    0.000000] x86/fpu: xstate_offset[9]: 2432, xstate_sizes[9]:    8
> kernel: [    0.000000] x86/fpu: Enabled xstate features 0x2e7, context size is 2440 bytes, using 'compacted' format.

  reply	other threads:[~2021-11-09  6:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-08 17:37 XSAVE / RDPKRU on Intel 11th Gen Core CPUs Brian Geffon
2021-11-08 19:37 ` Dave Hansen
2021-11-08 22:00   ` Dave Hansen
2021-11-08 23:20     ` Brian Geffon
2021-11-09  1:47     ` Brian Geffon
2021-11-09  6:49       ` Dave Hansen [this message]
2021-11-09 13:43         ` Brian Geffon
2021-11-09 14:14           ` Brian Geffon
2021-11-09 14:57           ` Andy Lutomirski
2021-11-09 18:58             ` Brian Geffon
2021-11-09 19:25               ` Brian Geffon
2021-11-09 19:29               ` Dave Hansen

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=472b8dbf-2c55-98c9-39ad-2db32a649a20@intel.com \
    --to=dave.hansen@intel.com \
    --cc=bgeffon@google.com \
    --cc=bp@suse.de \
    --cc=groeck@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --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.