From: Borislav Petkov <bp@suse.de>
To: Yu-cheng Yu <yu-cheng.yu@intel.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.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 v6 01/13] x86/xsaves: Define and use fpu_user_xstate_size
Date: Wed, 11 May 2016 19:20:45 +0200 [thread overview]
Message-ID: <20160511172045.GH2180@pd.tnic> (raw)
In-Reply-To: <f2e6daf2dc48724cc06250002dc01ac6b30339c1.1462914897.git.yu-cheng.yu@intel.com>
On Tue, May 10, 2016 at 04:29:53PM -0700, Yu-cheng Yu wrote:
> The XSAVE area of kernel can be in standard or compacted format;
"The kernel xstate area... "
and can we call it the xstate area as there are a bunch of XSAVE*
insns touching it. The file which deals with it is even called that:
arch/x86/kernel/fpu/xstate.c
> it is always in standard format for user mode. When XSAVES is
> enabled, the kernel uses the compacted format and it is necessary
> to use a separate fpu_user_xstate_size for signal/ptrace frames.
>
> Based on an earlier patch from Fenghua Yu <fenghua.yu@intel.com>
>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> [yu-cheng.yu@intel.com: rebase to current, rename to fpu_user_xstate_size]
> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Maybe I wasn't as clear as I hoped to be. Let me be more specific:
So you either need to do:
---
From: Fenghua
...
Signed-off-by: Fenghua
Signed-off-by: You
...
---
or
---
Based on an earlier patch from Fenghua Yu <fenghua.yu@intel.com>.
Signed-off-by: You
---
with the second variant making you the author implicitly because you're
the sender.
Makes more sense this way?
> ---
> arch/x86/include/asm/fpu/xstate.h | 1 -
> arch/x86/include/asm/processor.h | 1 +
> arch/x86/kernel/fpu/init.c | 5 ++-
> arch/x86/kernel/fpu/signal.c | 27 ++++++++++----
> arch/x86/kernel/fpu/xstate.c | 76 ++++++++++++++++++++++++---------------
> 5 files changed, 73 insertions(+), 37 deletions(-)
...
> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> index b48ef35..dfac87d 100644
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -44,6 +44,13 @@ static unsigned int xstate_sizes[XFEATURE_MAX] = { [ 0 ... XFEATURE_MAX - 1] =
> static unsigned int xstate_comp_offsets[sizeof(xfeatures_mask)*8];
>
> /*
> + * The XSAVE area of kernel can be in standard or compacted format;
"The kernel xstate area... "
> + * it is always in standard format for user mode. This is the user
> + * mode standard format size used for signal and ptrace frames.
> + */
But yes, that's very nice commenting.
> +unsigned int fpu_user_xstate_size;
> +
> +/*
> * Clear all of the X86_FEATURE_* bits that are unavailable
> * when the CPU has no XSAVE support.
> */
...
> @@ -591,7 +598,15 @@ static bool is_supported_xstate_size(unsigned int test_xstate_size)
> static int init_xstate_size(void)
> {
> /* Recompute the context size for enabled features: */
> - unsigned int possible_xstate_size = calculate_xstate_size();
> + unsigned int possible_xstate_size;
> + unsigned int xsave_size;
> +
> + xsave_size = get_xsave_size();
> +
> + if (cpu_has_xsaves)
So next time you submit patches against -tip, please merge them with
tip/master and see if they still build, at least.
During last review I told you to use boot_cpu_has(X86_FEATURE_XSAVES)
because those cpu_has_XXX things are going away and are gone in tip
already.
Please be more careful when incorporating review comments - otherwise it
is waste of both yours and reviewer's time.
Thanks.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
next prev parent reply other threads:[~2016-05-11 17:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-10 23:29 [PATCH v6 00/13] x86/xsaves: Fix XSAVES issues Yu-cheng Yu
2016-05-10 23:29 ` [PATCH v6 01/13] x86/xsaves: Define and use fpu_user_xstate_size Yu-cheng Yu
2016-05-11 17:20 ` Borislav Petkov [this message]
2016-05-11 17:25 ` Yu, Fenghua
2016-05-11 17:32 ` Borislav Petkov
2016-05-12 6:35 ` Ingo Molnar
2016-05-10 23:29 ` [PATCH v6 02/13] x86/xsaves: Rename xstate_size to fpu_kernel_xstate_size to distinguish from fpu_user_xstate_size Yu-cheng Yu
2016-05-10 23:29 ` [PATCH v6 03/13] x86/xsaves: Keep init_fpstate.xsave.header.xfeatures as zero for init optimization Yu-cheng Yu
2016-05-10 23:29 ` [PATCH v6 04/13] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly Yu-cheng Yu
2016-05-10 23:29 ` [PATCH v6 05/13] x86/xsaves: Align xstate components according to CPUID Yu-cheng Yu
2016-05-10 23:29 ` [PATCH v6 06/13] x86/xsaves: Supervisor state component offset Yu-cheng Yu
2016-05-10 23:29 ` [PATCH v6 07/13] x86/xsaves: Fix PTRACE frames for XSAVES Yu-cheng Yu
2016-05-11 14:50 ` Dave Hansen
2016-05-11 15:16 ` Ingo Molnar
2016-05-10 23:30 ` [PATCH v6 08/13] x86/xsaves: Fix XSTATE component offset print out Yu-cheng Yu
2016-05-10 23:30 ` [PATCH v6 09/13] x86/xsaves: Fix xstate_offsets, xstate_sizes for non-extended states Yu-cheng Yu
2016-05-10 23:30 ` [PATCH v6 10/13] x86/xsaves: Fix __fpu_restore_sig() for XSAVES Yu-cheng Yu
2016-05-10 23:30 ` [PATCH v6 11/13] x86/xsaves: When a disabled xstate component offset is requested, return NULL Yu-cheng Yu
2016-05-10 23:30 ` [PATCH v6 12/13] x86/xsaves: Fix fpstate_init() for XRSTORS Yu-cheng Yu
2016-05-10 23:30 ` [PATCH v6 13/13] x86/xsaves: Re-enable XSAVES Yu-cheng Yu
2016-05-11 4:17 ` [PATCH v6 00/13] x86/xsaves: Fix XSAVES issues Borislav Petkov
2016-05-11 20:03 ` Yu-cheng Yu
2016-05-11 20:12 ` Borislav Petkov
2016-05-12 6:41 ` Ingo Molnar
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=20160511172045.GH2180@pd.tnic \
--to=bp@suse.de \
--cc=dave.hansen@linux.intel.com \
--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