On Fri, Aug 29, 2014 at 11:17 AM, Oleg Nesterov wrote:
> ONCE AGAIN, THIS IS MORE THE QUESTION THAN THE PATCH.
this patch I think needs more thought for sure. please see below.
>
> interrupted_kernel_fpu_idle() does:
>
> if (use_eager_fpu())
> return true;
>
> ret
On Fri, Aug 29, 2014 at 11:16 AM, Oleg Nesterov wrote:
> interrupted_kernel_fpu_idle() tries to detect if kernel_fpu_begin()
> is safe or not. In particulat it should obviously deny the nested
> kernel_fpu_begin() and this logic doesn't look clean.
>
> If use_eager_fpu() == T we rely on a) __threa
|1 -
> 4 files changed, 10 insertions(+), 11 deletions(-)
These 4 patches also look good to me.
Reviewed-by: Suresh Siddha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
if (use_eager_fpu()) {
> + preempt_disable();
> math_state_restore();
> + preempt_enable();
> + }
>
> return err;
> } else {
>
oops. looks good to me.
Reviewed-by: Suresh Siddha
--
To uns
Commit-ID: 731bd6a93a6e9172094a2322bd0ee964bb1f4d63
Gitweb: http://git.kernel.org/tip/731bd6a93a6e9172094a2322bd0ee964bb1f4d63
Author: Suresh Siddha
AuthorDate: Sun, 2 Feb 2014 22:56:23 -0800
Committer: H. Peter Anvin
CommitDate: Tue, 11 Mar 2014 12:32:52 -0700
x86, fpu: Check
On Fri, Mar 7, 2014 at 3:18 PM, H. Peter Anvin wrote:
>
> Hi Suresh,
>
> Any thoughts on this?
hi Peter,
Can you please pickup the second short patch
(https://lkml.org/lkml/2014/2/3/21) which actually fixes the reported
problem at hand. And tested and acked by all the problem reporters.
I will
On Mon, 2014-02-03 at 10:20 -0800, Linus Torvalds wrote:
> Thinking about it some more, this patch is *almost* not needed at all.
>
> I'm wondering if you should just change the first patch to just always
> initialize the fpu when it is allocated, and at execve() time (ie in
> flush_thread()).
>
On Sun, 2014-02-02 at 11:15 -0800, Linus Torvalds wrote:
> On Sat, Feb 1, 2014 at 11:19 PM, Suresh Siddha wrote:
> >
> > The real fix for Nate's problem will be coming from Linus, with a
> > slightly modified option-b that Linus proposed. Linus, please let me
> > k
On Sat, 2014-02-01 at 17:06 -0800, Suresh Siddha wrote:
> Meanwhile I have the patch removing the delayed dynamic allocation for
> non-eager fpu. will post it after some testing.
Appended the patch for this. Tested for last 4-5 hours on my laptop.
The real fix for Nate's problem wil
On Sat, Feb 1, 2014 at 5:51 PM, Linus Torvalds
wrote:
> On Sat, Feb 1, 2014 at 5:47 PM, Suresh Siddha wrote:
>>
>> So if the restore failed, we should do something like drop_init_fpu(),
>> which will restore init-state to the registers.
>>
>> for eager-fpu() pat
On Sat, Feb 1, 2014 at 5:38 PM, Linus Torvalds
wrote:
> It definitely does not want an else, I think.
>
> If tsk_used_math() is false, or if the FPU restore failed, we
> *definitely* need that stts(). Otherwise we'd return to user mode with
> random contents in the FP state, and let user mode muck
On Sat, Feb 1, 2014 at 5:26 PM, H. Peter Anvin wrote:
> Even "b" does that, no?
oh right. It needs an else. only for non-eager fpu case we should do stts()
void __kernel_fpu_end(void)
{
if (use_eager_fpu()) {
struct task_struct *me = current;
if
On Sat, Feb 1, 2014 at 11:27 AM, Linus Torvalds
wrote:
> That said, regardless of the allocation issue, I do think that it's
> stupid for kernel_fpu_{begin,end} to save the math state if
> "used_math" was not set. So I do think__kernel_fpu_end() as-s is
> buggy and stupid.
For eager_fpu case, as
hi,
On Thu, Jan 30, 2014 at 2:24 PM, Linus Torvalds
wrote:
> I'm adding in some people here, because I think in the end this bug
> was introduced by commit 304bceda6a18 ("x86, fpu: use non-lazy fpu
> restore for processors supporting xsave") that introduced that
> math_state_restore() in kernel_f
Commit-ID: 29c574c0aba8dc0736e19eb9b24aad28cc5c9098
Gitweb: http://git.kernel.org/tip/29c574c0aba8dc0736e19eb9b24aad28cc5c9098
Author: Suresh Siddha
AuthorDate: Mon, 26 Nov 2012 14:49:36 -0800
Committer: H. Peter Anvin
CommitDate: Mon, 26 Nov 2012 15:43:25 -0800
x86, apic: Cleanup cfg
Had this cleanup patch (tested before by me and Boris aswell) for a
while. Forgot to post this earlier. Thanks.
---8<---
From: Suresh Siddha
Subject: x86, apic: cleanup cfg->domain setup for legacy interrupts
Issues that need to be handled:
* Handle PIC interrupts on any CPU irrespective
Commit-ID: 279f1461432ccdec0b98c0bcbe0a8e2c0f6fdda5
Gitweb: http://git.kernel.org/tip/279f1461432ccdec0b98c0bcbe0a8e2c0f6fdda5
Author: Suresh Siddha
AuthorDate: Mon, 22 Oct 2012 14:37:58 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 2 Nov 2012 11:23:37 +0100
x86: apic: Use tsc
On Tue, 2012-10-30 at 00:15 +0800, Chuansheng Liu wrote:
> Not all irq chips are IO-APIC chip.
>
> In our system, there are many demux GPIO interrupts except for the
> io-apic chip interrupts, and these GPIO interrupts are belonged
> to other irq chips, the chip data is not type of struct irq_cfg
On Wed, 2012-10-24 at 12:41 -0700, Jonathan Nieder wrote:
> Suresh Siddha wrote:
> > On Wed, 2012-10-24 at 11:25 -0700, Jonathan Nieder wrote:
>
> >> Why not cherry-pick 7716a5c4ff5 in full?
> >
> > As that depends on the other commits like:
> > commit 4
On Wed, 2012-10-24 at 11:25 -0700, Jonathan Nieder wrote:
> Hi Suresh,
>
> Suresh Siddha wrote:
>
> [...]
> > This problem doesn't happen with more recent kernels and closer
> > look at the 2.6.32 kernel shows that the code which masks
> > the IO-APIC R
n
Date: Tue Mar 30 01:07:12 2010 -0700
x86, ioapic: Move nr_ioapic_registers calculation to mp_register_ioapic.
Reported-and-tested-by: Zhang, Lin-Bao
Signed-off-by: Suresh Siddha
Cc: sta...@vger.kernel.org [v2.6.32..v2.6.34]
---
arch/x86/kernel/apic/io_apic.c |9 +++--
1 files ch
Thomas, You wanted to run some tests with this, right? Please give it a
try and see if this is ok to be pushed to the -tip.
thanks,
suresh
--8<--
From: Suresh Siddha
Subject: x86, apic: use tsc deadline for oneshot when available
If the TSC deadline mode is supported, LAPIC timer one-shot m
On Fri, 2012-10-19 at 16:36 -0700, H. Peter Anvin wrote:
> On 10/19/2012 04:32 PM, Yinghai Lu wrote:
> > On Fri, Oct 19, 2012 at 4:03 PM, Suresh Siddha
> > wrote:
> >> On Fri, 2012-10-19 at 13:42 -0700, rrl...@gmail.com wrote:
> >>> Any update? The messages jus
mostly the case if the bios has not exported interrupt-remapping tables to
the
OS).
Reported-by: Berck E. Nash
Signed-off-by: Yinghai Lu
Link:
http://lkml.kernel.org/r/20111222014632.600418...@sbsiddha-desk.sc.intel.com
Signed-off-by: Suresh Siddha
Signed-of
On Wed, 2012-10-10 at 00:26 +, Zhang, Lin-Bao (Linux Kernel R&D)
wrote:
> So , we can think ,as your patch , during the window , IO-apic is
> useless or we can think IO-APIC doesn't exist ?
> Could you mind please sharing your design details ? thanks very much!
Between the window of interru
On Wed, 2012-10-10 at 16:02 -0700, Zhang, Lin-Bao (Linux Kernel R&D)
wrote:
> > As I mentioned earlier, the current design already ensures that all the
> > IO-APIC
> > RTE's are masked between the time we enable interrupt-remapping to the time
> > when the IO-APIC RTE's are configured correctly.
>
On Sun, 2012-10-07 at 21:53 -0700, Zhang, Lin-Bao (Linux Kernel R&D)
wrote:
> Hi Suresh,
> Could you please update current status about these 2 files and patch?
> I am not sure if I have answered your questions , if not ,feel free to let me
> know.
> This is my first time to submit patch to LKML,
On Fri, 2012-09-28 at 00:12 +0530, Srivatsa S. Bhat wrote:
> On 09/27/2012 04:16 AM, Suresh Siddha wrote:
> >
> > No. irq_set_affinity()
> >
>
> Um? That takes the updated/changed affinity and sets data->affinity to
> that value no? You mentioned that proba
On Wed, 2012-09-26 at 23:00 +0530, Srivatsa S. Bhat wrote:
> On 09/26/2012 10:36 PM, Suresh Siddha wrote:
> > On Wed, 2012-09-26 at 21:33 +0530, Srivatsa S. Bhat wrote:
> >> I have some fundamental questions here:
> >> 1. Why was the CPU never removed from the aff
On Wed, 2012-09-26 at 21:33 +0530, Srivatsa S. Bhat wrote:
> I have some fundamental questions here:
> 1. Why was the CPU never removed from the affinity masks in the original
> code? I find it hard to believe that it was just an oversight, because the
> whole point of fixup_irqs() is to affine the
On Mon, 2012-09-24 at 12:12 -0700, Linus Torvalds wrote:
> On Mon, Sep 24, 2012 at 11:26 AM, Mike Galbraith wrote:
> >
> > Aside from the cache pollution I recall having been mentioned, on my
> > E5620, cross core is a tbench win over affine, cross thread is not.
>
> Oh, I agree with trying to av
Commit-ID: b1a74bf8212367be2b1d6685c11a84e056eaaaf1
Gitweb: http://git.kernel.org/tip/b1a74bf8212367be2b1d6685c11a84e056eaaaf1
Author: Suresh Siddha
AuthorDate: Thu, 20 Sep 2012 11:01:49 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 21 Sep 2012 16:59:04 -0700
x86, kvm: fix kvm&#
the error never
> gets cleared, the Linux kernel continuously print this error:
> "NMI: IOCK error (debug interrupt?) for reason"
Not sure why we get a NMI instead of a vt-d fault? Perhaps the vt-d
fault is also getting reported via NMI in this platform?
Does your tested kernel has
On Thu, 2012-09-20 at 12:50 +0300, Avi Kivity wrote:
> On 09/20/2012 03:10 AM, Suresh Siddha wrote:
> > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > index b06737d..8ff328b 100644
> > --- a/arch/x86/kvm/vmx.c
> > +++ b/arch/x86/kvm/vmx.c
> >
On Wed, 2012-09-19 at 10:18 -0700, Suresh Siddha wrote:
> These routines (kvm_load/put_guest_fpu()) are already called with
> preemption disabled but as you mentioned, we don't want the preemption
> to be disabled completely between the kvm_load_guest_fpu() and
> kvm_put_guest_fpu
On Wed, 2012-09-19 at 20:22 +0300, Avi Kivity wrote:
> On 09/19/2012 08:18 PM, Suresh Siddha wrote:
>
> > These routines (kvm_load/put_guest_fpu()) are already called with
> > preemption disabled but as you mentioned, we don't want the preemption
> > to be di
On Wed, 2012-09-19 at 13:13 +0300, Avi Kivity wrote:
> On 08/25/2012 12:12 AM, Suresh Siddha wrote:
> > kvm's guest fpu save/restore should be wrapped around
> > kernel_fpu_begin/end(). This will avoid for example taking a DNA
> > in kvm_load_guest_fpu() when it tries t
Commit-ID: a8615af4bc3621cb01096541dafa6f68352ec2d9
Gitweb: http://git.kernel.org/tip/a8615af4bc3621cb01096541dafa6f68352ec2d9
Author: Suresh Siddha
AuthorDate: Mon, 10 Sep 2012 10:40:08 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 18 Sep 2012 15:52:24 -0700
x86, fpu: remove
Commit-ID: e00229819f306b1f86134095347e9187dc346bd1
Gitweb: http://git.kernel.org/tip/e00229819f306b1f86134095347e9187dc346bd1
Author: Suresh Siddha
AuthorDate: Mon, 10 Sep 2012 10:32:32 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 18 Sep 2012 15:52:24 -0700
x86, fpu: make
Commit-ID: 5d2bd7009f306c82afddd1ca4d9763ad8473c216
Gitweb: http://git.kernel.org/tip/5d2bd7009f306c82afddd1ca4d9763ad8473c216
Author: Suresh Siddha
AuthorDate: Thu, 6 Sep 2012 14:58:52 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 18 Sep 2012 15:52:22 -0700
x86, fpu: decouple non
Commit-ID: 304bceda6a18ae0b0240b8aac9a6bdf8ce2d2469
Gitweb: http://git.kernel.org/tip/304bceda6a18ae0b0240b8aac9a6bdf8ce2d2469
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:13:02 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 18 Sep 2012 15:52:11 -0700
x86, fpu: use non-lazy
Commit-ID: 9c6ff8bbb69a4e7b47ac40bfa44509296e89c5c0
Gitweb: http://git.kernel.org/tip/9c6ff8bbb69a4e7b47ac40bfa44509296e89c5c0
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:13:01 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 18 Sep 2012 15:52:09 -0700
lguest, x86: handle
Commit-ID: 841e3604d35aa70d399146abdc526d8c89a2c2f5
Gitweb: http://git.kernel.org/tip/841e3604d35aa70d399146abdc526d8c89a2c2f5
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:13:00 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 18 Sep 2012 15:52:08 -0700
x86, fpu: always use
Commit-ID: 9c1c3fac53378c9782c18f80107965578d7b7167
Gitweb: http://git.kernel.org/tip/9c1c3fac53378c9782c18f80107965578d7b7167
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:12:59 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 18 Sep 2012 15:52:07 -0700
x86, kvm: use
Commit-ID: 377ffbcc536a5adc077395163ab149c02610
Gitweb: http://git.kernel.org/tip/377ffbcc536a5adc077395163ab149c02610
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:12:58 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 18 Sep 2012 15:52:06 -0700
x86, fpu: remove
Commit-ID: e962591749dfd4df9fea2c530ed7a3cfed50e5aa
Gitweb: http://git.kernel.org/tip/e962591749dfd4df9fea2c530ed7a3cfed50e5aa
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:12:57 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 18 Sep 2012 15:52:05 -0700
x86, fpu: drop_fpu
Commit-ID: 72a671ced66db6d1c2bfff1c930a101ac8d08204
Gitweb: http://git.kernel.org/tip/72a671ced66db6d1c2bfff1c930a101ac8d08204
Author: Suresh Siddha
AuthorDate: Tue, 24 Jul 2012 16:05:29 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 18 Sep 2012 15:51:48 -0700
x86, fpu: Unify signal
Commit-ID: 0ca5bd0d886578ad0afeceaa83458c0f35cb3c6b
Gitweb: http://git.kernel.org/tip/0ca5bd0d886578ad0afeceaa83458c0f35cb3c6b
Author: Suresh Siddha
AuthorDate: Tue, 24 Jul 2012 16:05:28 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 18 Sep 2012 15:51:26 -0700
x86, fpu: Consolidate
Commit-ID: 050902c011712ad4703038fa4489ec4edd87d396
Gitweb: http://git.kernel.org/tip/050902c011712ad4703038fa4489ec4edd87d396
Author: Suresh Siddha
AuthorDate: Tue, 24 Jul 2012 16:05:27 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 18 Sep 2012 15:51:26 -0700
x86, signal: Cleanup
kernel_fpu_begin() from
the process context but with BH disabled, then we can look into fixing the
irq_fpu_usable() in future. ]
Signed-off-by: Suresh Siddha
Cc: Tim Chen
---
crypto/tcrypt.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto
On Wed, 2012-09-12 at 15:58 +0800, Alex Shi wrote:
> On 09/12/2012 02:36 AM, Suresh Siddha wrote:
>
> > On Mon, 2012-09-10 at 15:10 +0800, Alex Shi wrote:
> >> Remove a redundant check for on_null_domain(cpu), and rerange the code
> >> that make it more readable
On Mon, 2012-09-10 at 15:10 +0800, Alex Shi wrote:
> Remove a redundant check for on_null_domain(cpu), and rerange the code
> that make it more readable.
hmm, but we are now doing the on_null_domain() check always,
irrespective of whether we need the load balance or not.
do we really need the on_
ame it as
> set_nohz_tick_stopped, since there is a clear_nohz_tick_stopped(), that
> just do the opposed action of this function. According to this, is it
> better to another function to nohz_balance_leave_idle()?
> Or keep their current name?
>
Yes that will be more appropriat
On Mon, 2012-09-10 at 13:37 +0100, Jan Beulich wrote:
> 1: unify SSE-base xor-block routines
> 2: improve XMM register spill/fill
> 3: add alternative SSE implementation only prefetching once per 64-byte line
> 4: make virtualization friendly
>
> Signed-off-by: Jan Beulich
Jan, There are some re
xsaveopt/xrstor support optimized state save/restore by tracking the
INIT state and MODIFIED state during context-switch.
Enable eagerfpu by default for processors supporting xsaveopt.
Can be disabled by passing "eagerfpu=off" boot parameter.
Signed-off-by: Suresh Siddha
---
Doc
Signed-off-by: Suresh Siddha
---
arch/x86/include/asm/fpu-internal.h |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/fpu-internal.h
b/arch/x86/include/asm/fpu-internal.h
index df023b4..9fa1a0e 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b
Add the "eagerfpu=auto" (that selects the default scheme in
enabling eagerfpu) which can override compiled-in boot parameters
like "eagerfpu=on/off" (that force enable/disable eagerfpu).
Signed-off-by: Suresh Siddha
---
Documentation/kernel-parameters.txt |4 +++-
arc
Decouple non-lazy/eager fpu restore policy from the existence of the xsave
feature. Introduce a synthetic CPUID flag to represent the eagerfpu
policy. "eagerfpu=on" boot paramter will enable the policy.
Requested-by: H. Peter Anvin
Requested-by: Linus Torvalds
Signed-off-by: Sur
et touches that area of code).
Suresh Siddha (5):
x86, fpu: decouple non-lazy/eager fpu restore from xsave
x86, fpu: enable eagerfpu by default for xsaveopt
x86, fpu: move check_fpu() after alternative_instructions()
x86, fpu: make eagerfpu= boot param tri-state
x86, fpu: remove cpu_has
On Sat, 2012-09-08 at 12:57 -0700, Linus Torvalds wrote:
> Whatever. Something like this (TOTALLY UNTESTED) attached patch should
> get the mtdchar overflows to go away,
It looks good to me. Acked-by: Suresh Siddha
Sasha, can you please give this a try?
> but it does *not* fix the fa
teresting to hear if it's the 32-bit
> 'len' thing that triggers this problem. Still, I can't see how it
> would - as far as I can tell, a truncated 'len' would at most result
> in spurious early "return -EINVAL", not any real problem.
>
> What are
ue to bad types, but maybe it does deeper than that?
>
I started to look into this to see if this is a PAT issue but it does
indeed appear to be a mtd mmap issue.
Sasha, Does the appended fix the issue for you?
--8<--
From: Suresh Siddha
Subject: mtd: check the starting offset to be mmap
On Fri, 2012-09-07 at 11:43 -0700, H. Peter Anvin wrote:
> On 09/07/2012 11:31 AM, Suresh Siddha wrote:
> >
> > diff --git a/Documentation/kernel-parameters.txt
> > b/Documentation/kernel-parameters.txt
> > index 6273099..b21bcbd 100644
> > --- a/Documentatio
On Fri, 2012-09-07 at 11:47 -0700, H. Peter Anvin wrote:
> On 09/07/2012 11:31 AM, Suresh Siddha wrote:
> >
> > +static inline void fx_finit(struct i387_fxsave_struct *fx)
> > +{
> > + memset(fx, 0, xstate_size);
> > + fx->cwd = 0x37f;
> > +
use_eager_fpu() in kernel_fpu_begin/end() relies on the patched
alternative instructions. So move check_fpu() which uses the
kernel_fpu_begin/end() after alternative_instructions().
Signed-off-by: Suresh Siddha
---
arch/x86/kernel/cpu/bugs.c |7 ++-
1 files changed, 6 insertions(+), 1
xsaveopt/xrstor support optimized state save/restore by tracking the
INIT state and MODIFIED state during context-switch.
Enable eagerfpu by default for processors supporting xsaveopt.
Can be disabled by passing "eagerfpu=off" boot parameter.
Signed-off-by: Suresh Siddha
---
Doc
Decouple non-lazy/eager fpu restore policy from the existence of the xsave
feature. Introduce a synthetic CPUID flag to represent the eagerfpu
policy. "eagerfpu=on" boot paramter will enable the policy.
Requested-by: H. Peter Anvin
Requested-by: Linus Torvalds
Signed-off-by: Sur
Commit-ID: 127f5403bfbc5f52cf0fbbadfa5e624a32a137ff
Gitweb: http://git.kernel.org/tip/127f5403bfbc5f52cf0fbbadfa5e624a32a137ff
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:13:02 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:54 -0700
x86, fpu: use non-lazy
Commit-ID: 1ce83ffda9aea53e6e4b6b6a82c028a019526010
Gitweb: http://git.kernel.org/tip/1ce83ffda9aea53e6e4b6b6a82c028a019526010
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:13:01 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:52 -0700
lguest, x86: handle
Commit-ID: 964735018df03c94dd12665385d59e3b2c7c08b8
Gitweb: http://git.kernel.org/tip/964735018df03c94dd12665385d59e3b2c7c08b8
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:13:00 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:50 -0700
x86, fpu: always use
Commit-ID: 98700fa647b3572f7fa55485570ab9fc53b91d23
Gitweb: http://git.kernel.org/tip/98700fa647b3572f7fa55485570ab9fc53b91d23
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:12:59 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:49 -0700
x86, kvm: use
Commit-ID: cc50fae05beb2db9f4587bbb1a0d6aba2af5b407
Gitweb: http://git.kernel.org/tip/cc50fae05beb2db9f4587bbb1a0d6aba2af5b407
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:12:58 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:48 -0700
x86, fpu: remove
Commit-ID: 739390035c5fba2132fa424309786ff7bdd2cc1e
Gitweb: http://git.kernel.org/tip/739390035c5fba2132fa424309786ff7bdd2cc1e
Author: Suresh Siddha
AuthorDate: Fri, 24 Aug 2012 14:12:57 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 24 Aug 2012 14:26:47 -0700
x86, fpu: drop_fpu
No need to save the state with unlazy_fpu(), that is about to get overwritten
by the state from the signal frame. Instead use drop_fpu() and continue
to restore the new state.
Also fold the stop_fpu_preload() into drop_fpu().
Signed-off-by: Suresh Siddha
---
arch/x86/include/asm/fpu-internal.h
being
corrupted.
Signed-off-by: Suresh Siddha
Cc: Avi Kivity
---
arch/x86/kvm/x86.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 42bce48..67e773c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5969,7 +5
problem if the xmm/ymm registers are manually saved and restored
(corrupting the extended state of those vector registers).
With this patch, there was no significant difference in the xor throughput
using AVX, measured during boot.
Signed-off-by: Suresh Siddha
Cc: Jim Kukunas
Cc: NeilBrown
---
ar
ing kernel-compilation workload.
* Improved throughput of the AVX based checksumming function inside the
kernel by ~15% as xsave/xrstor is faster than the serializing clts/stts
pair.
Signed-off-by: Suresh Siddha
Cc: Jim Kukunas
Cc: NeilBrown
Cc: Avi Kivity
---
arch/x86/include/asm/fpu-
Instead of using unlazy_fpu() check if user_has_fpu() and set/clear
the host TS bits so that the lguest works fine with both the
lazy/non-lazy FPU host models with minimal changes.
Signed-off-by: Suresh Siddha
Cc: Rusty Russell
---
drivers/lguest/x86/core.c | 10 +++---
1 files changed
Few lines below we do drop_fpu() which is more safer. Remove the
unnecessary user_fpu_end() in save_xstate_sig(), which allows
the drop_fpu() to ignore any pending exceptions from the user-space
and drop the current fpu.
Signed-off-by: Suresh Siddha
---
arch/x86/include/asm/fpu-internal.h
These patches are against tip/x86/fpu. Few cleanups and more improtantly
this series introduces the non-lazy FPU restore mechanism for processors
supporting xsave feature. More details in the individual patch changelogs.
Thanks.
Suresh Siddha (6):
x86, fpu: drop_fpu() before restoring new
Commit-ID: b2104ba4a037e296901e73a0d396826c13625bb0
Gitweb: http://git.kernel.org/tip/b2104ba4a037e296901e73a0d396826c13625bb0
Author: Suresh Siddha
AuthorDate: Thu, 9 Aug 2012 13:38:56 -0700
Committer: H. Peter Anvin
CommitDate: Thu, 9 Aug 2012 17:13:57 -0700
x86, fpu: fix build
.. for an x86-64 allyesconfig.
Sorry my binutils didn't have x32 support, so didn't catch this earlier.
Here is the updated patch fixing all the compilation issues. Thanks.
---
From: Suresh Siddha
Subject: x86, fpu: fix build issues with CONFIG_IA32_EMULATION,
CONFIG_X86_X32_ABI
Fengguan
On Wed, 2012-08-08 at 13:04 +0200, Borislav Petkov wrote:
> On Wed, Aug 08, 2012 at 10:58:37AM +0200, Robert Richter wrote:
> > On 07.08.12 15:39:07, Suresh Siddha wrote:
> > > Boris, Robert, can you check if the below patch makes both of your
> > > systems happy agai
On Tue, 2012-08-07 at 22:57 +0200, Borislav Petkov wrote:
> The funny thing is, they deliver to all CPUs except the BSP.
Looking at your /proc/interrupts below, probably it is using some sort
of round-robin.
> Or maybe the BSP gets that IRQ too but it actually has a handler
> registered?
from /p
On Tue, 2012-08-07 at 15:55 -0500, Seth Forshee wrote:
> On Tue, Aug 07, 2012 at 01:47:52PM -0700, Suresh Siddha wrote:
> > On Tue, 2012-08-07 at 22:10 +0200, Joerg Roedel wrote:
> > > Hi Seth,
> > >
> > > On Tue, Aug 07, 2012 at 02:48:37PM -0500, Seth Forsh
pr_info("ioapic %d has no mapping iommu, "
> + "interrupt remapping will be disabled\n",
> + ioapic_id);
> + return -1;
> + }
> + }
It will be cleaner to mo
On Tue, 2012-08-07 at 22:10 +0200, Joerg Roedel wrote:
> Hi Seth,
>
> On Tue, Aug 07, 2012 at 02:48:37PM -0500, Seth Forshee wrote:
> > This machine has a bug in its ACPI tables that's causing it to fail to
> > boot unless intremap=off is passed to the kernel. The MADT defines a
> > single IOAPIC
On Tue, 2012-08-07 at 19:28 +0200, Robert Richter wrote:
> On 07.08.12 09:24:21, Suresh Siddha wrote:
> > Boris, Robert, Can you please send me the complete dmesg
> > and /proc/interrupts on a successful boot?
>
> Sent to you in private mail.
Thanks.
>
> What info
On Tue, 2012-08-07 at 17:41 +0200, Borislav Petkov wrote:
> On Tue, Aug 07, 2012 at 05:31:49PM +0200, Robert Richter wrote:
> > On 06.06.12 08:03:58, tip-bot for Suresh Siddha wrote:
> > > Commit-ID: 332afa656e76458ee9cf0f0d123016a0658539e4
> > > Gitweb:
>
On Tue, 2012-07-31 at 13:41 +0200, Alexander Gordeev wrote:
> Currently multiple MSI mode is limited to a single vector per device (at
> least on x86 and PPC). This series breathes life into pci_enable_msi_block()
> and makes it possible to set interrupt affinity for multiple IRQs, similarly
> to M
is for v3.6. Thanks.
---
From: Suresh Siddha
Subject: x86, avx: don't use avx instructions with "noxsave" boot param
Clear AVX, AVX2 features along with clearing XSAVE feature bits,
as part of the parsing "noxsave" parameter.
Fixes the kernel boot panic with "nox
On Mon, 2012-07-30 at 21:33 -0700, H. Peter Anvin wrote:
> I'm wondering if we shouldn't just kill the affected CPUID bits if osxsave is
> off...
Yes, I considered clearing AVX bit (and any future xsave feature bits)
as part of the parsing "noxsave" parameter in x86_xsave_setup().
But thought ch
Check the kernel has indeed enabled xsave before using AVX instructions.
Fixes the kernel boot panic with "noxsave" boot parameter.
Signed-off-by: Suresh Siddha
---
arch/x86/include/asm/xor_avx.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/i
cpus_end()
>which were only used to set this one flag.
>
> Signed-off-by: Rusty Russell
Acked-by: Suresh Siddha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Fri, 2012-07-27 at 17:08 +0930, Rusty Russell wrote:
> Paul McKenney points out:
>
> mean offline overhead is 6251/48=130.2 milliseconds.
>
> If I remove the alternatives_smp_switch() from the offline
> path [...] the mean offline overhead is 550/42=13.1 milliseconds
>
> Basically, we're n
ter to incomplete type
> arch/x86/kernel/xsave.c: In function 'save_user_xstate':
> arch/x86/kernel/xsave.c:209:15: warning: ignoring return value of
> '__clear_user', declared with attribute warn_unused_result [-Wunused-result]
>
Appended the patch for this. Thank
Commit-ID: 29221d4b89d4e50f05ade42ad3b22e92bb564ca4
Gitweb: http://git.kernel.org/tip/29221d4b89d4e50f05ade42ad3b22e92bb564ca4
Author: Suresh Siddha
AuthorDate: Tue, 24 Jul 2012 16:05:29 -0700
Committer: H. Peter Anvin
CommitDate: Wed, 25 Jul 2012 13:25:25 -0700
x86, fpu: Unify signal
Commit-ID: 6c9ecaa3cdd6414c3d74c4d1a4ec23dc8dda5d29
Gitweb: http://git.kernel.org/tip/6c9ecaa3cdd6414c3d74c4d1a4ec23dc8dda5d29
Author: Suresh Siddha
AuthorDate: Tue, 24 Jul 2012 16:05:28 -0700
Committer: H. Peter Anvin
CommitDate: Wed, 25 Jul 2012 13:25:21 -0700
x86, fpu: Consolidate
Commit-ID: cc70cdc33242d79a48f46f652e5ce2deb86c9c09
Gitweb: http://git.kernel.org/tip/cc70cdc33242d79a48f46f652e5ce2deb86c9c09
Author: Suresh Siddha
AuthorDate: Tue, 24 Jul 2012 16:05:27 -0700
Committer: H. Peter Anvin
CommitDate: Wed, 25 Jul 2012 13:25:18 -0700
x86, signal: Cleanup
Use config_enabled() to cleanup the definitions of is_ia32/is_x32. Move
the function prototypes to the header file to cleanup ifdefs.
Signed-off-by: Suresh Siddha
---
arch/x86/include/asm/fpu-internal.h | 29
arch/x86/include/asm/signal.h |4 ++
arch/x86/kernel
1 - 100 of 105 matches
Mail list logo
