From: Dave Hansen <dave.hansen@linux.intel.com>
To: Borislav Petkov <bp@suse.de>
Cc: Yu-cheng Yu <yu-cheng.yu@intel.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Andy Lutomirski <luto@kernel.org>,
Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>
Subject: Re: [PATCH v5 02/13] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space
Date: Tue, 10 May 2016 10:31:38 -0700 [thread overview]
Message-ID: <57321AFA.3020104@linux.intel.com> (raw)
In-Reply-To: <20160510172657.GF28520@pd.tnic>
On 05/10/2016 10:26 AM, Borislav Petkov wrote:
>> > It's nice to dump out interesting data in dmesg, but I'm curious why you
>> > think it's interesting.
> I think it would be interesting to know what the kernel's idea
> is of user_xstate_size. I know, I know, one can follow the code
> and figure out what it is but one can say the same about a lot of
> other "interesting" data dumped in dmesg. And I'd like to know what
> fpu__init_system_xstate_size_legacy() decided. And so I know how many
> data is shuffled to/from userspace.
>
> And btw, this message needs more "humanization":
>
> [ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
>
> That doesn't tell me anything.
>
> Oh and it can be read out from CPUID too.
That all sounds like great stuff to do in a follow-on patchset after
this XSAVES stuff.
next prev parent reply other threads:[~2016-05-10 17:31 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-09 20:45 [PATCH v5 00/12] x86/xsaves: Fix XSAVES issues Yu-cheng Yu
2016-05-09 20:45 ` [PATCH v5 01/13] x86/xsaves: Define and use user_xstate_size for xstate size in signal context Yu-cheng Yu
2016-05-10 11:04 ` Borislav Petkov
2016-05-10 15:59 ` Yu-cheng Yu
2016-05-10 16:29 ` Borislav Petkov
2016-05-10 16:30 ` Yu-cheng Yu
2016-05-09 20:45 ` [PATCH v5 02/13] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space Yu-cheng Yu
2016-05-10 17:01 ` Borislav Petkov
2016-05-10 17:08 ` Dave Hansen
2016-05-10 17:26 ` Borislav Petkov
2016-05-10 17:31 ` Dave Hansen [this message]
2016-05-09 20:46 ` [PATCH v5 03/13] x86/xsaves: Keep init_fpstate.xsave.header.xfeatures as zero for init optimization Yu-cheng Yu
2016-05-09 20:46 ` [PATCH v5 04/13] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly Yu-cheng Yu
2016-05-09 22:09 ` Dave Hansen
2016-05-09 20:46 ` [PATCH v5 05/13] x86/xsaves: Align xstate components according to CPUID Yu-cheng Yu
2016-05-09 20:46 ` [PATCH v5 06/13] x86/xsaves: Supervisor state component offset Yu-cheng Yu
2016-05-09 20:46 ` [PATCH v5 07/13] x86/xsaves: Fix PTRACE frames for XSAVES Yu-cheng Yu
2016-05-09 20:46 ` [PATCH v5 08/13] x86/xsaves: Fix XSTATE component offset print out Yu-cheng Yu
2016-05-09 20:46 ` [PATCH v5 09/13] x86/xsaves: Fix xstate_offsets, xstate_sizes for non-extended states Yu-cheng Yu
2016-05-09 20:46 ` [PATCH v5 10/13] x86/xsaves: Fix __fpu_restore_sig() for XSAVES Yu-cheng Yu
2016-05-09 23:43 ` Dave Hansen
2016-05-09 20:46 ` [PATCH v5 11/13] x86/xsaves: Add WARN_ON_FPU() when a disabled xstate component offset is requested for a compacted format Yu-cheng Yu
2016-05-09 23:31 ` Dave Hansen
2016-05-09 23:44 ` Yu-cheng Yu
2016-05-09 23:54 ` Dave Hansen
2016-05-09 20:46 ` [PATCH v5 12/13] x86/xsaves: Fix fpstate_init() for XSAVES Yu-cheng Yu
2016-05-09 23:41 ` Dave Hansen
2016-05-09 23:50 ` Yu-cheng Yu
2016-05-10 0:01 ` Dave Hansen
2016-05-09 20:46 ` [PATCH v5 13/13] x86/xsaves: Re-enable XSAVES Yu-cheng Yu
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=57321AFA.3020104@linux.intel.com \
--to=dave.hansen@linux.intel.com \
--cc=bp@suse.de \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=ravi.v.shankar@intel.com \
--cc=sai.praneeth.prakhya@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yu-cheng.yu@intel.com \
/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
Powered by JetHome