[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160512064130.GB29495@gmail.com>
Date: Thu, 12 May 2016 08:41:30 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Yu-cheng Yu <yu-cheng.yu@...el.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Borislav Petkov <bp@...e.de>,
Sai Praneeth Prakhya <sai.praneeth.prakhya@...el.com>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>
Subject: Re: [PATCH v6 00/13] x86/xsaves: Fix XSAVES issues
* Yu-cheng Yu <yu-cheng.yu@...el.com> wrote:
> XSAVES is a kernel-mode instruction. It offers a compacted format and
> memory-write optimization. These patches fix issues in the first
> implementation.
>
> Changes since Version 5:
>
> Patch 1, 2 - Change names to fpu_user_xstate_size and fpu_kernel_xstate_size;
> fix some comments, etc.
>
> Patch 11 - In addition to a warning, make __raw_xsave_addr() return NULL
> when a disabled xstate component address is requested.
>
> Patch 12 - Add more details in the comments of why this patch is needed;
> make a new macro for xcomp_bv[63].
>
> Yu-cheng Yu (13):
> x86/xsaves: Define and use fpu_user_xstate_size
So if you look at the git log of arch/x86/kernel/fpu/ then you'll see that the
standard tag for FPU code is 'x86/fpu: ', for purely xstate related patch it's
'x86/fpu/xstate: '.
> x86/xsaves: Rename xstate_size to fpu_kernel_xstate_size to distinguish from fpu_user_xstate_size
> x86/xsaves: Keep init_fpstate.xsave.header.xfeatures as zero for init optimization
> x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly
> x86/xsaves: Align xstate components according to CPUID
> x86/xsaves: Supervisor state component offset
Please start all commit titles with verbs.
Also, this series is clearly too big. I was under the impression that the series
was ready, but there's a number of small details that were pointed out (none of
them very serious) - so how about you send a series of the first 4 patches next
time around, and only send another 4 once those 4 first patches get applied to
x86/fpu?
This makes it much easier to review, which reduces reviewer frustration; and it
also allows you to focus more on incorporating feedback, without having to juggle
13 patches all the time.
Ok?
Thanks,
Ingo
Powered by blists - more mailing lists