* Andy Lutomirski wrote:
> On Wed, Aug 5, 2015 at 11:27 AM, Steven Rostedt wrote:
> > On Wed, 5 Aug 2015 11:24:54 -0700
> > Andy Lutomirski wrote:
> >
> >> On Wed, Aug 5, 2015 at 1:59 AM, Ingo Molnar wrote:
> >> >
> >> > * Andy Lutomirski wrote:
> >> >
> >> >> ---
* Andy Lutomirski l...@amacapital.net wrote:
On Wed, Aug 5, 2015 at 11:27 AM, Steven Rostedt rost...@goodmis.org wrote:
On Wed, 5 Aug 2015 11:24:54 -0700
Andy Lutomirski l...@amacapital.net wrote:
On Wed, Aug 5, 2015 at 1:59 AM, Ingo Molnar mi...@kernel.org wrote:
* Andy
On Wed, Aug 5, 2015 at 11:27 AM, Steven Rostedt wrote:
> On Wed, 5 Aug 2015 11:24:54 -0700
> Andy Lutomirski wrote:
>
>> On Wed, Aug 5, 2015 at 1:59 AM, Ingo Molnar wrote:
>> >
>> > * Andy Lutomirski wrote:
>> >
>> >> --- a/arch/x86/kernel/process_64.c
>> >> +++ b/arch/x86/kernel/process_64.c
On Wed, 5 Aug 2015 11:24:54 -0700
Andy Lutomirski wrote:
> On Wed, Aug 5, 2015 at 1:59 AM, Ingo Molnar wrote:
> >
> > * Andy Lutomirski wrote:
> >
> >> --- a/arch/x86/kernel/process_64.c
> >> +++ b/arch/x86/kernel/process_64.c
> >> @@ -280,6 +280,10 @@ __switch_to(struct task_struct *prev_p,
On Wed, Aug 5, 2015 at 1:59 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> --- a/arch/x86/kernel/process_64.c
>> +++ b/arch/x86/kernel/process_64.c
>> @@ -280,6 +280,10 @@ __switch_to(struct task_struct *prev_p, struct
>> task_struct *next_p)
>> unsigned fsindex, gsindex;
>>
* Andy Lutomirski wrote:
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -280,6 +280,10 @@ __switch_to(struct task_struct *prev_p, struct
> task_struct *next_p)
> unsigned fsindex, gsindex;
> fpu_switch_t fpu_switch;
>
> +#ifdef CONFIG_DEBUG_ENTRY
>
* Andy Lutomirski l...@kernel.org wrote:
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -280,6 +280,10 @@ __switch_to(struct task_struct *prev_p, struct
task_struct *next_p)
unsigned fsindex, gsindex;
fpu_switch_t fpu_switch;
+#ifdef
On Wed, Aug 5, 2015 at 1:59 AM, Ingo Molnar mi...@kernel.org wrote:
* Andy Lutomirski l...@kernel.org wrote:
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -280,6 +280,10 @@ __switch_to(struct task_struct *prev_p, struct
task_struct *next_p)
unsigned
On Wed, 5 Aug 2015 11:24:54 -0700
Andy Lutomirski l...@amacapital.net wrote:
On Wed, Aug 5, 2015 at 1:59 AM, Ingo Molnar mi...@kernel.org wrote:
* Andy Lutomirski l...@kernel.org wrote:
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -280,6 +280,10 @@
On Wed, Aug 5, 2015 at 11:27 AM, Steven Rostedt rost...@goodmis.org wrote:
On Wed, 5 Aug 2015 11:24:54 -0700
Andy Lutomirski l...@amacapital.net wrote:
On Wed, Aug 5, 2015 at 1:59 AM, Ingo Molnar mi...@kernel.org wrote:
* Andy Lutomirski l...@kernel.org wrote:
---
On Sat, Jul 25, 2015 at 10:59 AM, Andy Lutomirski wrote:
>
> What if we added something like:
>
> if (regs->ip == ret_after_sti && !user_mode(regs) && (regs->flags &
> X86_EFLAGS_IF)) {
> regs->ip--;
> regs->flags &= ~X86_EFLAGS_IF;
> }
>
> to do_nmi, do_machine_check, and do_debug (the
On Sat, Jul 25, 2015 at 10:56 AM, Linus Torvalds
wrote:
> On Fri, Jul 24, 2015 at 9:59 PM, Andy Lutomirski wrote:
>>
>> And people will give me five new heads if I ignore Linus and do RET
>> even with IF=1, saving 300 cycles?
>
> So I'm still nervous about that "sti; ret" when we're back on the
On Fri, Jul 24, 2015 at 9:59 PM, Andy Lutomirski wrote:
>
> And people will give me five new heads if I ignore Linus and do RET
> even with IF=1, saving 300 cycles?
So I'm still nervous about that "sti; ret" when we're back on the
original kernel stack that took the original fault or interrupt.
On Fri, Jul 24, 2015 at 09:59:16PM -0700, Andy Lutomirski wrote:
> And people will give me five new heads if I ignore Linus and do RET
> even with IF=1, saving 300 cycles?
As long as you don't make it too complex and corner-casy, I'll give you
hats for those heads.
--
Regards/Gruss,
Boris.
On Fri, Jul 24, 2015 at 09:59:16PM -0700, Andy Lutomirski wrote:
And people will give me five new heads if I ignore Linus and do RET
even with IF=1, saving 300 cycles?
As long as you don't make it too complex and corner-casy, I'll give you
hats for those heads.
--
Regards/Gruss,
Boris.
On Sat, Jul 25, 2015 at 10:56 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, Jul 24, 2015 at 9:59 PM, Andy Lutomirski l...@amacapital.net wrote:
And people will give me five new heads if I ignore Linus and do RET
even with IF=1, saving 300 cycles?
So I'm still nervous about
On Fri, Jul 24, 2015 at 9:59 PM, Andy Lutomirski l...@amacapital.net wrote:
And people will give me five new heads if I ignore Linus and do RET
even with IF=1, saving 300 cycles?
So I'm still nervous about that sti; ret when we're back on the
original kernel stack that took the original fault
On Sat, Jul 25, 2015 at 10:59 AM, Andy Lutomirski l...@amacapital.net wrote:
What if we added something like:
if (regs-ip == ret_after_sti !user_mode(regs) (regs-flags
X86_EFLAGS_IF)) {
regs-ip--;
regs-flags = ~X86_EFLAGS_IF;
}
to do_nmi, do_machine_check, and do_debug (the latter
On Fri, Jul 24, 2015 at 9:32 PM, Borislav Petkov wrote:
> On Fri, Jul 24, 2015 at 09:28:47PM -0700, Andy Lutomirski wrote:
>> Yeah, I'm going to submit v2 with the simple approach. I admit I'm
>> rather fond of xadd as a way to switch rsp and set a flag at the same
>> time, though :)
>
> I know
On Fri, Jul 24, 2015 at 09:28:47PM -0700, Andy Lutomirski wrote:
> Yeah, I'm going to submit v2 with the simple approach. I admit I'm
> rather fond of xadd as a way to switch rsp and set a flag at the same
> time, though :)
I know you are.
But people will rip your head out if you added 60
On Fri, Jul 24, 2015 at 9:16 PM, Borislav Petkov wrote:
> On Fri, Jul 24, 2015 at 11:02:51AM -0700, Andy Lutomirski wrote:
>> So really the only difference between this simple approach (which is
>> more or less what we do now) and my fancy approach is that a kernel
>> instruction breakpoint will
On Fri, Jul 24, 2015 at 11:02:51AM -0700, Andy Lutomirski wrote:
> So really the only difference between this simple approach (which is
> more or less what we do now) and my fancy approach is that a kernel
> instruction breakpoint will cause do_debug to run on the initial stack
> instead of the
On Fri, Jul 24, 2015 at 3:25 AM, Borislav Petkov wrote:
> On Thu, Jul 23, 2015 at 11:08:39PM -0700, Andy Lutomirski wrote:
>> To be obviously safe against any local exception, we want a single
>> instruction that will change %rsp and some in-memory flag at the same
>> time. There aren't a whole
On Thu, Jul 23, 2015 at 11:08:39PM -0700, Andy Lutomirski wrote:
> To be obviously safe against any local exception, we want a single
> instruction that will change %rsp and some in-memory flag at the same
> time. There aren't a whole lot of candidates. Cmpxchg isn't useful
> (cmpxchg with a
On Thu, Jul 23, 2015 at 3:37 PM, Andy Lutomirski wrote:
> This will allow IRQ stacks to nest inside NMIs or similar entries
> that can happen during IRQ stack setup or teardown.
>
> The Xen code here has a confusing comment.
>
> Signed-off-by: Andy Lutomirski
> ---
> arch/x86/entry/entry_64.S
On Thu, Jul 23, 2015 at 3:37 PM, Andy Lutomirski l...@kernel.org wrote:
This will allow IRQ stacks to nest inside NMIs or similar entries
that can happen during IRQ stack setup or teardown.
The Xen code here has a confusing comment.
Signed-off-by: Andy Lutomirski l...@kernel.org
---
On Thu, Jul 23, 2015 at 11:08:39PM -0700, Andy Lutomirski wrote:
To be obviously safe against any local exception, we want a single
instruction that will change %rsp and some in-memory flag at the same
time. There aren't a whole lot of candidates. Cmpxchg isn't useful
(cmpxchg with a memory
On Fri, Jul 24, 2015 at 3:25 AM, Borislav Petkov b...@alien8.de wrote:
On Thu, Jul 23, 2015 at 11:08:39PM -0700, Andy Lutomirski wrote:
To be obviously safe against any local exception, we want a single
instruction that will change %rsp and some in-memory flag at the same
time. There aren't a
On Fri, Jul 24, 2015 at 11:02:51AM -0700, Andy Lutomirski wrote:
So really the only difference between this simple approach (which is
more or less what we do now) and my fancy approach is that a kernel
instruction breakpoint will cause do_debug to run on the initial stack
instead of the IRQ
On Fri, Jul 24, 2015 at 9:16 PM, Borislav Petkov b...@alien8.de wrote:
On Fri, Jul 24, 2015 at 11:02:51AM -0700, Andy Lutomirski wrote:
So really the only difference between this simple approach (which is
more or less what we do now) and my fancy approach is that a kernel
instruction
On Fri, Jul 24, 2015 at 09:28:47PM -0700, Andy Lutomirski wrote:
Yeah, I'm going to submit v2 with the simple approach. I admit I'm
rather fond of xadd as a way to switch rsp and set a flag at the same
time, though :)
I know you are.
But people will rip your head out if you added 60 cycles
On Fri, Jul 24, 2015 at 9:32 PM, Borislav Petkov b...@alien8.de wrote:
On Fri, Jul 24, 2015 at 09:28:47PM -0700, Andy Lutomirski wrote:
Yeah, I'm going to submit v2 with the simple approach. I admit I'm
rather fond of xadd as a way to switch rsp and set a flag at the same
time, though :)
I
This will allow IRQ stacks to nest inside NMIs or similar entries
that can happen during IRQ stack setup or teardown.
The Xen code here has a confusing comment.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/entry_64.S| 72 ++--
This will allow IRQ stacks to nest inside NMIs or similar entries
that can happen during IRQ stack setup or teardown.
The Xen code here has a confusing comment.
Signed-off-by: Andy Lutomirski l...@kernel.org
---
arch/x86/entry/entry_64.S| 72 ++--
34 matches
Mail list logo
