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;
>
>
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)
On Fri, Aug 29, 2014 at 11:16 AM, Oleg Nesterov o...@redhat.com 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
On Fri, Aug 29, 2014 at 11:17 AM, Oleg Nesterov o...@redhat.com 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;
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 http
if (use_eager_fpu()) {
> + preempt_disable();
> math_state_restore();
> + preempt_enable();
> + }
>
> return err;
> } else {
>
oops. looks good to me.
Reviewed-by: Suresh Siddha
--
To
();
math_state_restore();
+ preempt_enable();
+ }
return err;
} else {
oops. looks good to me.
Reviewed-by: Suresh Siddha sbsid...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
deletions(-)
These 4 patches also look good to me.
Reviewed-by: Suresh Siddha sbsid...@gmail.com
--
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
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
Commit-ID: 731bd6a93a6e9172094a2322bd0ee964bb1f4d63
Gitweb: http://git.kernel.org/tip/731bd6a93a6e9172094a2322bd0ee964bb1f4d63
Author: Suresh Siddha sbsid...@gmail.com
AuthorDate: Sun, 2 Feb 2014 22:56:23 -0800
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 11 Mar 2014
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 Fri, Mar 7, 2014 at 3:18 PM, H. Peter Anvin h...@zytor.com 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
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 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()).
We
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
> > know i
On Sun, 2014-02-02 at 11:15 -0800, Linus Torvalds wrote:
On Sat, Feb 1, 2014 at 11:19 PM, Suresh Siddha sbsid...@gmail.com 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
know if you want me
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 will be
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
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;
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,
On Sat, Feb 1, 2014 at 11:27 AM, Linus Torvalds
torva...@linux-foundation.org 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.
On Sat, Feb 1, 2014 at 5:26 PM, H. Peter Anvin h...@zytor.com 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;
On Sat, Feb 1, 2014 at 5:38 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Sat, Feb 1, 2014 at 5:51 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Sat, Feb 1, 2014 at 5:47 PM, Suresh Siddha sbsid...@gmail.com 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
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 will be coming
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
hi,
On Thu, Jan 30, 2014 at 2:24 PM, Linus Torvalds
torva...@linux-foundation.org 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
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 irresp
Had this cleanup patch (tested before by me and Boris aswell) for a
while. Forgot to post this earlier. Thanks.
---8---
From: Suresh Siddha suresh.b.sid...@intel.com
Subject: x86, apic: cleanup cfg-domain setup for legacy interrupts
Issues that need to be handled:
* Handle PIC interrupts on any
Commit-ID: 29c574c0aba8dc0736e19eb9b24aad28cc5c9098
Gitweb: http://git.kernel.org/tip/29c574c0aba8dc0736e19eb9b24aad28cc5c9098
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Mon, 26 Nov 2012 14:49:36 -0800
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Mon, 26
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
Commit-ID: 279f1461432ccdec0b98c0bcbe0a8e2c0f6fdda5
Gitweb: http://git.kernel.org/tip/279f1461432ccdec0b98c0bcbe0a8e2c0f6fdda5
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Mon, 22 Oct 2012 14:37:58 -0700
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Fri, 2 Nov
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 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
-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 changed, 7 insertions(+), 2 deletions
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 linbao.zh...@hp.com
Signed-off-by: Suresh Siddha suresh.b.sid...@intel.com
Cc: sta...@vger.kernel.org [v2.6.32..v2.6.34]
---
arch/x86/kernel/apic/io_apic.c
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 RTE's is not working as expected
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 4b6b19a1c7302477653d799a53d48063dd53d555
More
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
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 suresh.b.sid...@intel.com
Subject: x86, apic: use tsc deadline for oneshot when available
If the TSC deadline mode is supported
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
tly 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
Signe
if the bios has not exported interrupt-remapping tables to
the
OS).
Reported-by: Berck E. Nash fly...@gmail.com
Signed-off-by: Yinghai Lu ying...@kernel.org
Link:
http://lkml.kernel.org/r/20111222014632.600418...@sbsiddha-desk.sc.intel.com
Signed-off-by: Suresh Siddha
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
suresh.b.sid...@intel.com wrote:
On Fri, 2012-10-19 at 13:42 -0700, rrl...@gmail.com wrote:
Any update? The messages just seem to have stopped
On Wed, 2012-10-10 at 00:26 +, Zhang, Lin-Bao (Linux Kernel R)
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
On Wed, 2012-10-10 at 16:02 -0700, Zhang, Lin-Bao (Linux Kernel R)
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 Wed, 2012-10-10 at 16:02 -0700, Zhang, Lin-Bao (Linux Kernel RD)
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.
So I
On Wed, 2012-10-10 at 00:26 +, Zhang, Lin-Bao (Linux Kernel RD)
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
On Sun, 2012-10-07 at 21:53 -0700, Zhang, Lin-Bao (Linux Kernel R)
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 Sun, 2012-10-07 at 21:53 -0700, Zhang, Lin-Bao (Linux Kernel RD)
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, so
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 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 probably the intention of the original
code
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
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 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 affinity masks in the original
code? I find
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
On Mon, 2012-09-24 at 12:12 -0700, Linus Torvalds wrote:
On Mon, Sep 24, 2012 at 11:26 AM, Mike Galbraith efa...@gmx.de 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
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's
Commit-ID: b1a74bf8212367be2b1d6685c11a84e056eaaaf1
Gitweb: http://git.kernel.org/tip/b1a74bf8212367be2b1d6685c11a84e056eaaaf1
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Thu, 20 Sep 2012 11:01:49 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Fri, 21
; 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 this fix?
commit 254e
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 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
@@ -1493,7 +1493,8 @@ static void __vmx_load_host_state
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 this fix?
commit 254e42006c893f45bca48f313536fcba12206418
Author: Suresh Siddha suresh.b.sid...@intel.com
Date: Mon Dec 6 12
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 dis
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 to loa
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 to load the fpu immediately
after
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 disabled completely between
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().
Also KVM
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
Commit-ID: 050902c011712ad4703038fa4489ec4edd87d396
Gitweb: http://git.kernel.org/tip/050902c011712ad4703038fa4489ec4edd87d396
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Tue, 24 Jul 2012 16:05:27 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18
Commit-ID: 0ca5bd0d886578ad0afeceaa83458c0f35cb3c6b
Gitweb: http://git.kernel.org/tip/0ca5bd0d886578ad0afeceaa83458c0f35cb3c6b
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Tue, 24 Jul 2012 16:05:28 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18
Commit-ID: 72a671ced66db6d1c2bfff1c930a101ac8d08204
Gitweb: http://git.kernel.org/tip/72a671ced66db6d1c2bfff1c930a101ac8d08204
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Tue, 24 Jul 2012 16:05:29 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18
Commit-ID: e962591749dfd4df9fea2c530ed7a3cfed50e5aa
Gitweb: http://git.kernel.org/tip/e962591749dfd4df9fea2c530ed7a3cfed50e5aa
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Fri, 24 Aug 2012 14:12:57 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18
Commit-ID: 377ffbcc536a5adc077395163ab149c02610
Gitweb: http://git.kernel.org/tip/377ffbcc536a5adc077395163ab149c02610
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Fri, 24 Aug 2012 14:12:58 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18
Commit-ID: 9c1c3fac53378c9782c18f80107965578d7b7167
Gitweb: http://git.kernel.org/tip/9c1c3fac53378c9782c18f80107965578d7b7167
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Fri, 24 Aug 2012 14:12:59 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18
Commit-ID: 841e3604d35aa70d399146abdc526d8c89a2c2f5
Gitweb: http://git.kernel.org/tip/841e3604d35aa70d399146abdc526d8c89a2c2f5
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Fri, 24 Aug 2012 14:13:00 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18
Commit-ID: 9c6ff8bbb69a4e7b47ac40bfa44509296e89c5c0
Gitweb: http://git.kernel.org/tip/9c6ff8bbb69a4e7b47ac40bfa44509296e89c5c0
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Fri, 24 Aug 2012 14:13:01 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18
Commit-ID: 304bceda6a18ae0b0240b8aac9a6bdf8ce2d2469
Gitweb: http://git.kernel.org/tip/304bceda6a18ae0b0240b8aac9a6bdf8ce2d2469
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Fri, 24 Aug 2012 14:13:02 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18
Commit-ID: 5d2bd7009f306c82afddd1ca4d9763ad8473c216
Gitweb: http://git.kernel.org/tip/5d2bd7009f306c82afddd1ca4d9763ad8473c216
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Thu, 6 Sep 2012 14:58:52 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18 Sep
Commit-ID: e00229819f306b1f86134095347e9187dc346bd1
Gitweb: http://git.kernel.org/tip/e00229819f306b1f86134095347e9187dc346bd1
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Mon, 10 Sep 2012 10:32:32 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18
Commit-ID: a8615af4bc3621cb01096541dafa6f68352ec2d9
Gitweb: http://git.kernel.org/tip/a8615af4bc3621cb01096541dafa6f68352ec2d9
Author: Suresh Siddha suresh.b.sid...@intel.com
AuthorDate: Mon, 10 Sep 2012 10:40:08 -0700
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Tue, 18
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
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 suresh.b.sid...@intel.com
Cc: Tim Chen tim.c.c...@linux.intel.com
---
crypto/tcrypt.c |6 --
1 files changed, 0 insertions(+), 6
1 - 100 of 210 matches
Mail list logo
